Am 06/12/2013 08:50 PM, schrieb Rob Weir:
On Wed, Jun 12, 2013 at 2:36 PM, Donald Whytock<dwhyt...@apache.org> wrote:
On Wed, Jun 12, 2013 at 2:22 PM, Rory O'Farrell<ofarr...@iol.ie> wrote:
On Wed, 12 Jun 2013 13:35:23 -0400
Rob Weir<robw...@apache.org> wrote:
Something to consider for AOO 4.1 is the value of a broad public beta
program to solicit early feedback on builds. This could be a good
complement to our formal QA efforts.
A beta program could be set up like this:
1) After feature freeze, and after smoke tests pass on the 3 major
platforms, we have a build that has the new code, and doesn't have any
known horrible defects.
2) Immediately create a special Release Candidate for the beta,
English only, or maybe a combination install with 5 major languages.
3) Vote on the release of the beta via the normal 72-hour PMC vote.
Focus on the formal release checks around license, notice, etc.
4) Distribute via SourceForge and/or Apache mirrors. No need to
preserve older betas. We'd only keep the most recent one.
I just want to make sure that we're all aware this option is
available. We can do something that gives wider public exposure than
a dev snapshot build, but is less than a final version. The key thing
is to meet the formal requirements of an Apache release, but set user
expectations that it is a beta.
Regards,
A very major problem is that relatively inexperienced user _will_ download
and use a beta, disregarding any warnings about it being a beta. They will
increase the support workload, as faults may be due to their inexperience,
not to shortcomings in the beta, and certainly the stress level for support
staff as they are hassled to try to obtain recovery of "the most important
file this load of **** has ruined on me".
A lot of projects list multiple versions of their software with the most
"stable" at the top, and other versions provided below with multiple
caveats attached, such as, "This is the most bleeding edge version we've
got right now, download and try at your own risk...but please provide
feedback if you do."
As long as the first entry is described as the stable one, I'd like to
think users would get that one. But I've heard I can be naive.
The concept and expectations of a beta release are well-understood in
the industry. We may have some users who are unfamiliar with the
concept, but we should be able to find a way to make it clear to
everyone.
The important thing, I think, is to avoid giving prominence to the
beta in the default download page. Maybe even have a special beta
page that has extra text setting stability and support expectations,
how to report problems, etc.
In the old project we had one download page for different release modes
with respective colors:
a) green = Stable
b) yellow = Beta's / RC's
c) red= Dev Snapspots
AFAIK this worked good. However, b) and c) had not the
one-click-downloader but were links to separate webpages with download
links.
I found the following wording for Beta's/RC's and Dev Snapshots:
The software in the following table is based on the final release but
the final tests were not done yet. Therefore it cannot be seen as a
released build and it is not recommended to deploy in a production
environment. However, you are invited to use and test these builds.
report (link to Bugzilla) any possible issues. This process is not yet
finished. Please be patient and check back regularly.
Developer Snapshots represent the most recent status of the
OpenOffice.org Development and will be released mostly weekly/biweekly.
Please help us to improve the product quality of OpenOffice.org.
Download and test the latest versions."
These builds have not been fully tested and are under continuous
development. It is not recommended for production use.
With some bold/italic/colors formatting it should be possible to make
the message clear:
Please help us to test the latest and greatest release. However, please
be careful how/when/where to use it on your PC.
Finally:
I like the idea to do a beta program. To bad it's too late for AOO 4. ;-)
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
