[git] Why are we using Github (was: The any library does not pull cleanly because of a forced update on develop and master)
On Tue, Dec 10, 2013 at 7:40 AM, Dave Abrahams <dave@boostpro.com> wrote:
"Cox, Michael" <mhcox@bluezoosoftware.com> writes:
I tried to update my local repositories to the latest changes in each submodule:
git pull; git submodule foreach --recursive git pull
When it got to the libs/any submodule, I got the following message:
remote: Counting objects: 27, done. remote: Compressing objects: 100% (2/2), done. remote: Total 6 (delta 2), reused 6 (delta 2) Unpacking objects: 100% (6/6), done. From https://github.com/boostorg/any + 3f0b981...e3e5da6 develop -> origin/develop (forced update) + 38039b3...d35b2d6 master -> origin/master (forced update) * [new tag] 20131209-develop -> 20131209-develop * [new tag] 20131209-master -> 20131209-master
and my editor popped up with a merge commit message to edit. I think that's because the develop and master branches were force updated, re-writing history in develop and master.
If there is not already a policy in place to prevent history rewriting in public branches, we should have one. And if there's a GitHub mechanism for denying the privilege, it should be enabled.
There may be a policy, but as far as I can tell, Github has no easy interface to allow you to enforce it, i.e. set the receive.denyNonFastForwards=true and receive.denyDeletes=true (for all branches) or branch.name>.mergeoptions=--ff-only (setting up fast forward only per branch). Maybe via plugin (like I assume the trac plugin is being used to integrate boost's trac web-site)?
From the git-config man page: receive.denyNonFastForwards
If set to true, git-receive-pack will deny a ref update which is not a fast-forward. Use this to prevent such an update via a push, even if that push is forced. This configuration variable is set when initializing a shared repository. receive.denyDeletes If set to true, git-receive-pack will deny a ref update that deletes the ref. Use this to prevent such a ref deletion via a push. branch.<name>.mergeoptions Sets default options for merging into branch <name>. The syntax and supported options are the same as those of git-merge(1), but option values containing whitespace characters are currently not supported. The last one I'm not sure if it works on the server side. It may be a client side only configuration item. I have seen examples of adding hooks to enforce such restrictions. Which brings me to a question I've been wanting to get answered: why was Github chosen in the first place? I know it's the 900-lb gorilla in public git repository hosts, but I think Bitbucket allows so much more flexibility in configuring your repositories: - Individual branches and wild-card refs can be configured with who is allowed to commit (which can be a group). - Individual branches can be designated as not deletable. - Individual branches can be designated as not rewritable. See Take control with branch restrictions<http://blog.bitbucket.org/2013/09/16/take-control-with-branch-restrictions/> for more info. If we are still in the acceptance phase of the git conversion (based on some of the comments in the thread this was taken from), maybe we should reconsider Github? What were the advantages of Github vs. other public repositories like Bitbucket? Michael
-Dave
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 11/12/13 23:19, Cox, Michael wrote:
If we are still in the acceptance phase of the git conversion (based on some of the comments in the thread this was taken from), maybe we should reconsider Github? What were the advantages of Github vs. other public repositories like Bitbucket?
I believe the reason Github was chosen is that it is perceived that Github has better social features for code review, pull requests etc. Before considering moving to Bitbucket, I recommend simply asking the Github team whether it's possible to add restrictions on a case by case basis.
On 12 December 2013 11:12, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 11/12/13 23:19, Cox, Michael wrote:
If we are still in the acceptance phase of the git conversion (based on some of the comments in the thread this was taken from), maybe we should reconsider Github? What were the advantages of Github vs. other public repositories like Bitbucket?
I believe the reason Github was chosen is that it is perceived that Github has better social features for code review, pull requests etc.
Pull requests, as well as code review (inline comments) are closely related to the Issues at GitHub. Boost won't use the Issues though. That, I think, may be very confusing to anyone who wants to participate in Boost development and is used to overall GitHub environment. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net
On Thu, Dec 12, 2013 at 6:12 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 11/12/13 23:19, Cox, Michael wrote:
If we are still in the acceptance phase of the git conversion (based on some of the comments in the thread this was taken from), maybe we should reconsider Github? What were the advantages of Github vs. other public repositories like Bitbucket?
I believe the reason Github was chosen is that it is perceived that Github has better social features for code review, pull requests etc.
IIRC, the conversion team started out using other hosts (Gitorious? Bitbucker?) but switched to Github because of problems they encountered with the other sites.
Before considering moving to Bitbucket, I recommend simply asking the Github team whether it's possible to add restrictions on a case by case basis.
+1 --Beman
Before considering moving to Bitbucket, I recommend simply asking
On 12 Dec 2013 at 11:00, Beman Dawes wrote: the
Github team whether it's possible to add restrictions on a case by case basis.
+1
I think such special casing unlikely - being able to overwrite history is sometimes essential [1] which is why Github allows it, and it is expected that git users know not to do it except as an absolute last resort because it buggers everyone with a copy of that branch in their clones. BTW if you DO do it, you're expected to preannounce the fact to a dev mailing list with sufficient notice and put it in big letters in the docs and changelog. Regarding forcing people to behave, well you can't, except by the usual mechanism of only submoduling the commit SHAs which Boost master has approved of. [1]: An example of where it's necessary? When you need to purge a commit which contained proprietary code for example, and someone only just realised that now we're accidentally hosting copies of third party code for which we're about to get sued ... Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On Thu, Dec 12, 2013 at 9:22 AM, Niall Douglas <s_sourceforge@nedprod.com>wrote:
On 12 Dec 2013 at 11:00, Beman Dawes wrote:
Before considering moving to Bitbucket, I recommend simply asking the Github team whether it's possible to add restrictions on a case by case basis.
+1
I think such special casing unlikely - being able to overwrite history is sometimes essential [1] which is why Github allows it, and it is expected that git users know not to do it except as an absolute last resort because it buggers everyone with a copy of that branch in their clones. BTW if you DO do it, you're expected to preannounce the fact to a dev mailing list with sufficient notice and put it in big letters in the docs and changelog.
+1 But I think that thought needs to be expressed somewhere on the web-site/official policy. Michael
2013/12/12 Beman Dawes <bdawes@acm.org>:
On Thu, Dec 12, 2013 at 6:12 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 11/12/13 23:19, Cox, Michael wrote:
If we are still in the acceptance phase of the git conversion (based on some of the comments in the thread this was taken from), maybe we should reconsider Github? What were the advantages of Github vs. other public repositories like Bitbucket?
I believe the reason Github was chosen is that it is perceived that Github has better social features for code review, pull requests etc.
IIRC, the conversion team started out using other hosts (Gitorious? Bitbucker?) but switched to Github because of problems they encountered with the other sites.
The problem with Gitorious was the performance and Bitbucket did not exist when this decision was made. The reasons why GitHub was picked may be outdated. Our Boost-Jenkins has pushed the modularized repositories to both GitHub and Bitbucket.
Before considering moving to Bitbucket, I recommend simply asking the Github team whether it's possible to add restrictions on a case by case basis.
+1
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Beman Dawes wrote:
Mathias Gaunard wrote:
Before considering moving to Bitbucket, I recommend simply asking the Github team whether it's possible to add restrictions on a case by case basis.
+1
For what it's worth, Github Enterprise allows you to block force pushes per-repository. Hopefully that means they can, whether they will or not. Nate
On Thu, Dec 12, 2013 at 11:54 AM, Nathan Crookston < nathan.crookston@gmail.com> wrote:
Beman Dawes wrote:
Mathias Gaunard wrote:
Before considering moving to Bitbucket, I recommend simply asking the Github team whether it's possible to add restrictions on a case by case basis.
+1
For what it's worth, Github Enterprise allows you to block force pushes per-repository. Hopefully that means they can, whether they will or not.
Hosting choice isn't just a matter of checklist comparisons. Dave Abrahams has pointed out several times that what really matters is how they behave when the going gets tough and the flood levels are rising.
It will take time to evaluate how GitHub performs for Boost. --Beman
On 12.12.2013 02:19, Cox, Michael wrote:
Which brings me to a question I've been wanting to get answered: why was Github chosen in the first place? I know it's the 900-lb gorilla in public git repository hosts, but I think Bitbucket allows so much more flexibility in configuring your repositories:
- Individual branches and wild-card refs can be configured with who is allowed to commit (which can be a group).
Another problem with github model is that it promotes this fork-and-pull-request model, which then creates a history where every second commit is 'merged pull request N', which is not very useful. On the other hand, many other projects are using gerrit, where contributors clone locally, made changes and then push to a special magic ref on a server, which creates online review. Contributors of course can share their changes by pushing them to other repositories, but in the end, you end up with a clean logical patches to the official repository. Was this model considered for Boost? Thanks, Volodya
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Vladimir Prus Sent: 18 December 2013 07:55 To: boost@lists.boost.org Subject: Re: [boost] [git] Why are we using Github (was: The any library does not pull cleanly because of a forced update on develop and master) On 12.12.2013 02:19, Cox, Michael wrote:
Which brings me to a question I've been wanting to get answered: why was Github chosen in the first place? I know it's the 900-lb gorilla in public git repository hosts, but I think Bitbucket allows so much more flexibility in configuring your repositories:
- Individual branches and wild-card refs can be configured with who is allowed to commit (which can be a group).
Another problem with github model is that it promotes this fork-and-pull-request model, which then creates a history where every second commit is 'merged pull request N', which is not very useful. On the other hand, many other projects are using gerrit, where contributors clone locally, made changes and then push to a special magic ref on a server, which creates online review. Contributors of course can share their changes by pushing them to other repositories, but in the end, you end up with a clean logical patches to the official repository. Was this model considered for Boost? Thanks, Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 18 December 2013 07:55, Vladimir Prus <ghost@cs.msu.su> wrote:
On 12.12.2013 02:19, Cox, Michael wrote:
Which brings me to a question I've been wanting to get answered: why was Github chosen in the first place? I know it's the 900-lb gorilla in public git repository hosts, but I think Bitbucket allows so much more flexibility in configuring your repositories:
- Individual branches and wild-card refs can be configured with who is allowed to commit (which can be a group).
Another problem with github model is that it promotes this fork-and-pull-request model, which then creates a history where every second commit is 'merged pull request N', which is not very useful.
IMHO, we've talked about it on IRC the other day, it may be useful as it helps to find out where things come from. A 'plain' contributed commit does not always carry useful information i.e. bug number it fixes. So, the merge commit is a chance to amend that. Plus, it indicates important detail: *who* let the contribution into the codebase.
On the other hand, many other projects are using gerrit, where contributors clone locally, made changes and then push to a special magic ref on a server, which creates online review. Contributors of course can share their changes by pushing them to other repositories, but in the end, you end up with a clean logical patches to the official repository.
I have been a tiny contributor/lurker to Qt/Qt Creator, and from a contributor POV, their Gerrit system is a huge obstacle for ad-hoc or occasional contributors. Setting up is not easy, learning curve about the whole development workflow is quite steep, and the information is very distributed (no (auto)links between gerrit and their bug reports). For me, it is difficult to simply observe what is happening in the Qt/Qt Creator projects. Whereas on GitHub/BitBucket I can easily monitor lots. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net
On 18.12.2013 13:21, Mateusz Loskot wrote:
On 18 December 2013 07:55, Vladimir Prus <ghost@cs.msu.su> wrote:
On 12.12.2013 02:19, Cox, Michael wrote:
Which brings me to a question I've been wanting to get answered: why was Github chosen in the first place? I know it's the 900-lb gorilla in public git repository hosts, but I think Bitbucket allows so much more flexibility in configuring your repositories:
- Individual branches and wild-card refs can be configured with who is allowed to commit (which can be a group).
Another problem with github model is that it promotes this fork-and-pull-request model, which then creates a history where every second commit is 'merged pull request N', which is not very useful.
IMHO, we've talked about it on IRC the other day, it may be useful as it helps to find out where things come from. A 'plain' contributed commit does not always carry useful information i.e. bug number it fixes. So, the merge commit is a chance to amend that.
I assume we're gonna follow proper commit message guidelines, line here: http://git-scm.com/book/ch5-2.html so the bug being fixed is part of the commit message. (If not, the commit is rejected).
Plus, it indicates important detail: *who* let the contribution into the codebase.
You don't need pull requests for that, see: https://github.com/boostorg/build/commit/5ce453de47ba732f5a88236f302370d7bba... Git has separate information about committer and author, and github displays that.
On the other hand, many other projects are using gerrit, where contributors clone locally, made changes and then push to a special magic ref on a server, which creates online review. Contributors of course can share their changes by pushing them to other repositories, but in the end, you end up with a clean logical patches to the official repository.
I have been a tiny contributor/lurker to Qt/Qt Creator, and from a contributor POV, their Gerrit system is a huge obstacle for ad-hoc or occasional contributors. Setting up is not easy, learning curve about the whole development workflow is quite steep, and the information is very distributed (no (auto)links between gerrit and their bug reports). For me, it is difficult to simply observe what is happening in the Qt/Qt Creator projects.
I don't recall my pain setting up Gerrit for Eclipse. But they do have some kind of cross-linking. - Volodya
On 18 December 2013 09:26, Vladimir Prus <ghost@cs.msu.su> wrote:
On 18.12.2013 13:21, Mateusz Loskot wrote:
On 18 December 2013 07:55, Vladimir Prus <ghost@cs.msu.su> wrote:
On 12.12.2013 02:19, Cox, Michael wrote:
Which brings me to a question I've been wanting to get answered: why was Github chosen in the first place? I know it's the 900-lb gorilla in public git repository hosts, but I think Bitbucket allows so much more flexibility in configuring your repositories:
- Individual branches and wild-card refs can be configured with who is allowed to commit (which can be a group).
Another problem with github model is that it promotes this fork-and-pull-request model, which then creates a history where every second commit is 'merged pull request N', which is not very useful.
IMHO, we've talked about it on IRC the other day, it may be useful as it helps to find out where things come from. A 'plain' contributed commit does not always carry useful information i.e. bug number it fixes. So, the merge commit is a chance to amend that.
I assume we're gonna follow proper commit message guidelines, line here:
http://git-scm.com/book/ch5-2.html
so the bug being fixed is part of the commit message. (If not, the commit is rejected).
OK, that is good indeed.
Plus, it indicates important detail: *who* let the contribution into the codebase.
You don't need pull requests for that, see:
https://github.com/boostorg/build/commit/5ce453de47ba732f5a88236f302370d7bba...
Git has separate information about committer and author, and github displays that.
Yes, that's right, my comment above was lazily expressed. I meant, *who* as there is link to Pull Request where complete cycle of review/updating commit/review is preserved. I know Boost allows use of PRs [1], but not sure if it allows use of corresponding features at GitHub for code reviews, etc. [1] https://svn.boost.org/trac/boost/wiki/StartModPatchAndPullReq
On the other hand, many other projects are using gerrit, where contributors clone locally, made changes and then push to a special magic ref on a server, which creates online review. Contributors of course can share their changes by pushing them to other repositories, but in the end, you end up with a clean logical patches to the official repository.
I have been a tiny contributor/lurker to Qt/Qt Creator, and from a contributor POV, their Gerrit system is a huge obstacle for ad-hoc or occasional contributors. Setting up is not easy, learning curve about the whole development workflow is quite steep, and the information is very distributed (no (auto)links between gerrit and their bug reports). For me, it is difficult to simply observe what is happening in the Qt/Qt Creator projects.
I don't recall my pain setting up Gerrit for Eclipse. But they do have some kind of cross-linking.
I guess it's matter of how Git/Gerrit/bug tracker is set up to play together. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net
On 18.12.2013 16:11, Mateusz Loskot wrote:
Yes, that's right, my comment above was lazily expressed. I meant,*who* as there is link to Pull Request where complete cycle of review/updating commit/review is preserved.
You have a point here.
I know Boost allows use of PRs [1], but not sure if it allows use of corresponding features at GitHub for code reviews, etc.
[1]https://svn.boost.org/trac/boost/wiki/StartModPatchAndPullReq
Regretfully what Linus said about GitHub pull requests, here: https://github.com/torvalds/linux/pull/17#issuecomment-5654674 rings very true to me. - Volodya
On 18 December 2013 12:32, Vladimir Prus <ghost@cs.msu.su> wrote:
On 18.12.2013 16:11, Mateusz Loskot wrote:
I know Boost allows use of PRs [1], but not sure if it allows use of corresponding features at GitHub for code reviews, etc.
[1]https://svn.boost.org/trac/boost/wiki/StartModPatchAndPullReq
Regretfully what Linus said about GitHub pull requests, here:
https://github.com/torvalds/linux/pull/17#issuecomment-5654674
rings very true to me.
Those are good points, I second that. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net
On 12/18/2013 01:32 PM, Vladimir Prus wrote:
On 18.12.2013 16:11, Mateusz Loskot wrote:
Yes, that's right, my comment above was lazily expressed. I meant,*who* as there is link to Pull Request where complete cycle of review/updating commit/review is preserved.
You have a point here.
I know Boost allows use of PRs [1], but not sure if it allows use of corresponding features at GitHub for code reviews, etc.
[1]https://svn.boost.org/trac/boost/wiki/StartModPatchAndPullReq
Regretfully what Linus said about GitHub pull requests, here:
https://github.com/torvalds/linux/pull/17#issuecomment-5654674
rings very true to me.
+1 the whole GitHub "public" Fork to do Pull Request deal seams a bit heavy handed to me. I have no real experience in using it though. In addition if half of what Linus is concerned about has bearing on Boost, then there are reasons to consider alternatives to GitHub Pull Requests IMHO. -- Bjørn
On 12/18/2013 11:22 AM, Bjørn Roald wrote:
On 12/18/2013 01:32 PM, Vladimir Prus wrote:
On 18.12.2013 16:11, Mateusz Loskot wrote:
I know Boost allows use of PRs [1], but not sure if it allows use of corresponding features at GitHub for code reviews, etc.
[1]https://svn.boost.org/trac/boost/wiki/StartModPatchAndPullReq
Regretfully what Linus said about GitHub pull requests, here:
https://github.com/torvalds/linux/pull/17#issuecomment-5654674
rings very true to me.
+1
the whole GitHub "public" Fork to do Pull Request deal seams a bit heavy handed to me. I have no real experience in using it though. In addition if half of what Linus is concerned about has bearing on Boost, then there are reasons to consider alternatives to GitHub Pull Requests IMHO.
As I read that thread, much of what he objected to was github's web commit interface making it difficult/impossible for contributions to conform to the kernel patch standards, and that github pull requests did not meet his work flow requirements. The first part is eliminated if the developer pushes to a github fork using standard git commands; then the pull request is simply a notification of a proposed submission, which must still conform to the upstream project's expectations. The second is only relevant if Boost maintainers adopt Torvald's email-oriented workflow. My experience with using github forks to interact with upstream projects/downstream contributors has been that it is convenient to both submitter and reviewer, since a cursory inspection can be done on the web without integrating a mailer with one's development environment or having to pull the changes into a local workspace. The ability to provide comments in context with specific commits is also valuable. Is there a proposal for an alternative Boost pull-request protocol (specifically notification of submission, access to submission, and medium for providing feedback on submission) that we could weigh against github pull requests? I'd prefer not to have to submit zip files, or hunt through mail archives to find discussion related to an patch that was written nine months ago and accepted six months ago. Peter
On 19/12/2013 07:08, Quoth Peter A. Bigot:
As I read that thread, much of what he objected to was github's web commit interface making it difficult/impossible for contributions to conform to the kernel patch standards, and that github pull requests did not meet his work flow requirements.
The first part is eliminated if the developer pushes to a github fork using standard git commands; then the pull request is simply a notification of a proposed submission, which must still conform to the upstream project's expectations. The second is only relevant if Boost maintainers adopt Torvald's email-oriented workflow.
My experience with using github forks to interact with upstream projects/downstream contributors has been that it is convenient to both submitter and reviewer, since a cursory inspection can be done on the web without integrating a mailer with one's development environment or having to pull the changes into a local workspace. The ability to provide comments in context with specific commits is also valuable.
+1 Most of his remarks are how GitHub isn't suited to the Linux-kernel-specific workflow, and aren't really relevant to any other projects. And about the word wrapping, he's just *wrong*. :)
On 19 Dec 2013 at 11:41, Gavin Lambert wrote:
Most of his remarks are how GitHub isn't suited to the Linux-kernel-specific workflow, and aren't really relevant to any other projects.
Mmm ... github's present design is pretty good for smaller more informal projects, but it doesn't scale out well. I am unsure if Boost is big enough at the per library level to see any such scaling problems though. I think the scaling problems will occur only in changes to those libraries which have a ton of dependencies, because the new modular system currently scales out change ripple control very badly. I think Linus is mostly annoyed that there isn't a toggle for an advanced pull request UI for github, because with very little extra work (a few extra form fields with the signer etc) you'd be a lot closer to good enough.
And about the word wrapping, he's just *wrong*. :)
I get his point about not being able to easily mix up commentary (72 char wrap) with source code quotes (no wrap). A lot of github issues I see contain patches which are utterly useless after github has mangled them. Why github so mangles text in so many inconsistent ways depending on which part of github you're in I really don't get, and on that I definitely agree with Linus. A simple rich text editor could fix all these problems. But, then, so could structured text support for commit messages in git, and Linus could very easily arrange that :) Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 19/12/2013 14:30, Quoth Niall Douglas:
I think Linus is mostly annoyed that there isn't a toggle for an advanced pull request UI for github, because with very little extra work (a few extra form fields with the signer etc) you'd be a lot closer to good enough.
That's true. And Boost might be at a scale where it will want to use signed commits (though personally I think that attributing it to the maintainer who finally pushes it is probably sufficient, since presumably they're well-known and are warranting a change as tested and/or approved -- and should know how to find the original submitter if not self-generated).
And about the word wrapping, he's just *wrong*. :)
I get his point about not being able to easily mix up commentary (72 char wrap) with source code quotes (no wrap). A lot of github issues I see contain patches which are utterly useless after github has mangled them. Why github so mangles text in so many inconsistent ways depending on which part of github you're in I really don't get, and on that I definitely agree with Linus.
The solution there is to simply not wrap commentary at all. 72 char wrap is arbitrary and completely wrong in most cases other than Ye Olde Terminal Window (and sometimes even there). Wrapping should only occur at the very last UA presentation level and not be preserved when submitting. (Which is NOT the same thing as stripping or reconstructing newlines, which is worse.) This does require something in the editor itself to indicate which lines are code lines and not supposed to be wrapped at all, but most editors and/or markup formats have some way to indicate that. Even in email, which is hard-word-wrapped by convention, there are standards to indicate which newlines are soft and which are hard, such as format=flowed, where [SP][NL] indicates a soft newline that should be removed by the UA and allowed to word-wrap. Though he's right that GitHub's web-based editor doesn't seem to support that for the commit message itself, despite supporting it for the actual file edits. But it's not hard to manually wrap code to keep it readable, leaving commentary to auto-wrap. (And it's fairly rare to put code in the commit message anyway, isn't it?)
On 12/18/2013 07:08 PM, Peter A. Bigot wrote:
On 12/18/2013 11:22 AM, Bjørn Roald wrote:
On 12/18/2013 01:32 PM, Vladimir Prus wrote:
On 18.12.2013 16:11, Mateusz Loskot wrote:
I know Boost allows use of PRs [1], but not sure if it allows use of corresponding features at GitHub for code reviews, etc.
[1]https://svn.boost.org/trac/boost/wiki/StartModPatchAndPullReq
Regretfully what Linus said about GitHub pull requests, here:
https://github.com/torvalds/linux/pull/17#issuecomment-5654674
rings very true to me.
+1
the whole GitHub "public" Fork to do Pull Request deal seams a bit heavy handed to me. I have no real experience in using it though. In addition if half of what Linus is concerned about has bearing on Boost, then there are reasons to consider alternatives to GitHub Pull Requests IMHO.
As I read that thread, much of what he objected to was github's web commit interface making it difficult/impossible for contributions to conform to the kernel patch standards,
Are you saying none of the problems with the web commit interface apply to Boost? In that case there is no worry. And boost authors does not have to encourage or allow use of the web interface anyway.
and that github pull requests did not meet his work flow requirements.
Are you saying none of the problems with the web commit interface apply to Boost? In that case there is no worry.
The first part is eliminated if the developer pushes to a github fork using standard git commands; then the pull request is simply a notification of a proposed submission, which must still conform to the upstream project's expectations. The second is only relevant if Boost maintainers adopt Torvald's email-oriented workflow.
Well. I read that he is concerned about: real explanation, proper email addresses, proper shortlog, and proper diffstat. Why is those relevant only to Torvald's email-oriented workflow? He also says: " github identities are random, I expect the pull request to be a signed tag, so that I can verify the identity of the person in question." Why is that relevant only to Torvald's email-oriented workflow? If we depend 100% on GitHub login for identification and authentication, would not that be a tie-up that make it harder to use alternative tools even though they may be superior for certain tasks or as GitHub replacement or redundant hosting?
My experience with using github forks to interact with upstream projects/downstream contributors has been that it is convenient to both submitter and reviewer, since a cursory inspection can be done on the web without integrating a mailer with one's development environment or having to pull the changes into a local workspace. The ability to provide comments in context with specific commits is also valuable.
Good points that could make GitHub features stand up against alternatives that are less convenient with these regards.
Is there a proposal for an alternative Boost pull-request protocol (specifically notification of submission, access to submission, and medium for providing feedback on submission) that we could weigh against github pull requests?
In this thread and elsewhere people have asked if gerrit http://code.google.com/p/gerrit/ have been or, should be considered. I am not sure that count as a proposal. Also it is a question if Boost policies should enforce or at least encourage all libraries to use the same tools, I think it make a lot of sense to do so.
I'd prefer not to have to submit zip files,
+1 or hunt through mail archives to find discussion related to an
patch that was written nine months ago and accepted six months ago.
+1 -- Bjørn
On Thu, Dec 19, 2013 at 12:10 AM, Bjørn Roald <bjorn@4roald.org> wrote:
Well. I read that he is concerned about: real explanation, proper email addresses, proper shortlog, and proper diffstat.
Why is those relevant only to Torvald's email-oriented workflow?
At some point in the discussion he explains that there are, among other things, legal reasons to these requirements.
On 18 December 2013 07:55, Vladimir Prus <ghost@cs.msu.su> wrote:
On the other hand, many other projects are using gerrit, where contributors clone locally, made changes and then push to a special magic ref on a server, which creates online review. Contributors of course can share their changes by pushing them to other repositories, but in the end, you end up with a clean logical patches to the official repository.
I have no experience with gerrit, but I worry about server maintenance - Trac is neglected nowadays, and I had to upgrade the wordpress installation on the server to close some serious security holes in older versions.
On 18.12.2013 16:29, Daniel James wrote:
On 18 December 2013 07:55, Vladimir Prus <ghost@cs.msu.su> wrote:
On the other hand, many other projects are using gerrit, where contributors clone locally, made changes and then push to a special magic ref on a server, which creates online review. Contributors of course can share their changes by pushing them to other repositories, but in the end, you end up with a clean logical patches to the official repository.
I have no experience with gerrit, but I worry about server maintenance - Trac is neglected nowadays, and I had to upgrade the wordpress installation on the server to close some serious security holes in older versions.
Do you mean having available hardware, or manual effort to keep servers running? There are at least two issues where some more server-side support would help: - Right now, Boost.Build nightly docs are supposed to be generated on 'my' server, picked up by webserver, and served from there. That's rather fragile configuration. - We have test results generated by xsltproc, which is extremely slow, and does not allow for anything interesting, like history. It might be easy to switch to using database, but it requires a server with a database. Thanks, Volodya
On 18 December 2013 12:40, Vladimir Prus <ghost@cs.msu.su> wrote:
On 18.12.2013 16:29, Daniel James wrote:
I have no experience with gerrit, but I worry about server maintenance - Trac is neglected nowadays, and I had to upgrade the wordpress installation on the server to close some serious security holes in older versions.
Do you mean having available hardware, or manual effort to keep servers running?
Manual effort. Hardware is also an issue, but hopefully gerrit isn't as expensive as trac/subversion.
participants (14)
-
Beman Dawes -
Bjørn Roald -
Cox, Michael -
Daniel James -
Daniel Pfeifer -
Gavin Lambert -
Keith Burton -
Klaim - Joël Lamotte -
Mateusz Loskot -
Mathias Gaunard -
Nathan Crookston -
Niall Douglas -
Peter A. Bigot -
Vladimir Prus