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

Re: Suggestion: Track Subversion release process in our issue tracker

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2006-07-11 18:40:15 CEST

On 7/11/06, C. Michael Pilato <cmpilato@collab.net> wrote:
> I dunno. What *is* wrong with using the STATUS file instead? Was that
> suggested somewhere?

That's what we've been using, or at least that's what I thought.

> For my part, I think I'd prefer an issue tracking issue:
> * associated with a single release
> * that reveals the whole change history to casual website visitors
> * and can be located via a single web link that shows "all open release
> process issues" (of which there is generally ever only one at a time)
> * and even be annotated by non-committer testers of the tarball with
> notes about failing tests or whatever

Given how hard it is to access IZ when I'm on the road, I'd really
prefer not to go to a web-based process for release management. With
STATUS, I can review the proposed changes with just my WC and peruse
my local store of commit notifications and vote. When I go back
online, I can commit my changes and stuff. If we move that to
Bugzilla, then well, I just won't bother any more because I can't keep
up with that.

> to a version-controlled file:
> * associated with multiple releases (1.4.0-rc1, 1.4.0.rc2, ... ,
> 1.4.1, ... 1.4.n)
> * whose change history is less immediately visible (unless you visit
> via ViewVC or something)

I'm not sure that the change history is immediately necessary - only
the current version is.

> * and whose location changes with each minor release

The STATUS location is per branches. i.e. branches/1.4.x/STATUS, etc.

> * and which can only recieve direct input from folks with commit access.

They shouldn't be using an issue tracker either for pre-release
feedback (as we haven't released it yet!) - that's why we have a
mailing list. The STATUS file can act as *our* coordination

> But I'm admittedly used to being issue-tracker-driven on a daily basis here
> at CollabNet.
> Have you an alternative proposition that involves the STATUS file you'd like
> to put out there? This isn't a matter of pride or anything -- let's find
> the solution that meets everyone's needs, and let's try it out for RC2.

I'm admittedly partial to httpd's STATUS.


It's an extension of what we already do: it tracks the releases, any
showstoppers, etc. We could even ask people to record their votes in
the STATUS file in addition to the list. -- justin

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 11 18:40:45 2006

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

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