On Sat, Feb 25, 2012 at 6:07 AM, Ross Gardler <rgard...@opendirective.com> wrote: > On 25 February 2012 05:36, Rob Weir <rabas...@gmail.com> wrote: >> On Feb 24, 2012, at 11:05 AM, Ross Gardler <rgard...@opendirective.com> >> wrote: >> >>> Without commenting on the dates, schedules and technical issues I >>> would urge you to make sure you allow significant time for IP review >>> from mentors and the IPMC. I imagine this release will get a great >>> deal of attention and, almost without a doubt, someone will come up >>> with something that needs to be addressed. >>> >> >> Mentors and IPMC members have had 8 months to offer IP related >> comments. They are welcome at any time. But in my experience declaring >> a Release Candidate is especially effective at concentrating their >> attention on that task. > > Exactly (this is especially true of those who are not formally mentors). > >> We should plan on having multiple RC iterations. There are enough >> unwritten rules related to release requirements that we'll almost >> certainly need several iterations. > > 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. > >> But the most effective way to >> uncover these unwritten rules is by proposing a RC for a release vote. > > 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. >
OK. So this sounds like this can be done with a RC, but without calling a vote on the RC. The first RC can be like a "dress rehearsal". It goes beyond the dev milestone builds in several ways: 1) We include the source packages as well as the binaries 2) We deliver the platforms and languages that we actually intend to release 3) We follow release naming conventions, MD5 hashes, digital signatures, etc. 4) We tag the RC in SVN. 5) If during the informal review of that RC we uncover additional issues then we can spin a new RC2 build, etc. We call for a vote when we stop finding release blocking issues. 6) Generally be sensitive to the maxim: "Every new class of testers finds a new class of bugs". So extended gazing by the same set of reviewers will quickly lead to diminishing returns. Eventually we need to get the release vetted formally, and the vote is what drives that, > 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. > OK. > 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 see no conflict between what you propose and moving to RC1 very soon. What I hear is that we might want to ask for an informal review of RC1 rather than go immediately to a formal vote. >> Of course we should first make sure were following all the written >> rules. > > I think, in this respect, the project is doing well. Although I have > not yet done my own complete review. > > Ross
