TL;DR; I suppose is that in the case of 3 mentor/IPMC already +1 a release we can switch to a "review after commit" style notification so that folks eager to double check can, but not to burden the project or IPMC with a secondary step.
This not only reduces bookkeeping but encourages each podling to engage mentors, helping with the original intent of this thread. Anything noted as blocker review after commit would be addressed. In the rare case that IPMC members acting in a podling are doing a bad job, that could be addressed as a learning exercise as presumably they would also be doing a bad job at the later vote too. On Tue, Apr 2, 2019, 9:42 AM Adrian Cole <adrian.f.c...@gmail.com> wrote: > one part that may not be obvious is the bookkeeping overhead on projects > with many repositories and also the load on the IPMC. > > For example in zipkin, we are migrating several repositories. You can > imagine a surge of release verification votes which if people here want to > take the burden of responding to, surely can. Noting that there are already > several IPMC involved it might for some members feel less priority and they > may choose to not vote at all (such as our last release). > > Probably secondary to folks here is the burden on the podling to track the > incomplete releases. It is less about rush more about excess tracking. It > is possible that a project can achieve a "good driver status" to reduce the > burden of having to create a wait condition especially if it is not the > case people do anything during it. > > my 2p > > On Tue, Apr 2, 2019, 5:59 AM Dave Fisher <dave2w...@comcast.net> wrote: > >> >> >> > On Apr 1, 2019, at 3:42 PM, Justin Mclean <justinmcl...@gmail.com> >> wrote: >> > >> > Hi, >> > >> > When Ross wrote “72hrs or 3 +1” I think he was using shorthand, not >> >> intending to rewrite foundation policy. >> >> >> > >> > Sure I thought so as well, but other newer people here might not of been >> > aware of it. >> >> The only exception to the 72 hour rule that I’ve heard about is a >> critical security fix needs to be made in which case I would hope the >> reason for the hurry would be explained on private lists. >> >> I would not put words into Ross’s mouth. He may in fact mean that he >> would go quickly when there are three +1 votes and reasons other than >> security. >> >> Regards, >> Dave >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >>
