thx christian! regards, gerhard
2012/1/18 Christian Kaltepoth <[email protected]> > 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 >
