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