ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@hibnet.org>
Subject Re: Hoped for advantages of migrating to git
Date Mon, 05 May 2014 12:22:32 GMT
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 <boards@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.mas@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.suereth@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.mas@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.lalevee@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.suereth@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 <
>> antoine@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-unsubscribe@ant.apache.org
>>>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>> 
>>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>> 
>> 
> 
> 
> -- 
> Matt Sicker <boards@gmail.com>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message