On Fri, Feb 21, 2003 at 10:08:12AM -0600, Karl Fogel wrote:
> Justin Erenkrantz <jerenkrantz@apache.org> writes:
> > I'd rather the CHANGES file not end up like the unreadable and
> > unintelligable cruft that we have in httpd. I like Subversion's
> > succint and readable CHANGES file.
>
> I don't think Michael's proposing that he not touch the CHANGES file,
> merely that more of the "prep work" be done, so his job is mainly
> about cleaning up and succinctifying the material already there.
>
> The final contents of the CHANGES file in a release would still be the
> release manager's responsibility.
Yes, but the current practice of "do it right before release" ensures that
you catch everything. If we relied on it being updated for each commit, then
we will invariably see commits that *don't* update the thing, and those will
never be caught. And if the RM is reviewing the commit logs to see if
anything was left out... well, then why did the developers have to do
anything in the first place? :-)
It is understandably a bit painful. However, I would counter that with the
point that we have now moved to a *two* week release cycle instead of the
former three (or more!) week cycle. The number of commit messages to review
will, thus, be even smaller.
Finally, I would point out that this is a very parallelizable activity. You
could have one person handle the CHANGES file, and another person performing
the rest of the RM functions. That file goes in right at the last minute, so
that you get the right date and rev number. The test suites can be run
independent of that final change.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 22 05:59:56 2003