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
repository.
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