pll@lanminds.com writes:
> > * Issue #1287. A new abbrev 'Revision' for 'LastchangeRevision'.
>
> Filed as Issue 1392:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1392
Paul, below is some concrete advice about patch management.
Everything I'll say, though, essentially boils down to:
"Try to see things from the point of view of those for whom the
patches are being managed." :-)
Only by doing so will effective patch management be possible. On to
specifics:
If someone posts a patch for an issue (as for issue #1287 above), then
just attach the patch to the original issue, don't create a new issue.
The reason we have patch management is so that useful patches don't
get lost in the shuffle -- in fact, not only so they don't get lost,
but so they may be found in the places people are most likely to look
for them :-) !
The same goes for several other recently filed patches: the original
issues simply needs to be updated. For example, #1394 is really about
#787, and #1396 is already mentioned in #1378 (take a look at that
issue by the way). This list is not complete, it's just what I
noticed off the top of my head.
Oh, and speaking of #1396: notice how #1378 actually links to the
relevant mailing list thread, instead of just quoting it. That's
crucial, because it allows someone to move from the issue to all the
related discussion conveniently -- even when some of that discussion
happens after the issue was filed.
But the job of patch manager is about more than just finding the right
issue. You also need to be following almost all dev list threads to
some degree, so you can tell a) whether a patch should be filed at
all, or b) if it has already effectively been recorded, because some
issue points to the relevant mailing list thread already or whatever.
And regarding (a): not all patches posted need to be recorded, at
least not right away. For example, you filed issue #1391 regarding
P. Marek's timestamp patch, but if you watch the (still active) dev
list thread about this, you'll see that there is no consensus on the
feature, let alone on this implementation of the feature. There is
some consensus regarding a much simpler subset of the feature; look
for recent posts by Ben Collins-Sussman, I don't remember the exact
subject but it'll be obvious. Also, see issues #1256 and #1112 (hmmm,
which may be dups of each other?).
Anyway, since the thread is active, there is no danger of Marek's
patch being accidentally forgotten about -- hence, the patch manager
doesn't need to do anything yet, except watch the thread and get a
sense of when some sort of closure or other recordable point is
reached.
In short, patch management is not really about following a simple
procedure (tick, tick, tick... bing! time to file that patch). It's
much more touchy-feely than that. The manager has to be broadly
familiar with all the active dev list threads, and with all the issues
in the issue tracker, and always try to do the thing that will be most
useful to someone who's working on an issue, or someone trying to find
patches related to Problem X.
Patch management is a lot of work :-). And it's not as if there was
ever a document exaplaining all aspects of the job (perhaps this mail
should be added to what's already written up?), so I certainly don't
blame you for not realizing the full scope at first. If you think
you're still up to it, then great. But if you didn't know what you
were getting into, and won't have time to follow all the contexts,
that would be understandable too. Let us know.
I hope this helps,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 3 20:10:48 2003