Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years

Subject: Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2015-01-03 03:45:10

Gennadiy,

On 12/31/2014 01:44 PM, Gennadiy Rozental wrote:
> Vladimir Prus <vladimir <at> codesourcery.com> writes:
>
>> Gennadiy,
>>
>> I might be mistaken, but in Trac, you can either say:
>>
>> 	Addresses #100
>>
>> or
>>
>> 	Fixes #100
>>
>> The former adds a comment to issue, so keep everybody updated. The
> latter does the same,
>> and also completely closes the issue.
>>
>> Would that work for you?
>
> I might consider this, but what I was after is something different. I want
> to fix the ticket with actual commit and than in a commit which brings
> changes from develop to master I do not really want to remember which
> tickets this fixes/addresses (especially since I might be doing it half a
> year later with potentially dozen or more fixes bundled together) . I'd
> rather say something like: I am releasing all the fixes since last release
> and that should change the status of all fixed, but not released tickets
> into "released".

There might not be a fully automatic solution, but some fairly lightweight
conventions can make this almost painless:

- Adopt "Linux" style for commit messages, where first line is a brief
summary of the change.

- Further include Trac issue in that line.

- When you merge from develop to master, use "git shortlog master..develop"
to get a list of those one-line summaries that are to be merged, and base
commit message for the merge on the output.

That way, it will be not much work to actually close all merged tickets,
and it will be easy to create automation to do this in future.

> Vlad I have a separate request for you. Would you mind giving me a hand as
> Boost.Build expert. I've been trying to use doxygen rule, but I find it
> ... essentially unusable. The output it produces has number of issues:
>
> * it is missing all class level sections
> * it only generates "file view", while "official" doxygen output is much
> more rich. Class view, namespaces view, module view etc.
> * the output format is very rigid, resulting in some text running out of
> the screen

I would like to help, but Boost.Build only runs doxygen and then invokes
various XSLT tarnsforms. Everything else is either doxygen itself, or
Boost.Book, where I can only make trivial tweaks.

> There is significant (and important) part of documentation I want to place
> into the reference section. I can't find anyone to help me with the
> doxygen rule. So now I am asking: would it be possible to just run native
> doxygen command, collect the output as is and somehow bind it to my
> quickbook based docs?

What do you mean by 'bind' here? Maybe you can ask a separate thread, describing
what you want, so that Boost.Book experts notice it more easily?

Thanks,

-- 
Vladimir Prus
CodeSourcery / Mentor Embedded
http://vladimirprus.com