Stefan Fuhrmann wrote:
> .. seems it got lost
Not really. But I just got up - hey, it's sunday :)
> There has been a lengthly discussion about
> how to improve the stability (actually: reliability)
> of the TSVN releases.
>
> Lübbe made a good point finding an average
> of 1 out of 3 release being broken. Even though
That's why we stopped releasing directly from trunk and
now only release from a 'stable' branch.
> that number improved over time, we do have
> an issue here since a broken release implies
> a lot of extra work:
>
> * discuss the issue on the @dev list
> * make a whole new release
>
> My proposal:
>
> * build releases as we do today
> * release them on SF in an "RC" package
> containing all installables for all platforms
> (no need to have multiple RC packages,
> imho, since early adopters should be able
> to pick the right ones)
> * announce the RC and encourage users
> to test it
> * if it fails, build another release
> * after 2 weeks, move the installables to their
> respective SF package and bump the version
> file used to check for newer versions
> * announce release
>
> Basically, this is what we are doing today but
> with tagging the packages as "untested" for
> some time. We are trading a minor management
> overhead against reduced @dev traffic (hopefully).
That's exactly what we do today for major releases.
See https://192.168.2.2/svk/tortoisesvn/trunk/Release_procedure.txt
> Comments?
I'm not sure we should do the same for bugfix releases as we already do
for major releases. I don't know of any project out there which does RCs
for bugfix releases. IMHO it wouldn't really help: people realize that
an RC means that the final release is very near, and just wait for the
'real' one. Because installing TSVN always requires a reboot (something
we can't work around).
If I may propose another way:
We try to find people who don't want to test trunk nightlies but are
willing to test the stable nightlies. I think we should have at least
five such people. Every time we merge a fix back to the stable branch
and build the nightly for it, we send a mail out to dev@ and (if they
don't follow the mailing list) to their personal mail, telling about it.
They then download that stable nightly and use that one from that time on.
So, we would need 'stable' testers, which have to follow some few rules:
* install every stable nightly build, when they get notified by mail
* use that nightly build as their main build
* report back any problem they encounter
* if they can't install the nightlies anymore (vacation, no time, ...)
they must tell us so we can find replacements
* maybe (to have some control over who really is using those nightlies)
we could require them to send a short notice every time they install
such a nightly (e.g. subject: installed stable nightly, body=revision
XXXX, date of installation, x64/win32, processor-type (single/dual) ).
> -- Stefan^2
Hmmm - should I sign with 'Stefan^1' from now on? :)
Stefan^1
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Jun 18 09:36:02 2006