Re: [boost] [git] What about unmaintained libraries?

Subject: Re: [boost] [git] What about unmaintained libraries?
From: Beman Dawes (bdawes_at_[hidden])
Date: 2012-12-24 11:42:10

On Mon, Dec 24, 2012 at 1:51 AM, Andrey Semashev
<andrey.semashev_at_[hidden]> 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