On Jan 2, 2008 1:15 PM, Jeff Kowalczyk <
..hidden..> wrote:
Chris Travers wrote:
> We basically package the release and submit it for review. In the past
> this has been largely been done by the core team but this was originally
> at least in part due to the fact that we were doing a *lot* more in the
> way of security releases in our early days. There is an argument that
> this should be a more transparent process and I generally agree with
> that.
My question was more along the lines of what the validators did with the
proposed tarball. Is validation an informal loading of real world datasets
and seeing if there are any observable defects?
1) Looking for obvious packaging errors (this was a big one).
2) Reviewing changes to see if there were obvious problems introduced. This works better when the number of bug fixes is small. :-)
> In the past this has meant that we email the release out to everyone
> else. Under my proposal, it would be uploaded to a different package on
> Sourceforge. We should probably append the letter 'v' for a validation
> upload.
Can a proposed release simply be an svn tag URL, with validators
independently svn export'ing an tar/zipping?
That doesn't give us an ability to look for packaging errors. Hopefully once we get to 1.3 (and the use of svn export), that will be feasible, however.
Or, commit the proposed archives to the repository in a
ledgersmb/releases/ svn URL.
Send email to the validators to export and test the tag and/or release
URL, and if there are no problems reported, upload the archives to
sourceforge. If there's a problem and you don't want to increment the
version, the tag can be deleted and the branch tagged again with the name
later.
Doing it within the repository preserves the history of the validation
process.
Agreed. I think when we get to
1.3, I think we will want to do that :-)
Best Wishes,
Chris Travers