[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r8102 - branches/1.0-stabilization

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2003-12-28 20:57:27 CET

On Sun, Dec 28, 2003 at 12:15:23PM -0600, kfogel@collab.net wrote:
> I've taken most notes out in r8111 (including some that I'd originally
> put in). Please start mailing list threads instead, and link to the
> threads from the STATUS file. Or in some cases, the log message of
> the change, or the associated issue, might be a good place for the
> information formerly in the note.

I don't want to see vetoes be placed in the STATUS file without a
justification. If someone casts a -1 (which is a veto), they can't just
cast a -1 and then run away. They *may* post to a mailing list or they
could forget to update the STATUS file after they posted with the link
to the new thread. Therefore, I believe that veto rationale must be
captured in the STATUS file, so that people can later understand if the
veto has been resolved in an umambiguous manner.

I also think it's *extremely* helpful to have explanations as to why
people are not voting +1 on a patch (some of my notes were on those that
I did not cast +1s on). Therefore, I'd ask that we at least be allowed
to add 'propoganda' for or against a vote in STATUS. Right now, you are
only allowing 'for' with your justification; but forbidding anyone from
disagreeing with that justification or highlighting problems with the
merge candidate. That's a bit unfair, I think.

I believe the point is to have a centralized file with all of the
necessary information. The public can always chime in on a commit, so I
don't buy the barrier of entry concern; and if the STATUS file gets too
wordy on a topic, I think the participants will naturally move to a
mailing list. Yes, it's not for discussion, but it's also not supposed
to be devoid of any supporting evidence pro/con.

As an aside, if we used an issue tracker, people would be placing their
'notes' in their changes, but we chose not to go that route. Also, I
dislike the URLs that you are using for the 'mailing lists', you should
also be adding Message-IDs, so that people can search in their own
archives (for example, when they are off-line). About storing rationale
in a log instead, you'd then need one commit/vote; otherwise, you'll be
conflating multiple votes and rationales which will confuse everyone.

> Knowing that someone agrees with the concept doesn't add very much
> information. It doesn't tell us we can apply the change, because that
> requires actual review and a real +1. Sure, it tells us that
> so-and-so likes the concept, but then, there are probably others who
> feel the same and just didn't bother to say so in the STATUS file (for
> example, there was a whole thread about the copyright fixup change).

As demonstrated by our experiences in httpd-land with the STATUS file, I
think there's value in the concept +1. It's much stronger than a +0 and
indicates that someone has issued a review but they are realizing that
it *could* be wrong or they aren't comfortable with a full +1.

If you don't have a concept +1, then you are forced to either not vote
or vote +0. In practice, that's pretty harmful. So, consider it a
+0.9999, but remember that we only allow four choices: -1, -0, +0, +1.
The +1 (concept) is a fudge, but I think a necessary one. As I
indicated in my commit, the concept voter might be convinced to switch
to a full +1 with some lobbying or help to understand some of the finer
points they missed. A person who casts a +0 probably can't be convinced
to cast a +1 under any circumstances.

Here's an analogy: Consider that a libsvn_fs change was proposed. I
looked at it, said "yeah that's right, but I'm not 100% sure because of
X." Then, C-Mike (master-fu of libsvn_fs) comes along and says, "+1 to
the patch, and, oh, it addresses X by doing Y." I'd then switch my vote
to a full +1. I just don't see how things like that will be captured in
a mailing list that is such high traffic...

Remember the ideal is for every committer to vote, but, as the amount of
issues grows, I think it'll be harder to obtain complete coverage by
every committer of every vote in STATUS. Eventually, it'll be harder to
obtain the necessary quorum for a vote. Therefore, you need to be able
to identify who may be willing to cast full +1s.

> After all, every committer can read the STATUS file, so if they
> *didn't* agree with something, they'd have started a thread about it,
> maybe even voted -1 too.

I don't think you can keep the STATUS file in sync with the mailing list
threads. We've tried in httpd-land, and we gave up. We just found it
not to be practical. The email conversations got to be too long and
just caused people not to vote, or worse, to ignore what was said in the
mailing lists. By removing the context of the votes, I think we're
risking that same problem here. -- justin

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 28 20:57:53 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.