Andrew McIntyre wrote:
On 8/15/07, Jean T. Anderson <[EMAIL PROTECTED]> wrote:
and here's the actual policy from [1]:
"During the process of developing software and preparing a release,
various packages are made available to the developer community for
testing purposes. Do not include any links on the project website that
might encourage non-developers to download and use nightly builds,
snapshots, release candidates, or any other similar package. The only
people who are supposed to know about such packages are the people
following the dev list (or searching its archives) and thus aware of the
conditions placed on the package."
So it's fine to post the location of a snapshot to the mail list so
users can test it. It just isn't fine to make it readily accessible from
a web site because it might (likely) get downloaded for something other
than test purposes.
But it's only ok to post to the dev list, and not the user list, which
means only *really* motivated users are going to go to the effort to
look for snapshot mail posted to the dev list to go test. This really
limits the utility of snapshots, since everyone on the dev list is
capable of generating the contents of a specific revision themselves
if they want to do testing.
I can still see some value in posting a snapshot for developers--at
least until we streamline our release processes. Right now, generating a
snapshot is a bit tricky and I think a lot of developers would be
relieved if a battle-scarred veteran performed this chore.
The counterargument posted in one of the release policy threads
mentioned earlier was that if you really want to get the user
community involved in an alpha or beta test, mark the release
artifacts as such, put it to a proper vote, and if the vote passes,
put it on the mirrors and announce it as a beta release and call for
testing. The quality threshold for a beta release is essentially none,
so a vote to have a beta release will almost necessarily pass, unless
there are legal issues that come up. Having the vote in the archives
shows due diligence to the release process, which is important for any
artifacts that are distributed outside of the development community.
andrew
I think this is a promising idea. It would be great if we could get
early alpha-feedback on 10.4 long before we plunge into the release
proper. The process you describe, however, is awkward for a trunk
snapshot: The snapshooter has to wait a week for a vote to end before
posting the snapshot. On a volatile codebase like trunk, a snapshot's
value degrades rapidly in just a week.
