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 <[email protected]>" 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 <[email protected]> > To: [email protected] > 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 < >> [email protected]> wrote: >> >>> >>> On 2012-01-14, at 11:55 AM, Matt Benson wrote: >>> >>>> On Sat, Jan 14, 2012 at 9:47 AM, Marius Bogoevici >>>> <[email protected]> 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" >
