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