|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk