I did not call for a vote because I did not think I could as I'm just a community member, I would like my proposal formally voted it on as is.
As for the two concerns that I saw raised. 1) The timeline. Two weeks over the holiday to come to a formal agreement is going to be tough and I also don't think just because we have a path forward people will stop caring about proposing a better solution. From what I'm seeing the longer term proposal will likely get into the weeds of tooling around CI email patches etc... These take weeks to settle on. I trust the intentions of the people in the project and do not see a need to bind them to a timeline to build this out. 2) Why cut corners. Personally I don't see this as cutting corners I think this will in practice get us 90% of the way there and get us back into a cadence of improving the software. I trust the project members will use judgement within the structure and will actively move the project along to better structure. Thanks, Brennan On Sun, Dec 22, 2019, 7:08 AM Gregory Nutt <spudan...@gmail.com> wrote: > Again, is this a formal vote? it is not clear to me. Did someone in > the PPMC call a vote? There is not [VOTE] in the message title? > > Just point of order which I do not know the answer too. Brennan is not > yet listed as a PPMC member or a as a committer (but he should be and, > hopefully, will be). Can non-PPMC members calls votes that are binding > on the PPMC? Just to be clear, I think that someone in the PPMC should > call the vote with [VOTE] in the title so that is is clear if we are > castubg a binding vote or not for something are not? Or are we just > agreeing in principle or not? > > Are these binding votes? We need to clarify what is going on. > > I think we should stop the habit of using +1 just to indicate we agree > with something and we need to enforce the use of [VOTE] in the title so > that we know this is a binding vote. > > On 12/22/2019 7:57 AM, Xiang Xiao wrote: > > +1. > > It's impotant to let people start the contribution. > > The committer could/should do more work to ensure the correction in > > review process before the automation tool is ready. > > > > Thanks > > Xiang > > > > On Sun, Dec 22, 2019 at 8:57 PM David Sidrane <davi...@apache.org> > wrote: > >> This works! > >> > >> On 2019/12/22 02:05:56, Brennan Ashton <bash...@brennanashton.com> > wrote: > >>> I really want to let people to contribute (myself included) ASAP so I > was > >>> to propose this as an option to get going and can be amended later. I > know > >>> it does not resolve all the issues, but offers what I think is a > reasonable > >>> avenue to get started. > >>> > >>> Submit a PR on GitHub against master if it is approved by one commiter > >>> (that did not propose it) > >> This is key! We need the eyes (and possibly the hands) of the subject > matter experts, reviewing, commenting and possible fixing submissions. > >> > >>> it can be merged. The approval is done via the > >>> GitHub approval system. > >> +1 > >>> A commiter may create a PR on behalf of a patch submitted to the > mailing > >>> list. > >> +1 > >>> Commiters can ask for others to review or approve. But at the end of > the > >>> day they are the ones who approve and merge. > >> +1 > >>> We can and should amend this later, it is likely not enough long term. > >>> > >>> Could people vote if they think this is fine to start. If you don't > agree > >>> just note that and we can review where we are at. > >>> > >>> --Brennan > >>> > >