On Fri, Oct 12, 2012 at 1:06 AM, Ross Gardler <rgard...@opendirective.com> wrote: > Nobody, in my opinion, sh8old be voting on a release without having > conducted the appropriate verifications themselves.
-0 I agree -- but that's not going far enough. In my view, no one should vote on a release unless they're subscribed to the podling's dev list. That the Incubator's release process would grind to a halt without "freelance" IPMC votes exposes a systemic flaw. >> The first AOO release got my freelance IPMC vote because it was clear that >> they knew what they were doing and were taking their role as IP stewards > > (As a mentor I also voted +1 so don't take my next comments personally) > > This is a perfect example of why proper reviews are necessary. In the > second AOO release a problem was discovered (that was present in the first > release). After reviewing the thread at <http://markmail.org/message/2penzb453qzo55rz> and seeing people competently and earnestly work through a thorny issue, I'm inclined to draw the opposite conclusion. Rather than a failure of oversight, this seems like an example of successful empowerment and self-policing. In the real world, IP bugs happen. (Just look at all the slop we see in LICENSE and NOTICE files.) To my mind, what matters most is not whether a project can avoid all IP bugs forever, but whether the team possesses both the capacity and the will to detect and dispatch IP bugs efficiently. >> , it is much more important that the community members own the task of IP >> management themselves than that they pass any sort of superficial >> documentation review. > > Isn't that a contradiction? If you voted +1 on the grounds of the PPMC > knowing what they we doing isn't that a the most "superficial of > documentation reviews"? My position is that the oversight mechanisms generally employed by the Incubator, such as license header scans, are inherently superficial even when executed conscientiously. A truly rigorous IP audit would proceed either line-by-line, or commit-by-commit to match up with the standard of an Apache PMC scrutinizing individual messages to a commits list. For the record, my review of the first AOO release candidate was considerably more thorough than the norm. In fact, I doubt you will find a more thorough review of an incubating release by a non-Mentor in the last two years, and perhaps not for a long time before that. Here are links to the review thread and to my final VOTE: http://markmail.org/thread/b4wdzilemtu36i4a http://markmail.org/message/ejs6qw6kpr22o3ps > It seems all you reviewed was some mailing list traffic. That's completely inaccurate. Please review the review thread. I went several rounds with Jürgen Schmidt, though the work was spread out across multiple people and multiple lists. LICENSE and NOTICE were reformulated and we built consensus for the new approach both here and on legal-discuss. We pored over the rat-excludes file and got RAT passing. When I found that the svn tag and the release archive did not match, we had a discussion about scripting release builds. We discussed why the file name had to include the string "incubating", file formats for sums and sigs, etc, etc... > I encourage us to empower more people who do the work so their vot3s are > binding. In my opinion, it's ridiculous that Jürgen Schmidt's heroics on the first AOO release did not earn him a binding vote on the second. When it comes to release voting, the Incubator does not recognize merit, and the Incubator does not encourage self-government. The miserable experience of podlings as they twist in the wind for weeks awaiting "freelance" votes from disintested IPMC members is the inevitable result. I'm glad that Roman wants to do his part to spare Helix from that fate, and I wish him the best of luck. Personally, I have made a decision not to perform any more freelance reviews. It is difficult to do them well, and each +1 serves to perpetuate a rotten system. Marvin Humphrey --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
