[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Fwd: Proposal: RCs with ZERO overhead

From: Tobias Schäfer <tobiasschaefer_at_gmx.de>
Date: 2006-06-19 16:43:49 CEST

On Monday 19 June 2006 11:38, Stefan Küng wrote:
> On 6/18/06, Tobias Schäfer <tobiasschaefer@gmx.de> wrote:
> Good idea. Replying is much easier :)
>
> Should we create a new mailing list for this? I think the dev list
> could handle those few mails, after all, they're only text (no
> attachments). And I'm sure the testers will just reply again if they
> find a bug to report. And those definitely belong on the dev list.
> So I'm in favour of keeping that on the dev list.
> Other opinions/reasons?

Let's send the mail to dev@ first. Once the process has stabilized we could
send it to users@ instead. This would increase the number of testers and
might get more people get involved in TSVN. Since we consider all changes
we merge into the branch as stable, I don't see a problem in informing
users@ instead of dev@.

> But the signing process happens *after* the subversion devs have
> tested a tarball. Our mail-based system would require those mails to
> be sent right *before* they test, i.e. when they *start* testing by
> simply installing it.
> So I'd say that such a release could be considered 'signed' about x
> days after y testers replied to such a mail.
>
> Now, let's define x and y.
> My suggestion:
> x = 5
> y = 5

We currently have 50 votes for "Sure - I would install, test and report bugs
back to the mailing list" so that is a threshold we should be able to reach
and which assures that a RC has been tested enough.

Tobias

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jun 19 16:44:53 2006

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.