Justin Erenkrantz <justin@erenkrantz.com> writes:
> 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.
If someone commits a veto, but doesn't provide a justification, won't
we notice it? What I'm worried about is that an in-place explanation
would then becomes a starting point for discussion in the file.
> 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.
The justification line was not my idea originally, if you remember,
though I certainly agreed to it. (I'm fine discussing our options
here, but would like to avoid the implication that I came up with this
stuff *entirely* unilaterally, thank you! :-) ).
> 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.
That seems a reasonable balance to me (though some of those notes
really did go beyond this).
How do other people feel?
> 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.
I meant the log message of the change itself, not the vote. (To
approve a change, one must read its log message, though one needn't
know who has previously voted for it.)
> 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.
And how is that useful, in terms of making an ultimate decision about
the change?
(By the way, I thought the concept +1 did *not* indicate that the
person had reviewed the change!)
> 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.
Uh, okay. How is it harmful, exactly?
I still don't see how it helps us to have these halfway +1's. We want
people taking full responsibility for a change, not confusing the
issue with noncommittal approvals, I think. The goal is to be very
confident about our eventual decisions. Real +1's contribute to that
goal. +0, and concept +1's, do not IMHO.
> 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...
This is *exactly* what I am objecting to.
If you're not sure, then ask on the list "Does it address X?". Why
would you need to vote before knowing the answer?
What does the traffic load have to do with it? Are you saying that
it's impractical to post about libsvn_fs and expect an answer from
CMike, and that therefore one needs the STATUS file to become a
realtime communications medium too? Then the STATUS file will become
high-traffic, and CMike will be just as likely to miss it there as on
the list.
But in fact, people follow the list just fine, and posts do get
answered. You're claiming the mailing list is not useful, it seems,
and yet this does not match my experience. A well-crafted subject
line will get seen by the people who need to see it every time.
> Remember the ideal is for every committer to vote,
No. Why do you say that?
> 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.
Then ask them to review the change.
Every committer reads every subject line on the dev list, or if they
don't, then they're probably not reading every commit to the STATUS
file either (especially not if it starts getting a lot of commits).
Use email for realtime communications, that's what it's for. The
STATUS file is for recording a cumulative state.
> 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
If the conversations are too long, how does moving them to the STATUS
file help? They'll be just as long there.
I'm okay with putting some basic context in the STATUS file, but I
have a feeling you want much more than that, and I think it's likely
to get out of date w.r.t. what's being said on the mailing list. I'm
very uncomfortable duplicating in a file the high points of a realtime
list discussion, when any of those points might get contradicted or
expanded later without that update being reflected in the file.
Better to just point to the thread in the first place.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 28 21:43:37 2003