Justin Erenkrantz wrote:
> On 7/10/06, C. Michael Pilato <cmpilato@collab.net> wrote:
>
>> I didn't pitch the IZ idea as a solution for a "constipated" release
>> process. I pitched it as a solution for the effective opacity of release
>> process. If you want to debate the guts of the process itself, do so
>> elsewhere (like, say, that thread that's already ongoing about how
>> constipated our release process is).
>
>
> What's wrong with using the STATUS file instead? -- justin
I dunno. What *is* wrong with using the STATUS file instead? Was that
suggested somewhere?
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
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)
* and whose location changes with each minor release
* and which can only recieve direct input from folks with commit access.
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.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Jul 11 18:03:56 2006