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