[git] What about unmaintained libraries?
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.
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
on Mon Dec 24 2012, Beman Dawes <bdawes-AT-acm.org> wrote:
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.
On that page: "The Git community has a usual way of submitting changes upstream. See GitHub's description of the process" Actually, major parts of that description are GitHub-specific. "Forking" a repository on GitHub is similar to cloning a repository with git, except that GitHub remembers the relationship between the repositories. A "pull-request" (https://help.github.com/articles/using-pull-requests) provides a convenient web interface for submitting changes to a repository you've "forked." It also allows you to amend those changes before they are incorporated upstream; if you request a pull on a symbolic reference (like a branch), any changes to that reference made before the request is accepted upstream will become part of that pull. That can be a surprising effect. If you want to avoid it, you might use tags or dedicated branches for pull requests. GitHub also makes it easy to submit small changes upstream by providing an "Edit" button (if you're logged in) on the browser for any given file. That button will cause GitHub to fork the repository for you (if you don't already have a fork) and set up a new branch for the changes you make. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
On 24/12/12 20:09, Dave Abrahams wrote:
A "pull-request" (https://help.github.com/articles/using-pull-requests) provides a convenient web interface for submitting changes to a repository you've "forked."
You can also emit pull requests between branches of the same repository.
It also allows you to amend those changes before they are incorporated upstream; if you request a pull on a symbolic reference (like a branch), any changes to that reference made before the request is accepted upstream will become part of that pull. That can be a surprising effect. If you want to avoid it, you might use tags or dedicated branches for pull requests.
Pull requests should always be done from topical branches.
Thank you for the clarifications, Beman. On December 24, 2012 8:42:10 PM Beman Dawes <bdawes@acm.org> wrote:
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.
So, is the library repo an independent repo on GitHub that is somehow linked to boost-lib (like svn externals), or is it more like a subdirectory within boost-lib? From what you say about permissions it looks like the latter is closer to the truth and in that case it is logical that permissions of owners of boost-lib also apply to the subprojects. But while reading the wiki you wrote I got the impression that each library has its own repo linked to the boost-lib structure. This seemed logical, considering the case when a library is first developed as an independent GitHub project and then linked to boost-lib when reviewed and accepted. If so, each library repo is independent from boost-lib and thus boost-lib permissions no longer apply. Did I get it wrong?
On 24/12/12 21:22, Andrey Semashev wrote:
But while reading the wiki you wrote I got the impression that each library has its own repo linked to the boost-lib structure. This seemed logical, considering the case when a library is first developed as an independent GitHub project and then linked to boost-lib when reviewed and accepted. If so, each library repo is independent from boost-lib and thus boost-lib permissions no longer apply. Did I get it wrong?
Each library has indeed its own repository within the boost-lib organization. As an organization, boost-lib can have shared permissions over all the repositories it hosts.
on Mon Dec 24 2012, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
Thank you for the clarifications, Beman.
On December 24, 2012 8:42:10 PM Beman Dawes <bdawes@acm.org> wrote:
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.
So, is the library repo an independent repo on GitHub that is somehow linked to boost-lib (like svn externals), or is it more like a subdirectory within boost-lib?
http://github.com/boost-lib is the GitHub "organization" (similar to a user) that owns the repositories. It is not itself a repository. http://github.com/boost-lib/boost is a repository that refers to the individual repositories as submodules.
From what you say about permissions it looks like the latter is closer to the truth and in that case it is logical that permissions of owners of boost-lib also apply to the subprojects.
You can read about how GitHub "organization" permissions work on the GitHub website. https://help.github.com/articles/what-are-the-different-access-permissions
But while reading the wiki you wrote I got the impression that each library has its own repo linked to the boost-lib structure.
I don't know what you mean by "linked" or "structure" in this context.
This seemed logical, considering the case when a library is first developed as an independent GitHub project and then linked to boost-lib when reviewed and accepted. If so, each library repo is independent from boost-lib and thus boost-lib permissions no longer apply. Did I get it wrong?
I suggest reading the link above. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
On Wed, Dec 26, 2012 at 12:59 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Mon Dec 24 2012, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
Thank you for the clarifications, Beman.
On December 24, 2012 8:42:10 PM Beman Dawes <bdawes@acm.org> wrote:
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.
So, is the library repo an independent repo on GitHub that is somehow linked to boost-lib (like svn externals), or is it more like a subdirectory within boost-lib?
http://github.com/boost-lib is the GitHub "organization" (similar to a user) that owns the repositories. It is not itself a repository. http://github.com/boost-lib/boost is a repository that refers to the individual repositories as submodules.
From what you say about permissions it looks like the latter is closer to the truth and in that case it is logical that permissions of owners of boost-lib also apply to the subprojects.
You can read about how GitHub "organization" permissions work on the GitHub website. https://help.github.com/articles/what-are-the-different-access-permissions
Thanks, this seems like what I've been missing.
participants (4)
-
Andrey Semashev -
Beman Dawes -
Dave Abrahams -
Mathias Gaunard