deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [DISCUSS] Workflow for contributions
Date Sun, 15 Jan 2012 16:25:46 GMT
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.

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