You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Jürgen Schmidt <jo...@googlemail.com> on 2012/02/24 11:23:24 UTC
[RELEASE]: preparation for our first release
Hi,
we move closer forward to our first release.
I would like to suggest that we focus on the following areas next week.
And I would like to propose the following schedule depending on the
progress we will make next week.
Monday: Feb. 27th new dev snapshots
Monday: March 5th first RC candidate (based on the progress next week)
- increase QA work
- focus on stabilization, means focus on showstopper issues
- finalize the About dialog information, input for future bug reports
- online update service
- updating building guides in the wiki
- documentation update can be run in parallel and are independent of the
binary release
- translation update, we have made minimal UI changes only and we will
use the 3.4 beta translation that were in place.
Anything else that comes into your minds?
I have started to work on the MacOS building guide and have simplified
some things (work ongoing).
We need some volunteers who take a look on the other platforms.
Especially reference to the hg repo should be removed/replaced to our
svn repo. Information about childworkspaces can be removed because it is
not longer relevant for us. I would say the focus should be on
simplification.
What do others think about it?
Juergen
Re: [RELEASE]: preparation for our first release
Posted by Kay Schenk <ka...@gmail.com>.
2012/2/24 Jürgen Schmidt <jo...@googlemail.com>
> Hi,
>
> we move closer forward to our first release.
>
> I would like to suggest that we focus on the following areas next week.
> And I would like to propose the following schedule depending on the
> progress we will make next week.
>
>
> Monday: Feb. 27th new dev snapshots
> Monday: March 5th first RC candidate (based on the progress next week)
>
> Jürgen --
Good goals and good luck to us! I will certainly do what I can next week to
make this happen! As you (and others) have pointed out, a working 3.4 of
OpenOffice.org existed as early as last April or May . Hopefully, the
substitutions to make Apache OpenOffice IP ready have been successful. I am
looking forward to learning more about the distribution/packaging process
and producing a successful Apache OpenOffice release.
- increase QA work
> - focus on stabilization, means focus on showstopper issues
> - finalize the About dialog information, input for future bug reports
> - online update service
>
> - updating building guides in the wiki
>
>
> - documentation update can be run in parallel and are independent of the
> binary release
> - translation update, we have made minimal UI changes only and we will use
> the 3.4 beta translation that were in place.
>
> Anything else that comes into your minds?
>
> I have started to work on the MacOS building guide and have simplified
> some things (work ongoing).
>
> We need some volunteers who take a look on the other platforms. Especially
> reference to the hg repo should be removed/replaced to our svn repo.
> Information about childworkspaces can be removed because it is not longer
> relevant for us. I would say the focus should be on simplification.
>
> What do others think about it?
>
> Juergen
>
--
----------------------------------------------------------------------------------------
MzK
"Follow your bliss."
-- attributed to Joseph Campbell
Re: [RELEASE]: preparation for our first release
Posted by Rory O'Farrell <of...@iol.ie>.
On Fri, 24 Feb 2012 13:28:54 +0100
> Raphael, you should keep in mind that we had a 3.4 beta already
> last year. We have removed things or have replaced things. And
> for both do we have tested it since weeks. If we figure further
> critical issues than we will fix it and will potentially move
> the date.
I
--
Rory O'Farrell <of...@iol.ie>
Re: [RELEASE]: preparation for our first release
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 2/24/12 1:36 PM, Rory O'Farrell wrote:
> On Fri, 24 Feb 2012 13:28:54 +0100
> Jürgen Schmidt<jo...@googlemail.com> wrote:
>> Raphael, you should keep in mind that we had a 3.4 beta already
>> last year. We have removed things or have replaced things. And
>> for both do we have tested it since weeks. If we figure further
>> critical issues than we will fix it and will potentially move
>> the date.
>
> Sorry - last posting escaped!
>
> I'd be happier if the proposed release was 3.4 Beta 2, even if
> that progressed to RC1 within a short period. To proceed from
> Beta 1 to RC1 after such a massive rebuild may suggest
> over-confidence.
I think we are flexible here and can agree on a name. Important is from
my point of view that we are aligned and can all support it.
If somebody have valid concerns then please raise these concerns clearly
based on facts or better submit Issues.
Juergen
Re: [RELEASE]: preparation for our first release
Posted by Rory O'Farrell <of...@iol.ie>.
On Fri, 24 Feb 2012 13:28:54 +0100
Jürgen Schmidt <jo...@googlemail.com> wrote:
> Raphael, you should keep in mind that we had a 3.4 beta already
> last year. We have removed things or have replaced things. And
> for both do we have tested it since weeks. If we figure further
> critical issues than we will fix it and will potentially move
> the date.
Sorry - last posting escaped!
I'd be happier if the proposed release was 3.4 Beta 2, even if
that progressed to RC1 within a short period. To proceed from
Beta 1 to RC1 after such a massive rebuild may suggest
over-confidence.
--
Rory O'Farrell <of...@iol.ie>
Re: [RELEASE]: preparation for our first release
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 2/24/12 12:37 PM, Raphael Bircher wrote:
> Am 24.02.12 11:23, schrieb Jürgen Schmidt:
>> Hi,
>>
>> we move closer forward to our first release.
>>
>> I would like to suggest that we focus on the following areas next
>> week. And I would like to propose the following schedule depending on
>> the progress we will make next week.
>>
>>
>> Monday: Feb. 27th new dev snapshots
>> Monday: March 5th first RC candidate (based on the progress next week)
> - 1000
you have only 1 vote ;-)
> Sorry Jürgen, this plan is so far away from reality. We have this Week
> last feature integration, and you will do a RC in a bit more then a
> Week? Where you plane all the QA work? As QA I can't support a Release
> like this. We need one month time between last feature integration and
> Release for a minimum. Else you don't have time to perform serios tests.
this conclusion is based on what? Can you explain it please further?
Raphael, you should keep in mind that we had a 3.4 beta already last
year. We have removed things or have replaced things. And for both do we
have tested it since weeks. If we figure further critical issues than we
will fix it and will potentially move the date.
Non critical issues will be moved to later because we have to set
priorities. We have always more issues that we can fix.
And I hope that we all agree that we have to provide a release to signal
that our project is alive and can deliver.
I would strongly recommend that we plan to release as soon as possible.
We might have a missing string or not 100% updated help files. But that
is not different to any other release in the past. The most important
thing is stability, that we don't crash and things work as expected.
>
> Sorry, that I have not much positiv feedback today. But I'm interested
> in a Apache OpenOffice with height quality and so I take my job as QA
> serios.
it's the same for me and hopefully all of and I don't say that we will
release it anyway.
Fine that you will focus on QA now and that you will help us to find
critical issues.
Juergen
Re: [RELEASE]: preparation for our first release
Posted by Raphael Bircher <rb...@bluewin.ch>.
Am 24.02.12 11:23, schrieb Jürgen Schmidt:
> Hi,
>
> we move closer forward to our first release.
>
> I would like to suggest that we focus on the following areas next
> week. And I would like to propose the following schedule depending on
> the progress we will make next week.
>
>
> Monday: Feb. 27th new dev snapshots
> Monday: March 5th first RC candidate (based on the progress next week)
- 1000
Sorry Jürgen, this plan is so far away from reality. We have this Week
last feature integration, and you will do a RC in a bit more then a
Week? Where you plane all the QA work? As QA I can't support a Release
like this. We need one month time between last feature integration and
Release for a minimum. Else you don't have time to perform serios tests.
Sorry, that I have not much positiv feedback today. But I'm interested
in a Apache OpenOffice with height quality and so I take my job as QA
serios.
Greetings Raphael
Re: [RELEASE]: preparation for our first release
Posted by imacat <im...@mail.imacat.idv.tw>.
On 2012/02/24 18:23, Jürgen Schmidt said:
> Monday: Feb. 27th new dev snapshots
> Monday: March 5th first RC candidate (based on the progress next week)
> Anything else that comes into your minds?
It's nice to see this. But is the translation platform ready? I
believe the text messages related to "Pivot Table" is still not
translated for Traditional Chinese, for either the Pootle or Mercurial
version. This means the translation need to be revised before we may
release.
--
Best regards,
imacat ^_*' <im...@mail.imacat.idv.tw>
PGP Key http://www.imacat.idv.tw/me/pgpkey.asc
<<Woman's Voice>> News: http://www.wov.idv.tw/
Tavern IMACAT's http://www.imacat.idv.tw/
Woman in FOSS in Taiwan http://wofoss.blogspot.com/
Apache OpenOffice http://www.openoffice.org/
EducOO/OOo4Kids Taiwan http://www.educoo.tw/
Re: [RELEASE]: preparation for our first release
Posted by Andre Fischer <af...@a-w-f.de>.
On 24.02.2012 12:40, Andrea Pescetti wrote:
> Jürgen Schmidt wrote:
>> RC should be used indeed only if we think that it can be released, and
>> this depends on the progress ;-)
>
> Perfect.
>
>>> Note that https://issues.apache.org/ooo/show_bug.cgi?id=118895 is still
>>> not solved ...
>> here we might run into a problem because of not having the translation
>> process in place 100%. We have to figure out which translation data is
>> the latest one, it's still not 100% clear if we really have it :-(
>
> OK, but still a Writer context menu like the one shown in
> https://issues.apache.org/ooo/attachment.cgi?id=77204
> (it's supposed to be German) is clearly a release blocker.
>
> I'll have a look at the data Andre Fischer provided as soon as possible,
> and I'll ask our localization people to check whether we (meaning both
> the AOO project and our translation team, from possible backups) have
> the latest strings for Italian, that has more or less the same problems
> shown in the German screenshot above.
That would be great.
I hope that next week I find the time to look at the issue and find out
a) if the translation(s) is (are) present and
b) how much work it is to integrate it.
-Andre
>
> Regards,
> Andrea.
Re: [RELEASE]: preparation for our first release
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 2/24/12 12:40 PM, Andrea Pescetti wrote:
> Jürgen Schmidt wrote:
>> RC should be used indeed only if we think that it can be released, and
>> this depends on the progress ;-)
>
> Perfect.
>
>>> Note that https://issues.apache.org/ooo/show_bug.cgi?id=118895 is still
>>> not solved ...
>> here we might run into a problem because of not having the translation
>> process in place 100%. We have to figure out which translation data is
>> the latest one, it's still not 100% clear if we really have it :-(
>
> OK, but still a Writer context menu like the one shown in
> https://issues.apache.org/ooo/attachment.cgi?id=77204
> (it's supposed to be German) is clearly a release blocker.
>
> I'll have a look at the data Andre Fischer provided as soon as possible,
> and I'll ask our localization people to check whether we (meaning both
> the AOO project and our translation team, from possible backups) have
> the latest strings for Italian, that has more or less the same problems
> shown in the German screenshot above.
perfect because we need the feedback here from people who understand the
strings ;-) Based on this we can probably do a one time conversion from
po to sdf directly. But we need to know which data we have to use.
Improving and establishing a working translating process will be a high
prio for the future.
Juergen
>
> Regards,
> Andrea.
Re: [RELEASE]: preparation for our first release
Posted by Andrea Pescetti <pe...@apache.org>.
Jürgen Schmidt wrote:
> RC should be used indeed only if we think that it can be released, and
> this depends on the progress ;-)
Perfect.
>> Note that https://issues.apache.org/ooo/show_bug.cgi?id=118895 is still
>> not solved ...
> here we might run into a problem because of not having the translation
> process in place 100%. We have to figure out which translation data is
> the latest one, it's still not 100% clear if we really have it :-(
OK, but still a Writer context menu like the one shown in
https://issues.apache.org/ooo/attachment.cgi?id=77204
(it's supposed to be German) is clearly a release blocker.
I'll have a look at the data Andre Fischer provided as soon as possible,
and I'll ask our localization people to check whether we (meaning both
the AOO project and our translation team, from possible backups) have
the latest strings for Italian, that has more or less the same problems
shown in the German screenshot above.
Regards,
Andrea.
Re: [RELEASE]: preparation for our first release
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 2/24/12 11:53 AM, Andrea Pescetti wrote:
> On 24/02/2012 Jürgen Schmidt wrote:
>> And I would like to propose the following schedule depending on the
>> progress we will make next week.
>> Monday: Feb. 27th new dev snapshots
>> Monday: March 5th first RC candidate (based on the progress next week)
>
> This is (of course) great and exciting news. I would only recommend to
> avoid the temptation to be marketing-driven... let RC1 be something that
> we believe we could actually release. There's nothing bad in using the
> name "dev" or "beta" for something that is not ready yet. This is how I
> interpret the "depending on progress" above, and it would be very good
> and show respect for users.
RC should be used indeed only if we think that it can be released, and
this depends on the progress ;-)
>
>> - translation update, we have made minimal UI changes only and we will
>> use the 3.4 beta translation that were in place.
>
> Note that https://issues.apache.org/ooo/show_bug.cgi?id=118895 is still
> not solved: it might be that the 3.4 beta translations are not
> integrated in our current dev builds, or, more likely, that language
> packs are not being built correctly. I've just set that issue as a
> release blocker.
> Using the 3.4-beta translations would be OK, but we need the full set,
> not what we have now (see issue page).
here we might run into a problem because of not having the translation
process in place 100%. We have to figure out which translation data is
the latest one, it's still not 100% clear if we really have it :-(
>
> We will also need to:
> - Decide the URLs for all links in the suite (Extensions, Templates,
> Suite Updates, Extensions Updates...).
I hope the links wouldn't really change, but it have to be clarified
> - Describe the 3.3 -> 3.4 migration path; it would be good to avoid the
> need to reinstall extensions, but I don't know the current state of the
> art here.
that can't be avoided because of the removed berkeley DB. Not nice but
we can't avoid it.
Juergen
Re: [RELEASE]: preparation for our first release
Posted by Andrea Pescetti <pe...@apache.org>.
On 24/02/2012 Jürgen Schmidt wrote:
> And I would like to propose the following schedule depending on the
> progress we will make next week.
> Monday: Feb. 27th new dev snapshots
> Monday: March 5th first RC candidate (based on the progress next week)
This is (of course) great and exciting news. I would only recommend to
avoid the temptation to be marketing-driven... let RC1 be something that
we believe we could actually release. There's nothing bad in using the
name "dev" or "beta" for something that is not ready yet. This is how I
interpret the "depending on progress" above, and it would be very good
and show respect for users.
> - translation update, we have made minimal UI changes only and we will
> use the 3.4 beta translation that were in place.
Note that https://issues.apache.org/ooo/show_bug.cgi?id=118895 is still
not solved: it might be that the 3.4 beta translations are not
integrated in our current dev builds, or, more likely, that language
packs are not being built correctly. I've just set that issue as a
release blocker.
Using the 3.4-beta translations would be OK, but we need the full set,
not what we have now (see issue page).
We will also need to:
- Decide the URLs for all links in the suite (Extensions, Templates,
Suite Updates, Extensions Updates...).
- Describe the 3.3 -> 3.4 migration path; it would be good to avoid the
need to reinstall extensions, but I don't know the current state of the
art here.
Regards,
Andrea.
Re: [RELEASE]: preparation for our first release
Posted by Ross Gardler <rg...@opendirective.com>.
On 25 February 2012 07:54, Pedro Giffuni <pf...@apache.org> wrote:
> On 02/24/12 11:04, Ross Gardler 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.
>>
>> Ross
>
>
> As you know I have pointed out issues there but I am more
> concerned that we really need to put out a release and give
> signs of life soon.
>
> About how much time would be sufficient for the IP
> review, and is there something we can do to help that
> out?
The earlier we start the review the sooner the release will take
place. If the project believes it is ready then now, before the RC is
rolled, is the best time to start the review (see my other mail, with
a more detailed suggestion in reply to Rob).
In terms of "how long". Once a review is requested you will need to
allow a minimum of 72 hours, but expect some late comments.
Unfortunately the real problem occurs when there are contradictory
opinions, these contradictions need to be resolved. Shouting at one
another about the intent of written policy or expecting the other
person to back down because your voice is louder will only serve to
crete entrenched positions that can take a long time.
The thing to do is to take the *specifics* of the case in question to
a JIRA issue for the legal team, provide links to policies both
parties believe are relevant and ask for guidance. The legal team are,
in many cases, very prompt, but sometimes this process can be slow.
The sooner these specific cases get into the legal Jira the better.
The PPMC here needs to be pro-active in identifying any such cases as
early as possible. Waiting for an RC to be built will only delay
things if such cases exist.
> Please note that we have open JIRA issues that need to be
> resolved: at least the copyleft dictionaries and the OFL are
> issues that we identified long ago.
Exactly my point, although I was not referring to any specific issues.
My observations are more general in nature.
Ross
>
> best regards,
>
> Pedro.
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: [RELEASE]: preparation for our first release
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Ross;
On 02/24/12 11:04, Ross Gardler 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.
>
> Ross
As you know I have pointed out issues there but I am more
concerned that we really need to put out a release and give
signs of life soon.
About how much time would be sufficient for the IP
review, and is there something we can do to help that
out?
Please note that we have open JIRA issues that need to be
resolved: at least the copyleft dictionaries and the OFL are
issues that we identified long ago.
best regards,
Pedro.
Re: [RELEASE]: preparation for our first release
Posted by Jürgen Schmidt <jo...@googlemail.com>.
Am Samstag, 25. Februar 2012 schrieb O.Felka :
> Am 25.02.2012 01:06, schrieb Rob Weir:
>
>> On Feb 24, 2012, at 11:05 AM, Ross Gardler<rg...@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.
>>
>> 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. But the most effective way to
>> uncover these unwritten rules is by proposing a RC for a release vote.
>>
>
> A release by votes? Wouldn't it be better to have some
> concrete release criteria?
> Having some quality goals that must be reached?
it is not contradictory and have I pointed out that we don't release if
there are valid concerns.
We will release when we don't have critical show stopper issues. And
discussion on show stopper issues should take place on ooo-dev when issues
marked as critical.
I don't think we have to define the rules for show stopper issues again and
can use the existing ones (e.g. crashes, data loss, ...)
I hope people will take it serious and don't vote against a release without
valid concerns.
Juergen
> Groetjes,
> Olaf
>
Re: [RELEASE]: preparation for our first release
Posted by Ross Gardler <rg...@opendirective.com>.
On 25 February 2012 16:56, O.Felka <ol...@gmx.de> wrote:
> Am 25.02.2012 01:06, schrieb Rob Weir:
>
>> On Feb 24, 2012, at 11:05 AM, Ross Gardler<rg...@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.
>>
>> 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. But the most effective way to
>> uncover these unwritten rules is by proposing a RC for a release vote.
>
>
> A release by votes? Wouldn't it be better to have some
> concrete release criteria?
> Having some quality goals that must be reached?
It is expected that the release vote is only called for after the
release criteria and quality goals have been agreed upon and
delivered by the (P)PMC.
In the ASF anyone can create and publish a release as long as there
are no legal barriers to that release and the majority of the PPMC
wish to see the release proceed. A release cannot be vetoed unless for
supported legal reasons. Objections based on quality and features only
count towards a majority. Again, my comments above are based on the
assumption that the PPMC (or someone willing to be release manager)
believes there would be a majority in favour of a release and
therefore the vote is simply to indicate, as far as is possible,
sufficient oversight to allow the ASF to protect its committers in the
event of a legal problem.
Don't confuse voting with decision making. We don't make decisions
with votes, we make decisions with actions. If someone wants a
specific feature or quality improvement in a release the only way to
ensure it is there to implement it.
Ross
Re: [RELEASE]: preparation for our first release
Posted by "O.Felka" <ol...@gmx.de>.
Am 25.02.2012 01:06, schrieb Rob Weir:
> On Feb 24, 2012, at 11:05 AM, Ross Gardler<rg...@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.
>
> 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. But the most effective way to
> uncover these unwritten rules is by proposing a RC for a release vote.
A release by votes? Wouldn't it be better to have some
concrete release criteria?
Having some quality goals that must be reached?
Groetjes,
Olaf
Re: [RELEASE]: preparation for our first release
Posted by Jürgen Schmidt <jo...@googlemail.com>.
Am Samstag, 25. Februar 2012 schrieb Ross Gardler :
> On 25 February 2012 05:36, Rob Weir <rabastus@gmail.com <javascript:;>>
> wrote:
> > On Feb 24, 2012, at 11:05 AM, Ross Gardler <rgardler@opendirective.com<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 ;-)
Juergen
> 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
>
Re: [RELEASE]: preparation for our first release
Posted by Rob Weir <ro...@apache.org>.
On Sat, Feb 25, 2012 at 6:07 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 25 February 2012 05:36, Rob Weir <ra...@gmail.com> wrote:
>> On Feb 24, 2012, at 11:05 AM, Ross Gardler <rg...@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
Re: [RELEASE]: preparation for our first release
Posted by Ross Gardler <rg...@opendirective.com>.
On 25 February 2012 05:36, Rob Weir <ra...@gmail.com> wrote:
> On Feb 24, 2012, at 11:05 AM, Ross Gardler <rg...@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.
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
Re: [RELEASE]: preparation for our first release
Posted by Rob Weir <ra...@gmail.com>.
On Feb 24, 2012, at 11:05 AM, Ross Gardler <rg...@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.
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. But the most effective way to
uncover these unwritten rules is by proposing a RC for a release vote.
Of course we should first make sure were following all the written
rules.
-Rob
> Ross
>
> 2012/2/24 Jürgen Schmidt <jo...@googlemail.com>:
>> Hi,
>>
>> we move closer forward to our first release.
>>
>> I would like to suggest that we focus on the following areas next week. And
>> I would like to propose the following schedule depending on the progress we
>> will make next week.
>>
>>
>> Monday: Feb. 27th new dev snapshots
>> Monday: March 5th first RC candidate (based on the progress next week)
>>
>> - increase QA work
>> - focus on stabilization, means focus on showstopper issues
>> - finalize the About dialog information, input for future bug reports
>> - online update service
>>
>> - updating building guides in the wiki
>>
>>
>> - documentation update can be run in parallel and are independent of the
>> binary release
>> - translation update, we have made minimal UI changes only and we will use
>> the 3.4 beta translation that were in place.
>>
>> Anything else that comes into your minds?
>>
>> I have started to work on the MacOS building guide and have simplified some
>> things (work ongoing).
>>
>> We need some volunteers who take a look on the other platforms. Especially
>> reference to the hg repo should be removed/replaced to our svn repo.
>> Information about childworkspaces can be removed because it is not longer
>> relevant for us. I would say the focus should be on simplification.
>>
>> What do others think about it?
>>
>> Juergen
>
>
>
> --
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective http://opendirective.com
Re: [RELEASE]: preparation for our first release
Posted by Ross Gardler <rg...@opendirective.com>.
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.
Ross
2012/2/24 Jürgen Schmidt <jo...@googlemail.com>:
> Hi,
>
> we move closer forward to our first release.
>
> I would like to suggest that we focus on the following areas next week. And
> I would like to propose the following schedule depending on the progress we
> will make next week.
>
>
> Monday: Feb. 27th new dev snapshots
> Monday: March 5th first RC candidate (based on the progress next week)
>
> - increase QA work
> - focus on stabilization, means focus on showstopper issues
> - finalize the About dialog information, input for future bug reports
> - online update service
>
> - updating building guides in the wiki
>
>
> - documentation update can be run in parallel and are independent of the
> binary release
> - translation update, we have made minimal UI changes only and we will use
> the 3.4 beta translation that were in place.
>
> Anything else that comes into your minds?
>
> I have started to work on the MacOS building guide and have simplified some
> things (work ongoing).
>
> We need some volunteers who take a look on the other platforms. Especially
> reference to the hg repo should be removed/replaced to our svn repo.
> Information about childworkspaces can be removed because it is not longer
> relevant for us. I would say the focus should be on simplification.
>
> What do others think about it?
>
> Juergen
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: [RELEASE]: preparation for our first release
Posted by Kay Schenk <ka...@gmail.com>.
2012/2/24 Jürgen Schmidt <jo...@googlemail.com>
> Hi,
>
> we move closer forward to our first release.
>
> I would like to suggest that we focus on the following areas next week.
> And I would like to propose the following schedule depending on the
> progress we will make next week.
>
>
> Monday: Feb. 27th new dev snapshots
> Monday: March 5th first RC candidate (based on the progress next week)
>
> - increase QA work
> - focus on stabilization, means focus on showstopper issues
> - finalize the About dialog information, input for future bug reports
> - online update service
>
well...a tiny little breakthrough on the update service...
I did the following today--
* reassigned the old update service ( update36.services.openoffice.org) to
the current web server IP via my /etc/host file
* created a ProductUpdateService directory on www.openoffice.org and dumped
Ariel's atom feed file into the directory with the name check.Update
Now, on my exisiting OOo3.3, when I click "Check for updates", it *gets*
somewhere but of course, my system is expecting an ".rpm" package and not a
tar ball as spec'd in the DL url, so nothing happens. Really I didn't try
to find something reasonable, I just wanted to see if the ideas I had about
re-routing the connection would work.
Bottom line. I think we should have infra also make this DNS change. At
least folks with current "auto upgrades" will not continue to suffer from
NO conenctions AND we now have an place to test/implement the feed,
assuming we can get it in the right format for what we will be releasing
with 3.4.
Thoughts?
ps. I will copy all this to the previous thread/post on the update service
as well.
> - updating building guides in the wiki
>
>
> - documentation update can be run in parallel and are independent of the
> binary release
> - translation update, we have made minimal UI changes only and we will use
> the 3.4 beta translation that were in place.
>
> Anything else that comes into your minds?
>
> I have started to work on the MacOS building guide and have simplified
> some things (work ongoing).
>
> We need some volunteers who take a look on the other platforms. Especially
> reference to the hg repo should be removed/replaced to our svn repo.
> Information about childworkspaces can be removed because it is not longer
> relevant for us. I would say the focus should be on simplification.
>
> What do others think about it?
>
> Juergen
>
--
----------------------------------------------------------------------------------------
MzK
"Follow your bliss."
-- attributed to Joseph Campbell