Re: [boost] Release sponsorship (was: Re: Boost 1.58 schedule available?)

Subject: Re: [boost] Release sponsorship (was: Re: Boost 1.58 schedule available?)
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-01-23 01:47:55

Niall Douglas wrote
> I always felt the Community Maintenance Team should have been
> configured as a bounty based system. If someone needs an unmaintained
> library to be maintained in some way, then they stump up a bounty for
> it. Note by unmaintained I would cast the net to include libraries
> with maintainers, though in that case the maintainer gets a veto. I
> also think the maintainer should get first dibs to the bounty too,
> they already have thankless jobs.
> 
> This could be seen as creating incentives to not maintain libraries.
> I'm happy with that - software is expensive. I wouldn't go so far as
> holding users to ransom for fixes on payment though.

I've never been convinced of the Community Maintenance Team 
approach.  I believe that the incentives are all wrong to make it
effective.  I will be offering an alternative aproach.  A glimpse of
this alternative can be seen looking at the library page for Safe Numeric
in the incubator.

But let's not discuss this here - it's not relevant to the question at hand.

As a reminder - I maintain that the merge from develop into master
is a trivial operation.  If anyone is finding this not to be the case, they
are not doing right.

>> > Regarding releases, they are highly disruptive to the develop branch
>> > as basically one has to down tools on feature work and spend an age
>> > iterating fixing up master branch such that all the other master
>> > branches in all the other submodules play well together on all
>> > supported platforms.
>> >
>> > For quickly moving libraries such as Thread, I
>> > can see four weeks per release being lost. Increasing release
>> > frequency increases that cost substantially.
>>
>> If this is the case, then something is not right and needs to be
>> addressed.  It's hard for me to comment on your particular case without
>> spending a lot of time looking at the details,  but I can speak from
>> the experience of maintaining the serialization library over many years
>> through several different Source Control systems and several different
>> workflows.  My current view is that our issues with with these things
>> are now largely solved and we are in a good position to take boost
>> to the next level - whatever that might.
> 
> With respect Robert, Serialization has nothing like the amount of
> code intricately dependent on it behaving exactly in some way,
> including in ways it was broken in the past. 

I doubt this - but it's irrellevant.

My proposition is that merging from development to master is 
trivial operation.  If it isn't for you, then you're doing something
wrong.  The difficulties or peculiarities of any particular library are
irrelevant to my view and my argument.

Thread offers no less than four versions ....
... snip...
all the difficulties about working with boost thread, yada, yada, yada...

>> > Hence I do wish there was a facility for sponsors to sponsor a merge
>> > of develop to master. If this had been the case for Boost.Test, would
>> > its develop branch have remained unmerged for so many years? No, I
>> > think someone would have done the merge if $5000 were on the table
>> > for it.
>>
>> Again, if merging from develop to release is a big problem, someone is
>> doing something wrong.  It should be almost trivial.  As such
>> it doesn't need any financial incentive.  In fact, financial incentive
>> would
>> be the worst thing - it would be encouraging the continuance of a
>> some sort of broken workflow.
> 
> master branch is special with Boost though. It's not just the "unit
> tests pass here" branch, but also the branch used to generate Boost
> release.

LOL - one might say it's special.  But merging one's current develop
branch into the master is a trivial operation.  If it's not then he's
doing wrong.

Or possibly when he says "merging the develop branch" into the
"master" he's referring to other stuff like debugging code while it's
in develop or who know what else. This other stuff has nothing to
do with merging the develop branch into the master branch.

> That means writing code and merging is 50% of the effort of merging
> develop to master. 

LOL - we're not communicating.  merging develop into master should
require absolutely no coding.  At the end of the operation for the library
in question the code in the master should be bit for bit identical to 
code in the develop branch - that is all that the merge does.
(could be a slight simplification if multiple authors are working on
the same library and the authors are conflicting - but would be an
extremely rare case here so I'm ignoring it).

I finished AFIO v1.3 some weeks ago, but I haven't
merged from develop to master yet despite all unit tests being green
apart from Mingw32, which I am going to drop support for (Mingw-w64
works, Mingw32 is just horribly broken). That's because for a merge
to release branch I have yet to do:

1. Update documentation to reflect the new facilities, and indeed
your Incubator review where I believe I have addressed the majority
of your concerns at least partially. I've been at this for nearly
three weeks now. You only get so much time outside of work.

2. Rewrite the design rationale as it is now quite stale given my
recent empirical testing findings.

3. Add unit test targets for Android 5.0 which now supports C++ 11.
Fix any failures.

4. Add more tests to improve line coverage as I know it's dipped
below 90%.

5. Run compilation time benchmarks on all platforms. Fix any
regressions. You might think this easy, but AFIO has about twenty
different build configurations now.

6. Run performance benchmarks on all platforms. Fix any regressions.

> So actually, you're not done developing.  It's not the merge to master
> which is holding you up, it's finishing the development on the develop
> branch.  If Boost were to release the current master friday - things
> would be as they were - your changes just would appear later in the
> next release.  So if you that friday is "too soon" what you're really
> asking is that users of other libraries be denied the upgrades they've
> be waiting for so you you can ... deliver your stuff later?  Where is
> the logic in that?  If your not ready - let everyone else deliver.  If
> you are then you've got no problem.
> 
> You just develop at your own pace and merge to master when you're
> done.  

I had been hoping to merge to master for end of January, it's
currently looking like mid-February.

water for my mill

>> Personally I think the problems of "maintenance" are over stated. If
>> maintaining (as opposed to adding features) is a lot of work, one needs
>> to step back and look at what he's doing wrong and think about how
>> to change it.
> 
> I think a huge amount depends on how legacy your codebase is and how
> tightly other people's code depends on yours being exactly as before.

if you're not changing the library interface then there is no problem.  
Including/not including one's changes won't make a difference.

If you're changing an existing interface then we have a whole new problem.
This new problem won't be made better or worse by delaying a release
to meet the schedule/problems of a specific library.

> I'll put it another way: QNX and Microsoft expend enormous resources
> making sure all future versions of their software have identical
> behaviour to before when in some form of compatibility mode. There is
> a big customer demand for that sort of "reliability", and people
> willing to pay serious bucks for it.

LOL - well boost customers haven't seem willing - so far at least.  Maybe
that can change but for now that's the way it is.

>> One final thought.  How about using the "surprise release" © model?
>> This one is someone looks at all the test matrices for all the libraries.
>> When they (almost) all look good.  The release is announced and the
>> release branch is closed to updates except for any pending errors.  No
>> new features, etc.  The the release is no work for developers at all!!!!
>> I know this sounds like I'm trying to be funny, but I consider this a
>> serious proposal.
> 
> I am not a fan of this model. The Web 2.0 culture does this a lot,
> but they provide services which can and are remotely updated if
> showstoppers turn up. When you ship a library on the other hand, that
> release is probably going to turn into stone in someone else's code.

This is not the web 2.0 model which is basically, just ship it and let
the customers test it, when they find problems we'll just ship them
a "service pack".

This is entirely different.  This is:code in the master has been test
to the point where it has no known bugs. It is deemed ready to be
used by users.  This is true irregardless of whether it has been
shipped as Boost 1.xx.  Any code which does not meet this standard
can be found on the develop or some other branch.

It's really just that simple.

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-58-schedule-available-tp4671426p4671555.html
Sent from the Boost - Dev mailing list archive at Nabble.com.