Re: Expanding Review and Contributions as AOO 3.4 Approaches
On 04/16/2012 03:05 PM, Dennis E. Hamilton wrote: Short answer: At Apache, release candidates are not releases and don't appear anywhere that releases do. With respect to the outside world, they are unofficial, intermediate work. - Dennis This is my understanding: The RC artifacts are made available the same way as developer snapshots and previews. (If you look at the links, you'll see that the RC1 artifacts are on the release manager's Apache account.) The difference is that a release candidate is packaged in the form of artifacts on which release votes happen. When a release vote is held and passes, those are the artifacts that will then be put up as a release, populated on mirrors, etc. Since these candidates are not releases, it is inappropriate to notify the user base, make an ASF announcement, etc. They should not be provided at the download page either. Dennis and others-- Yes, trying to track down some other things, it is VERY clear that pre-releases, like these, should ONLY be announced on the dev list. http://www.apache.org/dev/release LOTS of info in this, and, much of it, well, different than what some of use are used to. In some sense, there is a feature and code freeze in effect for the release, except for any necessary repairs that require a new candidate to be produced. The need for repair can come about as part of the in-Apache review of the candidate and independently as the result of a release-blocking defect reported by anyone. Because of that level of stability, this is a time when investment of any volunteer testing, trial use, etc., is valuable in both how the candidate deploys and how it is usable. It's not a moving target and additional explorations are well-spent, especially for any show-stopper that is uncovered. - Dennis -Original Message- From: drew [mailto:d...@baseanswers.com] http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201204.mbox/%3c1334611284.19386.7.camel@sybil-gnome%3e Sent: Monday, April 16, 2012 14:21 To: dennis.hamil...@acm.org Cc: OOo-dev Apache Incubator; 'Louis Suárez-Potts' Subject: Re: Expanding Review and Contributions as AOO 3.4 Approaches 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? 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? Will the RC files go to the mirrors, 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? If so then that is the point at which we want to promote the RC more broadly, so I would think. Thanks, //drew On Mon, 2012-04-16 at 13:37 -0700, Dennis E. Hamilton wrote: http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201204.mbox/%3c01df01cd1c10$b4f45ba0$1edd12e0$@acm.org%3e [ ... ] -- MzK Women and cats will do as they please, and men and dogs should relax and get used to the idea. -- Robert Heinlein
Re: Expanding Review and Contributions as AOO 3.4 Approaches
On Mon, Apr 16, 2012 at 5:21 PM, drew d...@baseanswers.com 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? 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? Take a look a [DISCUSS] post I put over on ooo-marketing earlier today. Am trying to consolidate all the ideas circling about regarding how best to announce AOO 3.4to the various stakeholders and communities that depend on us. *http://s.apache.org/9aE * Will the RC files go to the mirrors, 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? If so then that is the point at which we want to promote the RC more broadly, so I would think. 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.
Re: Expanding Review and Contributions as AOO 3.4 Approaches
On 04/16/2012 03:05 PM, Dennis E. Hamilton wrote: Short answer: At Apache, release candidates are not releases and don't appear anywhere that releases do. With respect to the outside world, they are unofficial, intermediate work. - Dennis This is my understanding: The RC artifacts are made available the same way as developer snapshots and previews. (If you look at the links, you'll see that the RC1 artifacts are on the release manager's Apache account.) The difference is that a release candidate is packaged in the form of artifacts on which release votes happen. When a release vote is held and passes, those are the artifacts that will then be put up as a release, populated on mirrors, etc. yes, OK, perfectly clear... and the usual I think Since these candidates are not releases, it is inappropriate to notify the user base, make an ASF announcement, etc. They should not be provided at the download page either. In some sense, there is a feature and code freeze in effect for the release, except for any necessary repairs that require a new candidate to be produced. The need for repair can come about as part of the in-Apache review of the candidate and independently as the result of a release-blocking defect reported by anyone. Because of that level of stability, this is a time when investment of any volunteer testing, trial use, etc., is valuable in both how the candidate deploys and how it is usable. It's not a moving target and additional explorations are well-spent, especially for any show-stopper that is uncovered. got it...which is also why the packs available on the wiki are called unofficial developer snapshots rather than official developer snapshots I think. Really, this is a VERY confusing point for me. :( - Dennis -Original Message- From: drew [mailto:d...@baseanswers.com] http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201204.mbox/%3c1334611284.19386.7.camel@sybil-gnome%3e Sent: Monday, April 16, 2012 14:21 To: dennis.hamil...@acm.org Cc: OOo-dev Apache Incubator; 'Louis Suárez-Potts' Subject: Re: Expanding Review and Contributions as AOO 3.4 Approaches 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? 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? Will the RC files go to the mirrors, 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? If so then that is the point at which we want to promote the RC more broadly, so I would think. Thanks, //drew On Mon, 2012-04-16 at 13:37 -0700, Dennis E. Hamilton wrote: http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201204.mbox/%3c01df01cd1c10$b4f45ba0$1edd12e0$@acm.org%3e [ ... ] -- MzK Women and cats will do as they please, and men and dogs should relax and get used to the idea. -- Robert Heinlein
Re: Expanding Review and Contributions as AOO 3.4 Approaches
WE DON'T HAVE A RELEASE CANDIDATE YET!!! To avoid confusion the referenced wiki page was prepared in preparation for our first RC but we have to fix a further issue. The availability of the RC will be communicated here on the list. Juergen On 4/16/12 10:37 PM, 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.
Expanding Review and Contributions as AOO 3.4 Approaches
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.
Re: Expanding Review and Contributions as AOO 3.4 Approaches
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? 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? Will the RC files go to the mirrors, 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? If so then that is the point at which we want to promote the RC more broadly, so I would think. 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.
Re: Expanding Review and Contributions as AOO 3.4 Approaches
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
RE: Expanding Review and Contributions as AOO 3.4 Approaches
There is nothing to prevent us from going through the ASF release process and then calling the approved release Apache OpenOffice 3.4 RC1 although as far as ASF is concerned, it is evidently a release, it is preserved as a release, the source tarball is captured for the release, etc., etc. So the question would then be, why would this not be Apache OpenOffice 3.4.0? That is how the r1325589/RC1 downloads are identified. (It looks like the three packagings of source tarballs should have had the same identifier, rather than just a00-3.4-incubating-src.*). I don't believe the Apache release candidates go anywhere but where they are. Once they achieve release status, the dam bursts. But, in Apache terms, they are no longer candidates. - Dennis -Original Message- From: Kay Schenk [mailto:kay.sch...@gmail.com] http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201204.mbox/%3c4f8c9a8b.6080...@gmail.com%3e Sent: Monday, April 16, 2012 15:10 To: ooo-dev@incubator.apache.org Subject: Re: Expanding Review and Contributions as AOO 3.4 Approaches On 04/16/2012 02:21 PM, drew wrote: http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201204.mbox/%3c1334611284.19386.7.camel@sybil-gnome%3e [ ... ] 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. [ ... ]
