|
Boost : |
Subject: [boost] [git] What about unmaintained libraries?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-12-24 01:51:13
Hi,
I have little experience with git and none with GitHub, so apologies
if my questions sound silly.
We have a number of unmaintained libraries in Boost. With svn anyone
with commit rights can apply fixes and even take over these libs. In
the end of the day, I think, this is a good thing - community support
is better than no support. Even with maintained libs, it is sometimes
simpler to just apply the fix instead of filing a ticket and waiting
for the maintainer to get to it. Also, remember the bug fixing weeks
we had a while ago - anyone could choose a library and resolve tickets
against it.
I'm not sure how this will work after transition to git. IIUC, every
lib will be extracted into a separate git repository, and presumably
only the library maintainer will have the commit rights to that repo.
Essentially this means that unmaintained libs will become immutable
after the transition. Also, every minor fix will have to go through
the library maintainer, however busy he may be.
I suppose the problem with unmaintained libs could be solved by
forking but what if noone is ready to become the official maintainer
but occasionally people commit fixes and improvements to the lib? I
believe, at least Boost.DateTime is currently in such situation. Also,
forking does not solve the problem for minor fixes to maintained libs.
I would really like it if there was some kind of a user group (of all
Boost maintainers) that could be used to grant commit rights to the
libraries. Whatever the git term is, by "commit" here I mean the
ability to publish the changes to the repository on GitHub, so that
they are visible to other developers, including monolithic Boost
release scripts. Is this possible? If yes, I think all repositories
produced as a result of the transition to git should grant commit
rights to this group by default, so that the access rights are the
same as with svn now.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk