The github-asf integration is fairly smooth, if not as cool as the big Merge button. For the requester there is no difference, only the Apache committer have to do manual steps.
An example email, which we set up to go to dev@: http://apache-taverna-dev.markmail.org/thread/gq62b33me5mjjkjw If you just do those commands as in the email, you are done. Any replies on the mailing list thread as goes back to github (and hence the submitter) and vice versa - although with the occasional formatting issue. The only awkward bit is that you have to use dummy commits to close any pull requests that you don't want to merge. Btw, I think the example commands could be improved, --no-ff or something should force a merge commit (where you can say the "This closes #15" in the commit message) It has also been suggested to do a trial of GitLab installation at Apache, with various feedback. http://mail-archives.apache.org/mod_mbox/community-dev/201503.mbox/ <CADmm%2BKff9qR_zQstYxbW%3DsHMfV7%3DzZrFvuND_Mn7-8Ljp819hQ%40mail.gmail.com> On 11 Mar 2015 20:42, "Guillaume Laforge" <glafo...@gmail.com> wrote: > Yes Benedikt, we're aware of that. > It's actually been one of the (pain) points we raised when discussing with > our (then-soon-to-be) mentors and champion. > Working with the Github infrastructure was very smooth, very handy and > practical. > But we'll have to get used to this new approach! > > Guillaume > > On Wed, Mar 11, 2015 at 9:24 PM, Benedikt Ritter <brit...@apache.org> > wrote: > > > Is the groovy project aware that (to my knowledge) the coding has to > > happen on ASF infrastructure? You won't be able to use the github web UI > > for merging PRs for example, because currently the ASF only mirrors git > > repositories from git.apache.org to github. > > > > I'm very excited about this project, and will definitively be on board if > > groovy enters incubation. > > > > Benedikt > > > > 2015-03-11 21:11 GMT+01:00 Cédric Champeau <cedric.champ...@gmail.com>: > > > >> A good answer to this is to take a look at who actually contributed for > >> the > >> past 4 years: > >> > >> > https://github.com/groovy/groovy-core/graphs/contributors?from=2011-01-01&to=2015-03-11&type=c > >> and you will see that there are not so many regular contributors. GitHub > >> helped us a lot recently to have more contributions, from simple typos > to > >> complex bug fixes, but one should not forget that a contribution in > GitHub > >> doesn't mean that the author is a committer : it's just that authors are > >> preserved. > >> > >> While we have a lot of contributors, only a few of us have a deep > >> knowledge > >> of Groovy internals. We will certainly encourage regular contributors to > >> become committers (we already think of some), as long as those are > >> following quality standards, take care of important things like > >> maintaining > >> backwards compatibility etc... We had more than 5 committers in the > past, > >> but lots of them just stopped pushing code, for various reasons. In the > >> end > >> I would be the first pleased to see more committers, but meritocracy is > >> also important. And to be clear, we do not think only about code: > >> contributions like documentation or tests are also very important. > >> > >> 2015-03-11 20:17 GMT+01:00 Roman Shaposhnik <ro...@shaposhnik.org>: > >> > >> > On Wed, Mar 11, 2015 at 12:08 PM, jan i <j...@apache.org> wrote: > >> > > Hi. > >> > > > >> > > Having just skimmed the proposal, that in general look good, one > thing > >> > > caught my eye. > >> > > > >> > > The proposal talks several places about a vibrant community and the > >> > initial > >> > > commiters are only 5. > >> > > >> > This, is a GREAT question! Thank you so much for raising it. While > >> > preparing a proposal I've struggled with the same issue, because > looking > >> > at this: https://github.com/groovy/groovy-core/graphs/contributors > >> makes > >> > me wonder exactly the same thing. > >> > > >> > In the end, we decided to go ahead with the proposal the way it is and > >> > position > >> > the initial list of committers more as a PMC for the project. > >> > > >> > That still doesn't answer your (or mine! ;-)) question of what's the > >> best > >> > way > >> > to make sure than anybody who feels like they have a stake in the > >> project > >> > and have contributed in the past get invited. > >> > > >> > There are a few alternatives I could see, but I would really > >> > appreciate Incubator's > >> > collective wisdom on what would be the best way to proceed here given > >> > that Groovy is a very mature project with a lot of contributors in the > >> > past. > >> > Some of whom may or may not wish to keep contributing. > >> > > >> > Thanks, > >> > Roman. > >> > > >> > > > > > > > > -- > > http://people.apache.org/~britter/ > > http://www.systemoutprintln.de/ > > http://twitter.com/BenediktRitter > > http://github.com/britter > > > > > > -- > Guillaume Laforge > Groovy Project Manager > > Blog: http://glaforge.appspot.com/ > Social: @glaforge <http://twitter.com/glaforge> / Google+ > <https://plus.google.com/u/0/114130972232398734985/posts> >
