Stefan Küng wrote:
> Not really. But I just got up - hey, it's sunday :)
No worries ;) I just got confused as my later post
already arrived at the list while this one didn't show
up.
> > 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
Not exactly. I forgot to point out that my concern is
with the bugfix releases (.1 and up). The difference
to the current release procedure is that after building
the release we wait for e.g. 2 weeks and announce
it only afterwards as "released" (i.e. update version.txt).
Note, that there is no extra build after the RC
(provided that no regressions are found). As I understand
the RC handling for major releases, the final version
will require an extra build & upload cycle.
> 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.
We do ;) at our company (with an even much more
elaborate process behind).
IMHO, SCM business is a very conservative one.
Accidentally breaking a stable line lowers reputation
quite a bit and weakens the position of SVN advocates
trying to convince their companies to use (T)SVN.
Since I fought that fight 2 years ago, I'm somewhat
sensitive to that issue ;)
My goal was to come up with something that causes
close to no additional effort on your side while still
allowing for user feedback. The difference to just
using stable nightlies is that the actual "soon-to-be-released"
packages will be tested (i.e. no difference in revision,
issues with unclean builds are caught etc.)
> 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).
That, in fact, is a good thing: It keeps "ordinary" users
from jumping on untested releases. Just a few testers
should be enough to catch the most annoying glitches.
> 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.
+1. These don't have to be the same 5 people for
every release (holidays and other schedule problems).
Thus, we should call for testers well in advance of
a particular release. We would try to keep it the same 5
people, though.
Also, we might think of some incentive (most obvious:
listing them in some appropriate place). Testing is a *very*
unpleasant task after all.
> 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.
Hm. Going for a small group of testers implies them to
be in-depth testers. Hence, a test cycle may take a
whole day: Even just clicking every button / menu item
in a meaningful way will take a lot of time.
Therefore, we should inform those testers just as
you said but we shouldn't expect them to do a full test
every time. I would consider it sufficient if they committed
to one in-depth test just before the release.
> 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
Ah .. o.k. So, maybe we should allow the testers to
commit to one (or both) of the following "styles":
* all-day tester: uses the latest stable nightly
* in-depth tester: performs one comprehensive test
including infrequently used features (merging, locking,
remote repository operations etc.)
> * 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) ).
Perhaps not every time they install but as part
of their test feedback. The latter is important for us
to know whether there has been a test at all
- not to blame people that did not test.
> > -- Stefan^2
>
> Hmmm - should I sign with 'Stefan^1' from now on? :)
No need for Borg signatures here ;) I just follow
Lübbes proposal ...
-- Stefan^2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jun 19 23:50:47 2006