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

[Greg Hudson <gh...@MIT.EDU>]

On Sat, 2003-12-27 at 10:52, rooneg@tigris.org wrote:
> +     Notes:
> +      rooneg: This is worth it just so diffing between the branch and the 
> +              trunk doesn't show differences for every damn file ;-)

>        jerenkrantz: For 1.0, we'll state that svn_client_ctx_t can only add
>                     members, correct?  So, I'm not sure that adding the
>                     constructor buys us a lot - it's not opaque.  *shrug*
> +      rooneg: Yeah, it doesn't force people to 'do the right thing', but it 
> +              makes it possible for them to do so, and since 'the right thing' 
> +              is clearly documented I think that's enough.  Plus, to make it 
> +              100% bulletproof we'd need accessor functions and an opaque 
> +              structure, and people didn't like that when I originally did it 
> +              that way.

From HACKING:

  The STATUS file is not the place for discussion; use the dev mailing
  list for that, and have the file point to the thread.

So, a "Notes" entry is something you feel compelled to attach your name
to, because other people might not agree with it, then it doesn't belong
there.  Send mail to the dev list and include the URL of the mail thread
instead.

(I agree with HACKING on this point, because non-committers can't
participate in a discussion in the STATUS file.  Also, the STATUS file
would grow too big.)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Justin Erenkrantz <ju...@erenkrantz.com>]

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

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

[kf...@collab.net]

Justin Erenkrantz <ju...@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

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

[Justin Erenkrantz <ju...@erenkrantz.com>]

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

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

[kf...@collab.net]

Greg Hudson <gh...@MIT.EDU> writes:
> >From HACKING:
> 
>   The STATUS file is not the place for discussion; use the dev mailing
>   list for that, and have the file point to the thread.
> 
> So, a "Notes" entry is something you feel compelled to attach your name
> to, because other people might not agree with it, then it doesn't belong
> there.  Send mail to the dev list and include the URL of the mail thread
> instead.

What Greg said.  (I did put "Notes" fields on some items, but only to
explain why the change is not to be found on trunk, explain where the
patch is, or to give a bit of history that will help a reader
understand the context behind the change.)

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.

Regarding Justin's note on r8021: I just moved it into the
"Justification" line, so that probably doesn't need any further
followup.  It now reads:

  * r8021
     'svn revert' performance improvement (timestamp sleep once, not N times)
     Justification: trivial; API change; makes error returns correct priority
     Votes:
      +1: jerenkrantz, rooneg

Regarding the "concept" votes:

I'd like to remove them too, but have left them in while we discuss
it.  Here's why I think they're not much help:

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).

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.

It's much better to keep the STATUS file reduced to bare essentials,
with links to further discussion.  That way it's easy to browse.  And
people should be following the links -- because no one should be
making their decision about a change based just on the information in
the STATUS file anyway, right?

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org