On Sun, Dec 28, 2003 at 01:51:50PM -0600, kfogel@collab.net wrote:
> 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.
No, because that person could cast a -1, walk off for a few days, and
the rest of us are stuck wondering why there's a -1. During that time,
everything is at a standstill regarding the patch. All I'm saying is
that if you cast a -1, you need to leave behind a 'one-line' explanation
of why you are casting a -1. I'd hope that's a reasonable request.
> 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! :-) ).
Sorry for any misunderstanding here, then.
> > 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).
Perhaps the ones I did initially don't fit that mold (as I wasn't aware
that there was an explicit objection to discussion in STATUS), but I
hope we're all trying to figure out what the right thing is here. ;-)
> > 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.)
I think there's some crossed wires here, but I understood that you
suggested that any commentary regarding a vote must be in the log of the
commit of the vote not in the STATUS file itself. So, I'm not clear
what your context is here. Or, do you perhaps mean to modify the log
message of the merge candidate with any discussion? (I don't like
changing log history except for typos since they aren't versioned.)
> 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!)
Yes, I meant that they had reviewed it; but they aren't willing to write
it off completely as a +1 without some minor points straightened out
first. That is, they conceptually agree with *how* the patch is
implemented, but there's either something unclear about the patch or
they haven't tested it throughly, or something like that.
> 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.
They don't count towards quorum, but they can be used to identify who's
looked at the patch, reviewed it, and said, "Yeah, I think it's right,
but X needs to be done first." When you need 3 +1s, it's really good if
some people say, "Yeah, I think it's right"; then, later on, when it's
time to merge, that person can be prompted to cast a full +1 if you
don't have the required votes.
Let me summarize what I see the votes meaning:
+1: I agree completely, I think this patch should go in
+0: I don't like this patch, but we need it. *hold nose*
-0: We shouldn't accept this, but I won't stand in anyone's way
-1: No way should we accept this patch *ever*
So, the +1 (concept), as I see it is more of a "Yeah, this patch sounds
right; but I need more time to review." Perhaps enough +1s will be
received before the issues are resolved, but perhaps not. You could
conceivably change the +0 definition to be identical to the 'concept'
vote, but I think there's a slight emotional difference between +1
(concept) and +0. But, if you reject '+1 (concept)', then I'll just ask
that we define +0 as my '+1 (concept).' ;-)
> If you're not sure, then ask on the list "Does it address X?". Why
> would you need to vote before knowing the answer?
Because you want to signify that you've reviewed the patch and are
generally okay with it. You can be persuaded to cast a full +1.
In my httpd experience, people casting +0s can *not* be persuaded to
cast +1s.
> 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.
No, because STATUS file isn't like that.
I guess there's a difference in httpd from Subversion which is probably
due to the difference in life cycles. In httpd-land, we expect that
people may not read the mailing list for periods of time. Therefore,
messages aren't always expected to be answered in a 'timely' manner.
So, leaving notes in the STATUS file is a way of ensuring that the
questions don't get lost. Posting to a list is a sure-fire way of
getting your question lost or forgotten.
Increasingly, I've seen a number of posts and questions on dev@svn that
haven't been answered in a 'timely' manner. No, it's not a huge problem
yet, but perhaps it'll be at some point so messages from 'good' people
do get dropped too. To prevent these concerns from being dropped (and
later merged over objections that we never answered), I'd rather see
them stored in the STATUS file.
> > Remember the ideal is for every committer to vote,
>
> No. Why do you say that?
Well, it *should* be our ideal. We shouldn't have committers who aren't
paying attention. But, practically, it'll never happen...
> 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.
Rather than continue this debate (I think we could go back and forth
forever), let me propose a few simple modifications to what we have
that would address my concerns:
1) All vetoes should have a recorded justification in STATUS.
(See above for rationale)
2) All mailing list threads should *also* include a Message-ID of the
first message.
(URLs to a third-party archiver are not useful when off-line)
3) If the thread is about a sub-point of the merge candidate, an at-most
one-line description/summary should be provided in STATUS saying what
the thread is about; if there was a conclusion, that can be said here.
(There can be multiple threads/merge candidate)
4) To balance the 'Justification' line, there should be one 'Concerns'
line that allows people casting non-+1 votes to say why they did not
vote +1.
(I'd prefer one line/committer.)
What do you think? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 29 07:43:06 2003