Re: [Boost-users] what happens between "fixed in development" and "available in release"?

Subject: Re: [Boost-users] what happens between "fixed in development" and "available in release"?
From: oswin krause (oswin.krause_at_[hidden])
Date: 2015-03-20 09:45:47

On 19.03.2015 16:41, Robert Ramey wrote:
> Oswin Krause wrote
>> Hi,
>>
>> Question is in the subject. What has to happen after a fix of a bug in
>> development stage before it enters an official release?
> What has to happen is that I have to merge the serialization develop branch
> to the master branch.  My procedure is:
> a) switch my local copy of the serialization library to master branch.
> b) merge in current develop branch
> c) update my local modular boost tree - which is always kept on the master
> branch
> d) (re)run all serialization library tests with clang and gcc compilers for
> DLL and static libraries and debug and release libraries.  These
> combinations come to about 2000 tests which are presented in a giant table
> which has to come out all "green"  This isn't really enough as it should
> include a couple of versions of VS but I don't have that around.
>
> In this particular instance, I had trouble with step c).  This is not
> unusual as I have to confess the git submodule setup is pretty confusing and
> I don't do it all that frequently.  When I finally managed to get this done,
> I found that the code that I use to review the results (tools/regression)
> has been removed from the master branch.  Of course this was a surprise to
> me!  Apparently I'm the only one that uses this code (not a huge surprise,
> I'm not sure why though).  So now I have to remember how to get this thing
> built again and figure out where I'm going to keep it.
>
> So all in all this ends up taking a lot more time than one would expect.
>
> You might ask - why not just merge develop into master and watch the test
> results?  I would answer that I've learned the hard way that taking a
> "shortcut" can lead to repercussions which such up lots, lots more time.
> Even investing the effort above, the bug that provokes this email still
> managed to creep in and was not detected by my tests.
>
> Note that all the above doesn't actually include the time finding reported
> bugs.  These are pretty infrequent these days - but are often a major bitch
> to reproduce, find and fix. Often they are artifacts of standard library
> implementations which are very time consuming to track down.
>
> I hope that answer's your question.
>
> Robert Ramey
Hi Robert,

Thank you for your reply. I am reading all replies and comments but 
right now I do not see that I can propose anything to help the current 
situation or to "relieve the burden", other then waiting patiently until 
this is done. In general it seems to be a bit problematic to actually 
help boost overall. Maintainers seem to have a very high workload (which 
only very few people would accept to do besides work) and there is not 
much one can do to help. Squashing bugs is one thing. If the merging and 
testing part takes 200h this is something i would not be able to do.

So what do you guys think: is there something one can do with a 
reasonable workload ~20h/month to help the overall situation?