Re: [boost] [1.37.0] branches/release open for merges

From: Gennaro Prota (gennaro.prota_at_[hidden])
Date: 2008-08-21 06:18:18

Daniel James wrote:
> On 21/08/2008, Gennaro Prota <gennaro.prota_at_[hidden]> wrote:
>>> There also doesn't seem to be anyone willing to maintain the extra
>>> branches or point releases. And some boost developers don't seem very
>>> keen on working with multiple branches. If we had a culture of shared
>>> code ownership, we might be able to make up for that.
>>>
>>  What do you mean by "culture of shared code ownership"?
> 
> In general (this is a gross generalisation, there are plenty of
> exceptions) a library is maintained by one or two people and if there
> is a problem it's up to them to solve it. In a culture of shared
> ownership (I'm already embarrassed about using that phrase) people
> would be feel more responsibility for other's people libraries.

I have to say that sometimes I walk through the open tickets and say 
"hey, let's fix this... it's easy and the maintainer is probably just 
busy"; but usually --and here I'm speaking for myself and my own 
psychology-- either I give up knowing that nobody would appreciate the 
work, or I *have* to give up given code complexity (who wants to touch 
things like 
BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC2_2_1_A_QUARTER_TO_NINE_IN_BETWEEN_IMPL_WITH_BARRIER)

> Because most tasks are up to the individual library maintainers we can
> only do what they are willing to do. We have good unit tests, because
> maintainers are willing to write them. But individual developers don't
> seem willing to maintain multiple branches - which puts the burden
> onto the people who are (i.e. Beman). I don't want to put down
> anyone's contribution. I'm just trying to explain the problems that I
> see with maintaining multiple branches.

Yes. That's fair, IMHO. I for one I'm not willing to "overwork", 
simply because that isn't recognized here on Boost. There are other 
communities were you feel much more "part of the play". I'd not bring 
the case of dynamic_bitset up again, but when I took the library over 
it was *terrible*; lot of functions didn't even compile (they were 
never instantiated) and most of them had bugs; some are still 
ill-specified, because I didn't get any feedback from the list as to 
how the definition might have been changed. See what the library is 
now: it doesn't reflect my style and my ideas about software 
development but it's one of the most stable and bug-free boost 
libraries. I think it didn't get any real bug report since its rewrite 
in 2004 (IIRC). Note, too, that here on the list there are people who 
happily acknowledge everyone's contributions (even too much; I've got 
a couple of credits from Beman where I hardly commented on a few 
trifles :-)) and people who tend to think they are the only ones who 
did the real thing (wasn't it me the person suggesting the 
implementation of BOOST_WORKAROUND, for instance? or implicit_cast? or...)

Believe me, I don't mind about the specific cases above; I'm just 
explaining what the consequence is: your willing to contribute 
decreases, even though you certainly didn't contribute with the goal 
of getting credit in the first place (personally I just like the 
technical challenge)

-- 
Genny