On 04/16/2012 02:21 PM, drew wrote:
Howdy,
I have a few basic questions - sorry if this has been covered and I
missed it.
How extensive an announcement are we looking for with this?
can't answer this one ...yet...
The files are not on the mirror system at this moment, right, so it's
premature to blast out to the full user base, correct?
Correct, these developer builds are not on ANY mirrors, only from the
wiki. I'm sure after this release, things will get better vis a vis,
what's where.
Will the RC files go to the mirrors,
yes, but there is considerable discussion at the moment over WHICH
mirror system -- Apache, MirroBrain, or Sourceforge. You may want to
check out the rather lengthy discussion that started here:
http://markmail.org/thread/zfdsn2bbkikirdjg
and which I posted an additional response with a different subject at:
http://markmail.org/message/igjzrxtdecuug4ib
BTW, and I suppose in the same
question - will the download pages on the main ooo site be used for RC
as in the past?
This will be the starting point as in years past -- yes...we'll change
the DL location parameters. The same information must be gathered from
the requesting user.
If so then that is the point at which we want to promote
the RC more broadly, so I would think.
Stay tuned. :) My feeling is there are still some "bugs" vs "show
stopper" issues that are being dealt with, and other formalities. And,
there are setup issues relating to the mirror system which needs to be
undertaken first.
Thanks,
//drew
On Mon, 2012-04-16 at 13:37 -0700, Dennis E. Hamilton wrote:
If you haven't already, you can follow the creation and availability of the
unofficial developer snapshots for Apache OpenOffice 3.4 on the Community Wiki:
<https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots>.
There is now unofficial packaging (in they are not qualified as releases) of
release candidates. These are considered potentially stable enough for release
and the necessary structure for being Apache-releasable is introduced:
<https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+%28incubating%29+Release+Candidate>.
There can be several release candidates before one is approved for release.
The candidates reflect a revision level that is considered free of release
blockers. It is not unusual for there to be some deficiency that leads to
replacement of a candidate with another.
It is valuable to have quality assurance and other exploratory use of these
candidates by those in the community who feel comfortable using software at
this stage of development.
Designation of this first AOO 3.4 release candidate is the opportunity for
expanded review and scrutiny of the software for confirmation of the
candidate's readiness.
HOW TO PARTICIPATE
Release candidates should be handled as carefully as the unofficial snapshots.
In particular, the release candidate will replace a production installation of
OpenOffice 3.x if one is present. (This can't be helped - the candidate must
install and behave exactly as the final release would.)
It is recommended that installation be under conditions where any failure is
not costly. If installation is over an existing OpenOffice 3.x, be sure to have
a way to recover the older version if you find it necessary to remove the
candidate.
You can learn more about what the Apache OpenOffice 3.4 release will offer at
< https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Release+Notes>.
There is more about the technical configuration of release artifacts too. This
applies to release candidates as well:
<https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Release+FAQ>.
Defects and issues noticed in the candidate can be recorded in the Bugzilla.
Indicate that you are using the candidate by either the candidate number (e.g.,
RC1) or by the revision number (r1325589) associated with it. The Help | About
menu of the software provides the identifier as well.
QUESTIONS?
Questions you might have around how to contribute to the confirmation of a
candidate can be asked on ooo-dev.
Problems using associated materials are also important to identify before wider
release happens. Any difficulties with related materials and in learning how
to work with the candidate are important to identify.
SUGGESTIONS?
The more ways that usage of a candidate and releases can be confirmed and
reported by contributors to the project, the greater will be the ease and
reliability with which Apache OpenOffice releases will be adopted. Ideas for
how attention from a widespread group of hands-on contributors can be
encouraged and supported are welcome.
--
------------------------------------------------------------------------
MzK
"Women and cats will do as they please,
and men and dogs should relax and get used to the idea."
-- Robert Heinlein
