> If the mentors on the project list have voted +1, then the vote can be > continued in parallel? Shouldn't this help reduce both the time votes take > but not waste the limited IPMC bandwidth?
That's exactly what we tried and were given grief about. We waited until 3 binding +1 votes, which is for practical purposes all of our active mentors https://lists.apache.org/thread.html/0b52a3437370937c98724f5478002fe65b68717f30387595be4cd18e@%3Cgeneral.incubator.apache.org%3E I think the 100% perfect release standard is debated on other topics, and seems to be a split where many say you have to fix things by graduation, and others think you have to fix all things by next release. The 100% goal is really counterproductive and causes a lot of unnecessary stress, and frankly anger. This toxic situation of not being able to succeed because rules aren't knowable, yet expected as 100% makes it hard to be friendly and nice. > Instead of having to actually DO releases, at least Release Candidates should > be created ... this would prove the general ability to do a release, but not > actually DO it. Of course if these RCs contain bad things, they should not > pass. I suspect in some cases there are repos that maybe never have a release. In zipkin we felt like we had to do all work and it was a bad taste to see all this high friction efforts then projects go for graduation with dozens of repos.. probably some not even looked at. Whatever it is, I think it should become fair at some point. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
