While I was getting to know better another ASF project Spark [1], I have found that they use git, and they heavily use github in their workflow. So I asked them how they work it it [2].
Of course the ASF git repo is the official source repo. But contributions are asked to go through github. A pull request is open there, discussion may happen there [3]. And once a committer is satisfied with the result, the work is being imported into the git repo with a script [4]. I am not suggesting we use that workflow or we shouldn't use it. It is just an interesting workflow I have found and which we may discuss. Nicolas [1] https://spark.apache.org/ [2] http://apache-spark-developers-list.1001551.n3.nabble.com/Mailing-list-td6451.html [3] https://github.com/apache/spark/pull/634 [4] https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py Le 1 mai 2014 à 02:19, Matt Sicker <boa...@gmail.com> a écrit : > Apache projects are already mirrored at GitHub. > > https://github.com/apache/ > > We just need better support for merging back from GitHub (or even being > able to write to the GitHub repositories). > > > On 30 April 2014 18:00, Andre-John Mas <andrejohn....@gmail.com> wrote: > >> Fair point. >> >> My experience has been the same. Was a little stubborn at first, but once >> I made the move from Subversion I haven't looked back. One thing that I >> found it fixed, in my environment, is avoiding devs using the main source >> control as a form of backup. >> >> André-John >> >> Sent from my phone. Envoyé depuis mon téléphone. >> >>> On 30 Apr 2014, at 18:48, Josh Suereth <joshua.suer...@gmail.com> wrote: >>> >>> I'd argue that the convenience of pull requests in ASF should be a >> fixable >>> problem. If ASF is running repositories, Gerrit would be a great way to >>> set up an elegant ASF workflow... >>> >>> In any case, I applaud the effort to migrate to get and understand the >>> concerns. My experience has been truly great moving to git. >>> >>> >>> On Wed, Apr 30, 2014 at 6:33 PM, Andre-John Mas <andrejohn....@gmail.com >>> wrote: >>> >>>> Could we conceive of having a GitHub project, that serves as a point for >>>> pull-requests and other community work and at the same time have a git >> repo >>>> at Apache that syncs with this? >>>> >>>> >>>> André-John >>>> >>>> Sent from my phone. Envoyé depuis mon téléphone. >>>> >>>>>> On 30 Apr 2014, at 17:33, Nicolas Lalevée <nicolas.lale...@hibnet.org >>> >>>>> wrote: >>>>> >>>>> Even if I share some of your enthusiasm with git, don't forget that git >>>> at the ASF isn't like git in github. Pull request, code review and so >> on is >>>> not as integrated as in github. >>>>> >>>>> Nicolas >>>>> >>>>>> Le 30 avr. 2014 à 16:01, Josh Suereth <joshua.suer...@gmail.com> a >>>> écrit : >>>>>> >>>>>> If you don't mind some recommendations from the peanut gallery (been >>>> using >>>>>> git for 5 years now) >>>>>> >>>>>> >>>>>>> On Wed, Apr 30, 2014 at 9:53 AM, Antoine Levy-Lambert < >> anto...@gmx.de >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> Hello Maarten, >>>>>>> >>>>>>> I do not know a lot about git either. >>>>>>> >>>>>>> Here are the advantages I see in migrating to git : >>>>>>> >>>>>>> - git allows third-parties to clone an original repository and in >> fact >>>> to >>>>>>> create a fork while keeping the possibility of contributing back what >>>> they >>>>>>> have created if they want to, and also importantly to incorporate >>>> inside >>>>>>> their branches changes done elsewhere including in the reference >>>>>>> repository. So I see git as having the same strategic importance for >>>> the >>>>>>> source code like the fact of uploading the ant jars to maven central >>>> is for >>>>>>> the use of the binaries. >>>>>> This is pretty huge. The cost of contributions is a lot lower *and* >> you >>>> can >>>>>> perform magic on branches (git rebase) before submitting to upstream >>>>>> projects. We (sbt + Scala) generally have a workflow of: >>>>>> >>>>>> 1. hack, hack, hack on our own clone/branch with a name "wip" >>>>>> 2. When done (across the group working on it), rebase the commits and >>>> clean >>>>>> up the commit messages to be as useful as possible >>>>>> 3. Submit a pull request, code review, go back to #1 as necessary >>>>>> 4. Merge into master, delete local branch, continue work. >>>>>> >>>>>> Not only that, we're already using the git Ivy mirror to collaborate >>>>>> between sbt devs and outside ivy contributors. It's a very good model >>>> for >>>>>> highly distributed (i.e. OSS) teams where coordination of >> contributions >>>> is >>>>>> hard. >>>>>> >>>>>> >>>>>>> - for the developers of the Apache project - us - the small >> advantages >>>> are >>>>>>> to be able to commit stuff locally on our computers before pushing >>>> when we >>>>>>> are happy with our changes. Also one can switch branch very quickly >>>> within >>>>>>> the same workspace when using git, this might be an advantage. >>>>>> I often run 3-5 branches of code for OSS projects. 1-2 of "itch >>>>>> scratching" and 1-3 of "bug fixing". It's a great thing. >>>>>> >>>>>> >>>>>>> - because of the popularity of git I imagine that the change is good >>>> for >>>>>>> the long run but this is speculation >>>>>> Popularity definitely puts it above something like mercurial. It >> also >>>>>> means the tooling for git has become pretty good over the past few >>>> years. >>>>>> JGit even provides really good Git support for programatic access. >>>>>> >>>>>> >>>>>> >>>>>>> I imagine that some corporations, individuals,or other open source >>>>>>> organizations will take advantage of our projects moving to git to >>>> create >>>>>>> these forks, either because the contribution process via JIRA is too >>>> slow, >>>>>>> or because they want to create proprietary enhancements, or because >>>> they >>>>>>> are not sure that the changes that they do match the views /plans... >>>> of our >>>>>>> the Ant/Ivy/Ivyde/Easyant Apache project. >>>>>> From an sbt perspective, you'd see us attempting to contribute things >>>> back >>>>>> far more often than we do now. If you'd like an example project that >>>>>> contains website assets in it, feel free to checkout >> github.com/sbt/sbtand >>>>>> see how long it takes to switch branches / load the repository >>>> initially. >>>>>> >>>>>> - The Peanut Gallery (Josh) >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >>>>> For additional commands, e-mail: dev-h...@ant.apache.org >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >>>> For additional commands, e-mail: dev-h...@ant.apache.org >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >> For additional commands, e-mail: dev-h...@ant.apache.org >> >> > > > -- > Matt Sicker <boa...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
