On Sep 8, 2011, at 7:47 PM, Chris Lattner wrote:> I don't see the conversion to Git actually happening until someone can clearly demonstrate a win for the open source project.I would think that using git would allow LLVM to setup a system whereby commits are pushed to a special buildbot repository instead of the main repository. If a commit fails to pass the test suite then it would be rejected and never committed to the main repository, preventing it from causing issues with other developers. If a commit passes then the buildbots could automagically push the changes into the main repository. I'm not exactly sure how this would work, but I think it would be possible. -- Wesley Peck University of Kansas SLDG Laboratory
On Fri, Sep 9, 2011 at 10:39, Wesley Peck <peckw at wesleypeck.com> wrote:> > On Sep 8, 2011, at 7:47 PM, Chris Lattner wrote: >> I don't see the conversion to Git actually happening until someone can clearly demonstrate a win for the open source project. > > I would think that using git would allow LLVM to setup a system whereby commits are pushed to a special buildbot repository instead of the main repository. If a commit fails to pass the test suite then it would be rejected and never committed to the main repository, preventing it from causing issues with other developers. If a commit passes then the buildbots could automagically push the changes into the main repository. > > I'm not exactly sure how this would work, but I think it would be possible.This is definitely possible, and would be cool to see implemented. The big issue with this, though, is we don't presently have the buildbot power to isolate individual broken commits and then retest all the commits depending on them. It wouldn't even need to be a separate repository; one repo could have an 'incoming' branch and its master could refuse pushes, and then the repository machine has hooks which test commits and then fast forward merge them into master once they're confirmed good. I do wish we had the buildbot power for this; it would be very useful. Sean
I believe the concern here is concentrating on how owning devs + others conduct incremental patch reviews in conformance with the current LLVM/svn based practice. IMHO any automated approach, such as your suggestion, would have to incorporate this concern, while simultaneously not forcing core devs to temporarily stop their current LLVM work in favor of learning a new review process, and possibly having to retool 3rd party dev tools. Garrison On Sep 9, 2011, at 10:39, Wesley Peck wrote:> > On Sep 8, 2011, at 7:47 PM, Chris Lattner wrote: >> I don't see the conversion to Git actually happening until someone can clearly demonstrate a win for the open source project. > > I would think that using git would allow LLVM to setup a system whereby commits are pushed to a special buildbot repository instead of the main repository. If a commit fails to pass the test suite then it would be rejected and never committed to the main repository, preventing it from causing issues with other developers. If a commit passes then the buildbots could automagically push the changes into the main repository. > > I'm not exactly sure how this would work, but I think it would be possible. > > -- > Wesley Peck > University of Kansas > SLDG Laboratory > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Fri, Sep 09, 2011 at 09:39:37AM -0500, Wesley Peck wrote:> > On Sep 8, 2011, at 7:47 PM, Chris Lattner wrote: > > I don't see the conversion to Git actually happening until someone can clearly demonstrate a win for the open source project. > > I would think that using git would allow LLVM to setup a system whereby commits are pushed to a special buildbot repository instead of the main repository. If a commit fails to pass the test suite then it would be rejected and never committed to the main repository, preventing it from causing issues with other developers. If a commit passes then the buildbots could automagically push the changes into the main repository. > > I'm not exactly sure how this would work, but I think it would be possible.FWIW, I set up a system like this for another project a few years ago (using Hudson (now Jenkins) instead of Buildbot). As far as I know, the team is still using this system successfully to manage their changes. Jenkins' git plugin has built-in support for this scenario (the "Push Merges back to origin" option). I have no idea how difficult this would be to implement for Buildbot, and I haven't heard of anyone actually doing it. I'm not by any means advocating that we switch to Jenkins... just mentioning my experience. Thanks, -- Peter
Just to be clear and upfront, I don't particularly care if the master repository is git or svn. I'm not a full time LLVM developer and I just use git-svn when needed. That said… On Sep 9, 2011, at 10:36 AM, Garrison Venn wrote:> I believe the concern here is concentrating on how owning devs + others > conduct incremental patch reviews in conformance with the current LLVM/svn > based practice. IMHO any automated approach, such as your suggestion, would > have to incorporate this concern, while simultaneously not forcing core devs to > temporarily stop their current LLVM work in favor of learning a new review process, > and possibly having to retool 3rd party dev tools.There is a bit of a catch-22 here. It seems like the core developers want only minor interruptions to the patch management and revision control methodologies, probably because these tasks are tedious enough as is. However, in my opinion, git doesn't really shine until you go "all in". That is why it has been difficult to enumerate an obvious advantage of git, you don't get much of a benefit by just converting the central repository to git. To get an advantage you need to move most of your infrastructure to git and this is a non-trivial interruption to the workflow. For instance, all of the project references below have some sort of tool support for tracking patch submissions and performing code review. In particular, it seems like Gerrit would meet the needs and usage style of the LLVM project. Additionally, cheap branching means its faster and easier to apply and build a patch without interrupting your workflow. My guess is that life would be easier for core developers and patch reviews would not get lost in the ether as often (not that this happens that often in the LLVM project). Like I said, setting one up and changing to it would be tedious and would probably cause a non-trivial interruption in LLVM development for a time. For core developers and/or the LLVM project, the resulting payoff may not be worth the cost of the interruption. One thing that may help mitigate the cost of a change would be git's support for local commits and distributed patch sharing. [1] http://code.google.com/p/gerrit [2] http://source.android.com/source/life-of-a-patch.html [3] http://unethicalblogger.com/2009/12/07/code-review-with-gerrit-a-mostly-visual-guide.html [4] http://www.gitorious.org [5] https://github.com -- Wesley Peck University of Kansas SLDG Laboratory