incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Schmidt <>
Subject Re: [RELEASE]: preparation for our first release
Date Sun, 26 Feb 2012 09:05:49 GMT
Am Samstag, 25. Februar 2012 schrieb Ross Gardler :

> On 25 February 2012 05:36, Rob Weir < <javascript:;>>
> wrote:
> > On Feb 24, 2012, at 11:05 AM, Ross Gardler <<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
> 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.
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 ;-)


> 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.
> >  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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message