Interesting idea about the 72 hour lazy consensus for committing. Vaguely related is that you can commit without review if the build is broken, since it is emergency. But you are still required to open a pull request and merge your own pull request, so everyone can see and comment on it later.
Also, a thing that works really well for Beam is RTC where if the author is a committer, the reviewer can be a non-committer. You could also have lazy consensus after 72 hours for minor changes, but might not need it if you can trust a committer to choose a good enough non-committer reviewer. Kenn On Wed, Mar 13, 2019 at 10:36 AM Craig Russell <[email protected]> wrote: > Hi Lars, > > I think we might codify this as RTC with an exception that if someone > wants to commit a trivial or non-controversial patch, they still need to > post the patch for review and specifically request lazy consensus after 72 > hours or some other time we deem relevant to this project. > > Craig > > > On Mar 13, 2019, at 2:21 AM, Lars Francke <[email protected]> > wrote: > > > > On Mon, Mar 11, 2019 at 4:34 PM Craig Russell <[email protected] > <mailto:[email protected]>> wrote: > > > >> > >> > >>> On Mar 11, 2019, at 6:35 AM, Lars Francke <[email protected]> > >> wrote: > >>> > >>> Okay, any other opinions? > >>> > >>> I don't necessarily need "Bylaws" but a good "Contributors Guide" is > one > >> of > >>> my pet peeves. So as soon as we have the website up and running I'd > like > >> to > >>> get some content up there. > >> > >> Yes, a contributors' guide is a great thing to add to the user-facing > site. > >>> > >>> I'm usually in favor of review-then-commit but in our case I'm not sure > >> if > >>> that's always going to work. > >>> Ideally we'd have people contribute stuff that neither of us is - > >>> technically I mean - able to review as we won't have experts for every > >>> single field in the committership initially. > >>> But we can of course review for form and style etc. > >>> > >>> Other than that I'm in favor of requiring a +1 from another committer > to > >>> commit anything but this can be painful for small things (e.g. a single > >>> typo). For Hive we established a rule that for small changes (at > >>> contributors discretion) after a delay/request for reviews of 72h or so > >> it > >>> can be committed without feedback. > >> > >> This sounds reasonable. It's a combination of RTC and CTR with lazy > >> consensus. Formally, I think it would be described as CTR with > discretion > >> to wait until another committer has reviewed a "large" change. > >> > > > > I understand what you mean but I (others might disagree) would like to > see > > it codified as RTC and have the commit without a review as the exception > > not the other way around. This has been a major pain for me as a "lone" > > non-big-corporate contributor to various projects. You see things > happening > > without discussion on any public mailing list/Jira. > > > > > > > >> Regards, > >> > >> Craig > >>> > >>> Cheers, > >>> Lars > >>> > >>> On Tue, Feb 26, 2019 at 10:11 PM Sharan Foga <[email protected]> > wrote: > >>> > >>>> Hi > >>>> > >>>> I'd be happy with having both models of Jira and Github in place too. > >>>> > >>>> Thanks > >>>> Sharan > >>>> > >>>> On 2019/02/25 19:06:28, Lars Francke <[email protected]> wrote: > >>>>> On Mon, Feb 25, 2019 at 5:37 AM Kenneth Knowles <[email protected]> > >> wrote: > >>>>> > >>>>>> On Fri, Feb 22, 2019 at 2:31 PM Lars Francke < > [email protected]> > >>>>>> wrote: > >>>>>> > >>>>>>>> > >>>>>>>> Bylaws have gone out of fashion and it’s generally recommend that > >>>>>>> podlings > >>>>>>>> (and TLP) don’t have them and use the “default”. > >>>>>>>> > >>>>>>> > >>>>>>> Really? I didn't notice. > >>>>>>> > >>>>>>> > >>>>>>>> As the default is often unclear I've created a default simple set > >>>> that > >>>>>>>> graduating projects can use, [1] Legal and board have reviewed > >>>> this. > >>>>>>>> > >>>>>>> > >>>>>>> That's a good starting point. What I struggle with is that every > >>>> project > >>>>>>> works slightly different in things like: Commit-then-review or > >>>>>>> review-then-commit or whether ReviewBoard needs to be used or > patches > >>>>>> need > >>>>>>> to be attached to Jira etc. > >>>>>>> These rules are often not written down which makes it hard to > >>>> contribute. > >>>>>>> This might be a particular pet-peeve of mine because I do - nature > >>>> of the > >>>>>>> job - lots of "drive by" contributions but I'd still love a clearly > >>>>>> defined > >>>>>>> set of rules on how we want to operate. > >>>>>>> > >>>>>>> This includes - and I don't actually know what works there these > >>>> days and > >>>>>>> what doesn't - the Github use. > >>>>>>> If anyone knows what's allowed and possible it'd be great if you > >>>> could > >>>>>>> share. > >>>>>>> > >>>>>> > >>>>>> At this point, the GitHub pull request model is a de facto standard > in > >>>> my > >>>>>> mind. It works great with ASF infra. > >>>>>> > >>>>>> The most important thing being that you don't have to read a > project's > >>>>>> contribution guide to know how to *request* that they *pull* from > your > >>>> fork > >>>>>> of their code. Great for drive-by contributions. If a project > doesn't > >>>>>> basically follow this model, I don't trust them to accept outside > >>>> input. We > >>>>>> should definitely use it. I would guess users will be much more > likely > >>>> to > >>>>>> also want to casually contribute bits here and there, compared to > >> other > >>>>>> projects. Let's make it easy and fun for them (and bring them on > board > >>>> :-). > >>>>>> > >>>>> > >>>>> I agree that lots of projects use it but most projects I work with > work > >>>>> differently (e.g. Hadoop, Kafka, HBase etc.). Some do have a model > >> where > >>>>> both ways are accepted (Jira & Github). I myself am not the biggest > fan > >>>> of > >>>>> Pull requests. I'm against using it as the only option. I like the > >>>>> "old-fashioned" way of attaching patches to Jira. It doesn't lock me > >>>> into a > >>>>> workflow provided by a 3rd party. I can download everything offline > and > >>>>> prepare a review offline as well. That's not possible with Github (I > >> can > >>>>> download the code but I can't prepare a review for the website > >> offline). > >>>>> > >>>>> But as I said: I definitely agree that it makes "drive-by" > >> contributions > >>>>> easier so I'm in favor of having both models. > >>>>> > >>>>> Lars > >>>>> > >>>>> > >>>>>> > >>>>>> Kenn > >>>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Justin > >>>>>>>> > >>>>>>>> 1. https://wiki.apache.org/incubator/DefaultProjectGuidelines > >>>>>>> > >>>>>> > >>>>> > >>>> > >> > >> Craig L Russell > >> Secretary, Apache Software Foundation > >> [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto: > [email protected]>> http://db.apache.org/jdo <http://db.apache.org/jdo> < > >> http://db.apache.org/jdo <http://db.apache.org/jdo>> > > Craig L Russell > Secretary, Apache Software Foundation > [email protected] <mailto:[email protected]> http://db.apache.org/jdo < > http://db.apache.org/jdo> >
