On 7/11/06, C. Michael Pilato <firstname.lastname@example.org> 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: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Jul 11 18:40:45 2006