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 Sun, 15 Jan 2012 18:11:55 GMT

On 2012-01-15, at 11:25 AM, Mark Struberg wrote:

> basically that would be fine.
> 
> But note that any user on github _might_ be faked. It's simple for everyone to e.g. create
a commit with "Marius Bogoevici <marius.bogoevici@gmail.com>" as committer info ;)

> 
> So please only pull from locations you know and have verified in the past - otherwise
let the contributor creat a Jira issue and he should attach the patch + pull request there.

Sure, but I thought that we were already discussing this in the context of two sources which
authorize submitters beforehand, viz.: JIRA+patch and github. Ultimately, in both cases the
submitter must be trusted.

> 
> LieGrue,
> strub
> 
> 
> ----- Original Message -----
>> From: Marius Bogoevici <marius.bogoevici@gmail.com>
>> To: deltaspike-dev@incubator.apache.org
>> Cc: 
>> Sent: Saturday, January 14, 2012 8:16 PM
>> Subject: Re: [DISCUSS] Workflow for contributions
>> 
>> 
>> 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