On 25 February 2012 05:36, Rob Weir <raba...@gmail.com <javascript:;>> wrote:

Exactly (this is especially true of those who are not formally mentors).

You've been paying attention to recent discussions on general@incubator.a.o I see ;-)

Glad to see this is a part of the release planning process.

I would caution against this approach, generally a vote (any vote) should only ever be called when you know it will pass. If you call for the vote indicating that it is likely to pass because of the process followed people are less likely to become involved and dredge up a half dozen edge cases as objections.

I happen to be be sat with Nick Burch, during a fashion show in a hotel lobby in Sri Lanka believe it or not! Nick is a very experienced ASF member who until recently was chair of the POI project, a project that has experience of being under the IP microscope (he also hit significant problems with the first ODF Toolkit release). He and I have been discussing what we believe will be the least painful way of getting the first AOO release out. Between us we suggest that you invite the IPMC to start the review now in order to attract as many interested, but helpful, volunteers as you can. We both feel that by inviting some key IPMC members to participate now a stronger, more positive vote can be called later. Votes attract attention from many more people than requests for assistance.

Consider sending a mail to general@incubator.a.o along the lines of...

"The AOO PPMC is getting ready to prepare for our first release. As you can imagine we have done a great deal of IP work. We believe we are in good shape and our mentors have been asked to further review our work. However, we are also aware that releases from the IPMC can often highlight many grey areas in the legal policies of the ASF. Outlined below is the process we intend to follow in ensuring that our first vote on a release candidate is successful, if you are well versed in Apache policies relating to releases we welcome your input on this process and invite you to help us review our code prior to our first RC build and vote."

I realise this is only a small difference from what you propose with multiple release candidates. My point is that calling a vote attracts much more attention than calling for help. Whilst feedback on a vote is often very useful it can also be contradictory. If we ask for input from experienced parties and document their recommendations and the actions taken in the issue tracker we can then refer to this in the vote, in some cases breaking the deadlock that can occur where feedback contradicts.

All that being said. this is just an alternative approach to the multiple RC approach. There can be no predicting which is will be the least painless - whichever route is followed there will almost certainly be pain, even the simplest of projects usually have items that have been missed by the project community and mentors.

I think, in this respect, the project is doing well. Although I have not yet done my own complete review.