Parallel would solve our problem of delayed bookkeeping as well. good idea.
It is not so much about about the initial 72 hours, rather the pause then another 72hrs that someone having to remember. Podlings have a stateful experience during a release.. they have to know which are in what stage. voting is more stateless. My goal is to have podlings and folks who have stateful tasks to be able to complete them with no more stages than necessary. People will drive up quality to have less burdensome process. You'll notice zipkin already automating things people have been emburdened by for years [1] . If higher gates are needed for a faster process, I'm sure we'd find a way to do that vs the alternative. No ones goal is to do more red tape than necessary or take longer doing it I'm sure. -A [1] https://github.com/openzipkin-contrib/apache-release-verification On Tue, Apr 2, 2019 at 4:30 PM Geertjan Wielenga <geertjan.wiele...@googlemail.com.invalid> wrote: > > Maybe the PPMC and IPMC vote could run in parallel -- a key reason why we > in Apache NetBeans are looking forward to graduation is that we'll not need > to go through the loop of (1) PPMC approves, (2) IPMC rejects, (3) PPMC > needs to put together a new release and vote on it again, (4) IPMC rejects > again (finding something else they hadn't found before), etc. That's slowed > the releases we have done in the incubator down significantly, typically by > at least 2 weeks -- of course, as will be pointed out, Apache NetBeans is > very large -- but, assuming Apache wants to be a welcome place for large > projects too, something needs to be done here (though it won't be a problem > for Apache NetBeans anymore since we plan to graduate before our next > release). So, if the votes were to at least run in parallel, that would > save time, and maybe as soon as there are 3 +1s from PPMC/IPMC members, > that should be good to go, rather than waiting another 72 hours after that, > in situations where those votes come in quickly. > > Gj > > On Tue, Apr 2, 2019 at 11:09 AM Julian Feinauer < > j.feina...@pragmaticminds.de> wrote: > > > Hi, > > > > I like Craigs suggestion and I'm aware of the problem with the ASF Policy > > if we would skip the formal IPMC Vote. > > On the other hand in PLC4X we had a discussion about a regular release > > cycle to bring new features to the users as fast as possible and decided to > > skip that for now, to keep the burden on the IPMC low (and we usually have > > 3 IPMC / Mentor Votes as we have very active Mentors). > > I agree with this decision of the PPMC but I see a problem with that, as > > the IPMC Vote should be something to help podlings (aside from the > > necessity by Policy) but not "negatively" impact them. > > > > Perhaps it helps to see the IPMC Votes more as a "take notice" in case > > that there are already 3 +1 Votes. This means that the vote is open for > > 72hrs formally, but IPMC members do not feel to have to go to action > > (usually as PMC member one "should" participate in votes... although this > > is practiced differently in the IPMC for good reasons) but CAN if they feel > > like. > > This would especially mean that podlings should be encouraged to formulate > > their votes more explicit about whether there are already enough IPMC Votes > > or not. > > > > Julian > > > > > > Am 01.04.19, 23:51 schrieb "Justin Mclean" <jus...@classsoftware.com>: > > > > Hi, > > > > I'd also like to see those mentors / IPMC members vote with more than > > just a +1 and provide a list of what they checked. If they could use > > something like this all the better [1]. > > > > I wouldn’t be for removing the second step of letting the IPMC look at > > it, reasonably often serious issues are found in that step. By skilling > > that we risk some podlings going all the way to propose graduation while > > having releases that don’t follow ASF policy. This is a situation I’d like > > to avoid. > > > > Thanks, > > Justin > > > > 1. https://wiki.apache.org/incubator/IncubatorReleaseChecklist > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
