On Mon, Dec 24, 2012 at 1:51 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Hi,
I have little experience with git and none with GitHub, so apologies if my questions sound silly.
There is nothing silly about your questions! Getting this stuff documented is part of moving to Git and GitHub.
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.
AFAIK, we will use same procedure (see below) as for maintained libraries, but it will be someone with global write permissions who applies the pull request.
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've added a FAQ entry "How do I submit fixes to a Boost library owned by someone else?". See https://svn.boost.org/trac/boost/wiki/ModCvtFAQ.
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.
All public repos are part of boost-lib, so those that have overall write permission for https://github.com/boost-lib can modify any component library's public repo, and that includes apply changes to permissions as well as changes to the actual library.
Also, every minor fix will have to go through the library maintainer, however busy he may be.
Every library repo sets its own policies, so some will have more maintainers than others. GitHub is known to scale well. My (limited, so far) experience with Git and GitHub pull requests is that they are so easy to handle that there is a big incentive to stay on top of them.
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.
If you look at https://github.com/boost-lib and click on the "members" tab, hopefully you can see who has top level access. In general we don't need to work out our own procedures because the Git community has already come up with effective ways to handle the issues you are raising. It is more a case of needing to communicate those procedures, and get them documented. I'm trying to make progress quickly on documentation by doing a lot of linking to material that is already out there. HTH, --Beman