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
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.