db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Snapshots for testing (was: fix versions, etc.)
Date Thu, 16 Aug 2007 15:21:56 GMT
Andrew McIntyre wrote:
> On 8/15/07, Jean T. Anderson <jta@bristowhill.com> 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.


Mime
View raw message