You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Michael Price <mp...@atl.lmco.com> on 2003/02/20 22:38:17 UTC
RFC: CHANGES proposal.
I would like to open up a discussion on the way the CHANGES file is
handled.
Right now it, uh, isn't.
I would like to propose the following change in the way we do
things. When you commit what you know is a user-visible change then you
also update the CHANGES file with an appropriate comment. After all, if
you are doing something like adding new command line options or changing
the layout of config files then there isn't much doubt about whether or
not its going into the file so it might as well go in right away.
Developer-visible changes are more transitory in nature and have a way
of disappearing as fast as they arrived so I can see delaying those
entries until the actual release.
So what does everyone think?
Michael Price Member of the Engineering Staff
Distributed Processing Lab; Lockheed Martin Adv. Tech. Labs
A&E 3W; 1 Federal Street; Camden, NJ 08102
856-338-4021, fax 856-338-4144 email: mprice@atl.lmco.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: CHANGES proposal.
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Justin Erenkrantz wrote:
> I'm kind of against the developer who wrote the changes making the
> CHANGES entry because I see us do it in httpd and APR and frankly, we
> are absolutely atrocious at it. It's really hard for some developers
> to figure out what is 'user-visible,' 'developer-visible,' or
> neither. No amount of prompting is going to help as you run the risk
> of being a pest and getting on someone's blacklist yourself. =)
>
> 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 agree with justin. it takes a bit of effort on the part of the
release manager, but i think we end up with something much more readable
in return.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: CHANGES proposal.
Posted by cm...@collab.net.
Justin Erenkrantz <je...@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.
>
> But, that's just me. -- justin
Me, too. I find, for example, that Ben does a great job of keeping
the changes concise enough to fit on a line, yet detailed enough to
make sense. There is a certain amount of skill present there, and I
foresee time wasted when those who do not possess that skill have
their CHANGES mods corrected by those who do.
Also, the one time I've actually done the CHANGES updates for a
release (or at least part of them), I was thrilled by how much of a
"big picture" understanding of that release I was able to gain. A
release manager is effectively taking responsibility for an entire set
of changes being tossed into the general public. I think an RM should
have that "big picture" understanding of what he or she is claiming as
good, and the CHANGES updates pretty much force that to happen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: CHANGES proposal.
Posted by Michael <mi...@ispwest.com>.
Greg Stein writes:
> 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.
Well, technically you are supposed to test the tarball -- not just the
revision. Either way its not a big deal so since everyone and their
mother apparently hates the CHANGES file I'll just deal with it.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: CHANGES proposal.
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Feb 21, 2003 at 10:08:12AM -0600, Karl Fogel wrote:
> Justin Erenkrantz <je...@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
Re: RFC: CHANGES proposal.
Posted by Michael Price <mp...@atl.lmco.com>.
Karl Fogel writes:
> Justin Erenkrantz <je...@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.
Yeh, what he said. :)
Michael Price Member of the Engineering Staff
Distributed Processing Lab; Lockheed Martin Adv. Tech. Labs
A&E 3W; 1 Federal Street; Camden, NJ 08102
856-338-4021, fax 856-338-4144 email: mprice@atl.lmco.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: CHANGES proposal.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Justin Erenkrantz <je...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: RFC: CHANGES proposal.
Posted by Sander Striker <st...@apache.org>.
> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> Sent: Friday, February 21, 2003 4:30 PM
> I'm kind of against the developer who wrote the changes making the
> CHANGES entry because I see us do it in httpd and APR and frankly, we
> are absolutely atrocious at it. It's really hard for some developers
> to figure out what is 'user-visible,' 'developer-visible,' or
> neither. No amount of prompting is going to help as you run the risk
> of being a pest and getting on someone's blacklist yourself. =)
>
> 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.
>
> But, that's just me. -- justin
And me.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: CHANGES proposal.
Posted by Justin Erenkrantz <je...@apache.org>.
--On Thursday, February 20, 2003 5:38 PM -0500 Michael Price
<mp...@atl.lmco.com> wrote:
> I would like to propose the following change in the way we do
> things. When you commit what you know is a user-visible change then
> you also update the CHANGES file with an appropriate comment. After
> all, if you are doing something like adding new command line
> options or changing the layout of config files then there isn't
> much doubt about whether or not its going into the file so it might
> as well go in right away.
>
> Developer-visible changes are more transitory in nature and have a
> way of disappearing as fast as they arrived so I can see delaying
> those entries until the actual release.
>
> So what does everyone think?
I'm kind of against the developer who wrote the changes making the
CHANGES entry because I see us do it in httpd and APR and frankly, we
are absolutely atrocious at it. It's really hard for some developers
to figure out what is 'user-visible,' 'developer-visible,' or
neither. No amount of prompting is going to help as you run the risk
of being a pest and getting on someone's blacklist yourself. =)
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.
But, that's just me. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: CHANGES proposal.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Michael Price <mp...@atl.lmco.com> writes:
> I would like to open up a discussion on the way the CHANGES file is
> handled.
>
> Right now it, uh, isn't.
>
> I would like to propose the following change in the way we do
> things. When you commit what you know is a user-visible change then you
> also update the CHANGES file with an appropriate comment. After all, if
> you are doing something like adding new command line options or changing
> the layout of config files then there isn't much doubt about whether or
> not its going into the file so it might as well go in right away.
This seems reasonable.
The job of the release manager would then be to condense what's
already there, for the user-visible changes at least (it may be that
several entries added at different times can be condensed into one).
> Developer-visible changes are more transitory in nature and have a way
> of disappearing as fast as they arrived so I can see delaying those
> entries until the actual release.
More importantly, you can't judge an individual code change's
importance until you have all the other changes to compare it to. So
here, it really should be done all at once; otherwise the CHANGES file
will just become a copy of the 'svn log' records.
> So what does everyone think?
+1
However, you may need to watch the commit list and slap people on the
wrist a few times until we get the hang of it.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org