[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2006-07-11 19:38:59 CEST

Justin Erenkrantz wrote:
> 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.

Oh, dude, I think you misunderstood my proposal. I think STATUS is the
perfect way to track change backports and such. I don't want to replace
that part of the release process at all. I'm talking about tracking the
portions of the release process that begin with, say, step 6 of release.txt.
 The stuff that's directly related to creating and publishing and testing
and blessing the release tarballs. The stuff that today is "tracked" only
via intermittent emails and IRC conversations.

Users should have extremely easy access to the answer to the question, "How
is the 1.4.0 release process going, and when can I expect to see the final
tarball?" without crawling through mail archives or poking around in the

Developers want to know that stuff too, and IZ is a great way to see the
status and history of that process for a given release. *Additionally*,
developers want the gritty details of the source-code management side of the
release procedure, and for that we (rightly) use STATUS, which lives
alongside the very source code we're managing.

C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Tue Jul 11 19:39:27 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.