Am Samstag, 25. Februar 2012 schrieb Ross Gardler : > On 25 February 2012 05:36, Rob Weir <[email protected] <javascript:;>> > wrote: > > On Feb 24, 2012, at 11:05 AM, Ross Gardler > > <[email protected]<javascript:;>> > 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 > [email protected] 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. > > thanks for sharing such thoughts with the broader community. I am happy to get so many useful info which is important for our release by simply using 2 letters "RC" and a potential date.
And I would be even more happy if more people would start pro-active helping to prepare a release. I think we can invite the IPMC to take a closer or first look on our next dev snapshots on Tuesday. I will prepare source release snapshots as well. I would like to see at least the rules requirements for an Apache release fulfilled asap to be able to concentrate on the quality. I will be back in HH on Monday and will work on further preparation towards a release ;-) Juergen > Consider sending a mail to [email protected] 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. > > > 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 >
