What happens when pull requests are just ignored or left hanging? Unless there is a diligent maintainer, these things go into a black hole by default. There ought to be a forcing function to accept or reject. When fixes for obvious issues go nowhere, it takes away any motivation to commit further.
On Wed, Oct 18, 2017 at 11:40 AM [email protected] <[email protected]> wrote: > No I think its fine, I never see or read that email :P > Regards. > > 2017-10-18 13:36 GMT-05:00 Nate Smith <[email protected]>: > > > I'm sorry it looks like my last email didn't go to @dev. > > > > Do need to have a more structured vote on this? > > I did not see any negative opinions, only a few points on the allotted > time > > and revisiting at a more "mature" point in the future. > > > > Let me know, > > > > - Nathanael > > > > On Fri, Sep 29, 2017 at 11:54 AM, Nate Smith <[email protected]> > > wrote: > > > > > Bump, > > > > > > Do we need to take an official vote on this? > > > > > > +1 from me of course on the change, and it seems that we're all in > > > agreement. > > > > > > On Fri, Sep 22, 2017 at 1:59 PM, Cesar Berho <[email protected]> wrote: > > > > > >> +1 on the 48 hrs period. > > >> > > >> On Fri, Sep 22, 2017 at 10:15 AM, Gonzalez, Victor < > > >> [email protected]> wrote: > > >> > > >>> +1 with 48 hours period > > >>> > > >>> Sent from my iPhone > > >>> > > >>> > On Sep 21, 2017, at 3:52 PM, Jon Zeolla <[email protected]> > > wrote: > > >>> > > > >>> > I agree, at least one +1 from a committer as a minimum bar is > pretty > > >>> > reasonable. For bigger changes usually having more people review > and > > >>> test > > >>> > makes sense, but I've seen that handled as more of a one off. > > >>> > > > >>> > I'm usually in favor of a 24 hour wait as well, but could see it go > > >>> either > > >>> > way here. > > >>> > > > >>> > Jon > > >>> > > > >>> >> On Thu, Sep 21, 2017, 16:44 <[email protected]> wrote: > > >>> >> > > >>> >> I would recommend to make contributing to Spot as easily as > possible > > >>> >> because any hurdle or obstacle will make contributing harder and > > thus > > >>> will > > >>> >> discourage potential long term contributors. > > >>> >> > > >>> >> Pretty much all other projects that I’m involved with at ASF are > > >>> following > > >>> >> something in the lines of what Nate is describing. Anyone on the > > >>> internet > > >>> >> can submit a patch and all it takes is a single committer who does > > >>> review > > >>> >> and then the patch is merged to master branch. Some projects do a > > >>> “cool > > >>> >> off" window before the “review” and “merge” to make sure that > other > > >>> >> committers have time to jump in - projects like Hadoop and Hive > tend > > >>> to > > >>> >> give 24 hours, projects like Sqoop or Flume simply commit > > >>> immediately. Any > > >>> >> other committer however have always a chance to jump in and pretty > > >>> much > > >>> >> VETO the patch — provided there is a good explanation for the push > > >>> back. > > >>> >> > > >>> >> Jarcec > > >>> >> > > >>> >>> On Sep 21, 2017, at 1:15 PM, Michael Ridley < > [email protected]> > > >>> >> wrote: > > >>> >>> > > >>> >>> Sounds like a good approach. I'm all in favor of following a > > process > > >>> >> that > > >>> >>> works for other ASF projects. > > >>> >>> > > >>> >>> Speaking of votes by committer, I think any vote would be > recorded > > as > > >>> >>> binding or non-binding based on committer status. I am not a > > >>> committer > > >>> >> so > > >>> >>> I always make sure to mark mine as non-binding. > > >>> >>> > > >>> >>> Michael > > >>> >>> > > >>> >>> On Thu, Sep 21, 2017 at 1:28 PM, Nate Smith < > [email protected] > > > > > >>> >> wrote: > > >>> >>> > > >>> >>>> Also, > > >>> >>>> > > >>> >>>> As a point of consideration it's good to highlight that in such > a > > >>> >> scenario > > >>> >>>> where a +1 is given and 48 hours to review prior to merge, any > -1 > > >>> should > > >>> >>>> reset the vote in my mind. Votes of such nature would have to be > > >>> >> restricted > > >>> >>>> to committers on the project. > > >>> >>>> > > >>> >>>> On Thu, Sep 21, 2017 at 10:22 AM, Nate Smith < > > [email protected]> > > >>> >> wrote: > > >>> >>>> > > >>> >>>>> Hello, > > >>> >>>>> > > >>> >>>>> From my own experience and also in talking directly with a few > > >>> >> committers > > >>> >>>>> to the project the requirement for three +1's from committers > > >>> should be > > >>> >>>>> reviewed. > > >>> >>>>> > > >>> >>>>> My understanding is that other projects in the ASF simply > require > > >>> one > > >>> >>>> vote > > >>> >>>>> and provide some time for review by others prior to merging > (such > > >>> as a > > >>> >>>>> 24-48 hour period). However more emphasis is placed on refining > > >>> code in > > >>> >>>>> preparation for releases. > > >>> >>>>> > > >>> >>>>> As it stands today we require at least three +1's before merge, > > and > > >>> >> there > > >>> >>>>> is no time requirement. > > >>> >>>>> > > >>> >>>>> Since we are a growing community, and the goal is to develop > more > > >>> code > > >>> >>>>> contributors I think it is important to bring this up for > review > > in > > >>> >> hopes > > >>> >>>>> that we can adopt something that allows faster iterations with > a > > >>> strong > > >>> >>>>> focus on polishing for future releases. > > >>> >>>>> > > >>> >>>>> - Nathanael > > >>> >>>>> > > >>> >>>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> -- > > >>> >>> Michael Ridley <[email protected]> > > >>> >>> office: (650) 352-1337 > > >>> >>> mobile: (571) 438-2420 > > >>> >>> Senior Solutions Architect > > >>> >>> Cloudera > > >>> >> > > >>> >> -- > > >>> > > > >>> > Jon > > >>> > > >> > > >> > > > > > >
