Re: [boost] A bike shed (any colour will do) on greener grass...

Subject: Re: [boost] A bike shed (any colour will do) on greener grass...
From: Peter Dimov (lists_at_[hidden])
Date: 2013-10-31 08:54:04

Ahmed Charles wrote:
> > AMDG
> >
> > On 10/30/2013 06:07 AM, Ahmed Charles wrote:
> > >
> > > Short of boost being forked by a group of energetic people interested 
> > > in making massive changes, how exactly will it ever migrate to 
> > > C++11/14 with the current ownership model where people have to contact 
> > > ~100 library maintainers if they want to make changes across the 
> > > entire project? If all I wanted to do was create a branch to work on 
> > > C++11/14 work or anything like it, not only would it require touching 
> > > ~100 git repos, I'd have to send ~100 emails and create ~100 trac 
> > > tickets with patches and then manage ~100 different conversations with 
> > > ~100 different people, across different countries, timezones, native 
> > > languages, cultures, etc. How do you ever expect anyone to ever want 
> > > to do that?
> >
> > Your scenario is completely unrealistic in the
> > first place.  No one can make these kinds of
> > sweeping changes in one shot without making serious
> > errors.  It simply isn't possible to understand
> > all of boost at once at the level of detail
> > needed to make major modifications correctly.
>
> Proving that something isn't possible is really hard. I didn't what the 
> scope of the changes would be, ...

If you're doing any kind of serious work, the time investment per library 
will dwarf the effort of filing a ticket and sending an e-mail. For it not 
to do so, the work needs to be either superficial or heavily automated. Even 
then, to be sure that the massive changes haven't broken anything, you'd 
need to run the entire test suite after each round of changes. This wouldn't 
be any fun, either.

It doesn't even matter. The process is not as inflexible as you think. 
Filing a ticket and notifying the maintainer is a matter of courtesy and 
respect, it's not a requirement. If you're good enough so that your changes 
are entirely beneficial, nobody will object.

But that doesn't matter, either. The process is emergent from the structure 
of Boost in which maintainers are responsible for their libraries. This 
means that if your massive changes introduce bugs in some library, it will 
be the maintainer of that library who will have to deal with the bug 
reports. This naturally tends to make (active) maintainers somewhat 
protective.

This all works fairly well in practice, if your measure working by the 
actual results. Stephen Kelly's situation is unique and one-off, because of 
the impending transition to Git. Normally, we'd do things in our 
old-fashioned, non-energetic, inflexible way across a few releases without 
entering the news.