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 <[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. 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 <[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" >>
