deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marius Bogoevici <marius.bogoev...@gmail.com>
Subject Re: [DISCUSS] Workflow for contributions
Date Sat, 14 Jan 2012 19:16:46 GMT

On 2012-01-14, at 12:39 PM, Lincoln Baxter, III wrote:

> Is it not still possible to use Pull requests, but simply merge them
> manually against the proper repository? Github would see the changes in the
> repository and automatically close the pull request once the merge has been
> completed (and synced with Github.) Additionally, pull requests that were
> only partially merged or accepted can still be closed manually.

That should work pretty well too, especially if multi-commit pull requests are discouraged
or even
banned (and I personally think that they should, as they are can be a PITA to review).


> 
> Would that be too confusing?
> ~Lincoln
> 
> On Sat, Jan 14, 2012 at 12:05 PM, Marius Bogoevici <
> marius.bogoevici@gmail.com> wrote:
> 
>> 
>> On 2012-01-14, at 11:55 AM, Matt Benson wrote:
>> 
>>> On Sat, Jan 14, 2012 at 9:47 AM, Marius Bogoevici
>>> <marius.bogoevici@gmail.com> wrote:
>>>> 
>>>> On 2012-01-14, at 10:14 AM, Christian Kaltepoth wrote:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I think we should talk about how contributions and patch submissions
>> could
>>>>> work in the future.
>>>>> 
>>>>> Everybody familiar with GitHub knows pull requests which offer a great
>> way
>>>>> to submit patches to a project. But as the ASF repository doesn't offer
>>>>> such a feature we should think about how we could handle contributions
>>>>> while getting as much out of git as possible.
>>>>> 
>>>>> One way to handle this is to use "git format-patch" which is able to
>>>>> package a series of commits into one file (see [1] for an examle).
>> Using
>>>>> format-patch has some nice advantages over standard patch files. The
>> major
>>>>> advantage is that individual commits including their commit messages
>> and
>>>>> author are preserved.
>>>>> 
>>>>> Creating such patches is very easy. Just create a local branch, do the
>>>>> commits there and then create the patch this way:
>>>>> 
>>>>> $ git format-patch --stdout master > ../DELTASPIKE-XXX.patch
>>>>> 
>>>>> Applying such patches is also straight forward:
>>>>> 
>>>>> $ git am < ../DELTASPIKE-XXX.patch
>>>>> 
>>>>> The most important question we have to answer is if we should accept
>> such
>>>>> "git format-patch" patches in the future or if we stick with the
>> classic
>>>>> "diff" patches.
>>>>> 
>>>>> The only reason against the "git format-patch" contributions I could
>> think
>>>>> of would be that the name of the original patch author (who is
>> presumably
>>>>> not ASF member) appears in the commit. But IMHO this shouldn't be a
>> real
>>>>> problem because the name of the committer that applied the patch is
>> also
>>>>> added (see [2] for an example).
>>>> 
>>>> I would argue that preserving a reference to the original contributor
>> is very
>>>> desirable. For one thing, giving credit where it's due is the fair
>> thing to do - on the other hand,
>>>> it is a good way of tracing the amount of individual contributions for
>> non-committer contributors
>>>> (e.g. before they become committers in their own right). Now, quantity
>> is really just one of the
>>>> metrics (the other one being quality, of course), but I'd say that it's
>> still good to have this kind of
>>>> stuff remembered somewhere.
>>>> 
>>> 
>>> This won't necessarily be the case 100% of the time, but I would hope
>>> that a given contribution would typically not be pulled into the main
>>> repository without meeting or exceeding the DeltaSpike committer's
>>> standard of minimum quality.  So in most cases, quantity of
>>> contributions, along with other forms of community participation
>>> (there have been committers and even PMC members elected to projects
>>> with *no* actual code contributed), would remain a decent metric.
>>> 
>> 
>> Yes, and other SCMs (SVN for instance) tend to blur this. So, I see using
>> the way
>> in which git format-patch works more like a desirable feature we shall
>> use, rather than a
>> hindrance we need to work around.
>> 
>>> Matt
>>> 
>>>>> 
>>>>> Any thoughts on this? I think we should create a wiki page for the
>> process
>>>>> however it will look like so that new contributors can get started
>> quickly.
>>>>> 
>>>>> Christian
>>>>> 
>>>>> 
>>>>> [1]
>>>>> 
>> https://issues.apache.org/jira/secure/attachment/12510524/DELTASPIKE-49.patch
>>>>> [2]
>>>>> 
>> http://git-wip-us.apache.org/repos/asf?p=incubator-deltaspike.git;a=commit;h=becf0ff57bfbf472fc7c1e07a0c68746aa00018b
>>>>> 
>>>>> 
>>>>> --
>>>>> Christian Kaltepoth
>>>>> Blog: http://chkal.blogspot.com/
>>>>> Twitter: http://twitter.com/chkal
>>>> 
>> 
>> 
> 
> 
> -- 
> Lincoln Baxter, III
> http://ocpsoft.com
> http://scrumshark.com
> "Keep it Simple"


Mime
View raw message