Hi @all, I've just added a first version of the workflow description to the corresponding wiki page:
https://cwiki.apache.org/confluence/display/DeltaSpike/Suggested+Git+Workflows Christian 2012/1/17 Gerhard Petracek <[email protected]>: > hi @ all, > > as we have seen the suggestion of christian works pretty well and at least > for contributions via patches, we should use it imo (it's better than the > typical "thx to [name of contributor]" in the commit message). > > @christian: > if there are no objections, it would be nice if you add it to [1]. > > @new features which consist of multiple commits: > (there needs to be at least a jira ticket and we have to review it in any > case - just trusting an external contributor without reviewing the > contribution won't work at all imo.) > since we suggest to work with >local< branches, we could think about > suggesting branches for new features as well. > e.g.: create branch -> commits -> push it to a public repository -> add the > link to the jira ticket. > -> a committer performs a pull >rebase< on the remote branch as soon as we > agreed on it -> we still have a clean commit history. > > regards, > gerhard > > [1] > https://cwiki.apache.org/confluence/display/DeltaSpike/Suggested+Git+Workflows > > > > > 2012/1/15 Marius Bogoevici <[email protected]> > >> >> 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" >> >> >> >> -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
