We use already Github pull requests. The Apache integration is pretty good, so I don't see any blockers. I already reviewed and merged a couple of them.
See for example last week https://issues.apache.org/jira/browse/TOMEE-2083 https://github.com/apache/tomee/pull/81 The comments on PRs are also synchonized into JIRA. So not sure what we need more but use it. In terms of RTC, I'm tempted to give a +0, not because I think it's a bad thing, but because I fear I can't really help much in terms of reviews. -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Mon, Jul 3, 2017 at 8:34 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > I'm +1 to enhance our github support, it is really a favorable contribution > solution but for the process itself I don't see what changed so I'm still > -1 for the reasons mentionned when we discussed it. > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://blog-rmannibucau.rhcloud.com> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/ > rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory > <https://javaeefactory-rmannibucau.rhcloud.com> > > 2017-07-03 3:04 GMT+02:00 David Blevins <david.blev...@gmail.com>: > > > There’s a discussion on the private list on this topic, but given the > > recent thread I think it makes sense to move that here. > > > > The vote would be only on this question: > > > > - Is RTC worth trying for 3 months? (+1,+/-0,-1) > > > > I’ve seen some voices in favor, but do not want to propose a vote > > without a heads-up. Specifically, even if many people like the idea > > we should talk about how we want to do it. > > > > # Review-than-commit > > > > For those that do not know, Review-than-commit is essentially what > > Github Pull Requests are. Prior to github, Apache describes them as: > > > > - Commit policy which requires that all changes receive consensus > > approval in order to be committed. > > > > I think we’ve seen evidence that: > > > > - Slowing ourselves down can be a good thing. > > > > - Moving ahead after discussion is a good thing. Discussion should > > precede even the first commit. > > > > - More eyes and talk around commits can help documentation efforts. > > > > - As 3 +1s are required, a one-to-one conversation with no one else > > included is naturally discouraged. > > > > # Trial basis > > > > My thought is to go RTC for 3 months as a trial. After 3 months, no > > action means we revert back to our present CTR. A new vote would be > > required to continue RTC in any form, as-was or modified. > > > > The trial-basis is to acknowledge that we are voting on a guess of > > potential benefits. This allows us to "try before we buy" and the > > vote really comes down to if we want to try. We need not make a > > decision based on other people's experience and have a means to gain > > our own experience with a built-in escape clause that triggers lazily. > > > > RTC may sound like a good idea, but our implemention of it may be bad > > in practise. It may sound like a bad idea, but we may discover > > positives we hadn't anticipated. We don't currently know. > > > > # How would we do it? > > > > Some things that would be good to discuss: > > > > - How could we use github pull requests? Other communities do use > > them and I suspect there are options we have not explored. > > > > - Should all reviews be on the dev list? With Github PRs comments > > and JIRA comments, there needs to be a source of truth. > > > > - Should we fully document the process before we try so we can get > > the most value from a 3 month trial? > > > > > > -- > > David Blevins > > http://twitter.com/dblevins > > http://www.tomitribe.com > > > > >
