You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@subversion.apache.org by Benjamin Pflugmann <be...@pflugmann.de> on 2003/12/17 14:44:10 UTC

Re: svn commit: rev 8025 - in branches/0.35.0/subversion/bindings/java/javahl: . native

Hi.

On Wed 2003-12-17 at 04:13:11 -0600, josander@tigris.org wrote:
> Author: josander
> Date: Wed Dec 17 04:13:11 2003
> New Revision: 8025
> 
> Modified:
>    branches/0.35.0/subversion/bindings/java/javahl/README
[...]
> Merge r8009, r8010 and r8011 into the 0.35.0 branch

Maybe it's just me, but since there was some voting involved, I'd
expected the log to mention the fact or even maybe by whom this was
blessed.

I don't mean to say that you have to justify by voting what you decide
to put on a release, but since a voting has been done, I think some
reference would be in order.

Bye,

	Benjamin.

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

Re: Timetable for first 1.0 merge list

Posted by kf...@collab.net.

Greg Stein <gs...@lyra.org> writes:
> I'll note the issue tracker isn't as easy to say "open"; there is some
> nebulous process that Karl defined to open an issue for voting. AFAIK,
> none have been opened (since the "rules" aren't part of the issue tracker,
> it is hard to know what they are all the time; with a STATUS file, the
> rules can be "right there"). If an issue is *not* voted in, then what
> happens? How does it get "closed"? I suspect there will some monkey games
> with the milestone to suggest the various voting.

Yes, you're right, there's an unclarity here.

> Hmm. Thinking on this more, I currently see a *bunch* of issues that have
> no milestone associated with them. They're all "---" which is tough
> because it can also mean that somebody hasn't dealt with it yet. The two
> semantics are conflated. If there is a milestone named "open for voting",
> then it would be more obvious. But then we're conflating process with
> milestone...

That seems a reasonable solution.  But since we're almost done
deciding to use a STATUS file (not to put too fine a point on it, but
the voting pattern seems pretty clear so far), I won't bother to fix
this in the tracker now.

> Sigh.  /me waits with anticipation for the vote on IZ vs STATUS to close...

:-)  Soon, soon.

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

Re: Timetable for first 1.0 merge list

Posted by Greg Stein <gs...@lyra.org>.

On Sat, Dec 20, 2003 at 01:16:40PM +0100, Tobias Ringström wrote:
> kfogel@collab.net wrote:
> > Regarding dates:
> > 
> > Hmmm, yeah, you're right that a lot of people will be off line for the
> > holidays.  I shouldn't try to rush so much.  Let's say:
> > 
> > Thursday, Jan. 8th for all candidate changes listed and voting on them
> > to be complete.
> > 
> > Does that sound okay?
> 
> Yes.
> 
> Will this be the only voting period, or will there be another or 
> possibly several periods after that?  Or will each potential change be 
> handled individually after that?  I'm just trying to understand how this 
> will work.

Assuming that we use a STATUS file, then it is very easy to have a running
vote on each issue. There is no "open" or "close" announcement for an
issue to be voted on. When somebody puts it into the STATUS file, then it
is implicitly open for voting. When ample time to vote has occurred and it
is removed from STATUS, then you don't need to worry about it.

I'll note the issue tracker isn't as easy to say "open"; there is some
nebulous process that Karl defined to open an issue for voting. AFAIK,
none have been opened (since the "rules" aren't part of the issue tracker,
it is hard to know what they are all the time; with a STATUS file, the
rules can be "right there"). If an issue is *not* voted in, then what
happens? How does it get "closed"? I suspect there will some monkey games
with the milestone to suggest the various voting.

Hmm. Thinking on this more, I currently see a *bunch* of issues that have
no milestone associated with them. They're all "---" which is tough
because it can also mean that somebody hasn't dealt with it yet. The two
semantics are conflated. If there is a milestone named "open for voting",
then it would be more obvious. But then we're conflating process with
milestone...

Sigh.  /me waits with anticipation for the vote on IZ vs STATUS to close...

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

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

Re: Timetable for first 1.0 merge list was Re: what voting means, what voting doesn't mean

Posted by Tobias Ringström <to...@ringstrom.mine.nu>.

kfogel@collab.net wrote:
> Regarding dates:
> 
> Hmmm, yeah, you're right that a lot of people will be off line for the
> holidays.  I shouldn't try to rush so much.  Let's say:
> 
> Thursday, Jan. 8th for all candidate changes listed and voting on them
> to be complete.
> 
> Does that sound okay?

Yes.

Will this be the only voting period, or will there be another or 
possibly several periods after that?  Or will each potential change be 
handled individually after that?  I'm just trying to understand how this 
will work.

/Tobias

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

Re: Timetable for first 1.0 merge list was Re: what voting means, what voting doesn't mean

Posted by kf...@collab.net.

Justin Erenkrantz <ju...@erenkrantz.com> writes:
> I think a lot of people are going to be out of town or busy with the
> families the next two weeks.  So, the first week of January is
> probably the earliest I'd think is reasonable to have the initial 1.0
> issue list in place. Otherwise, we're running the risk of not having
> the 'right' people look at issues.
> 
> I'd branch now (i.e. Monday or whatever), then allow commits to
> proceed as normal to trunk.  If people think their commit should be in
> 1.0, they need to add it to the merging tracker - which we're having a
> parallel discussion on what that should be.  ;-)

Oh, the 1.0 branch comes from the 0.35 tag anyway -- trunk commits are
not any more delayed now than after 1.0-stabilization is branched.

Nevertheless, let's try to be conservative about trunk commits.  We
want to concentrate review energy on 1.0 as much as possible.  I'm not
saying we should vote on the trunk commits (heaven forbid).  Just
asking that committers hold off on new feature development and major
code changes for a while, so we can pay that much more attention to
the release.

Regarding dates:

Hmmm, yeah, you're right that a lot of people will be off line for the
holidays.  I shouldn't try to rush so much.  Let's say:

Thursday, Jan. 8th for all candidate changes listed and voting on them
to be complete.

Does that sound okay?

We shouldn't set a date for all the merges to be done, since we don't
yet know what we're merging.  But I think it'll be easier just to set
the 1.0 release date, when we see what's on our plate as of Jan. 8th.
We're going to do the merges as quickly as possible (I'm personally
committing to that, you can bet), so that the changes will be in the
line and testable for as long as possible.

-Karl

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

Timetable for first 1.0 merge list was Re: what voting means, what voting doesn't mean

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.

--On Friday, December 19, 2003 12:51 PM -0600 kfogel@collab.net wrote:

> Let's say this Monday, Dec 22, is preferred, with Jan. 1 at the
> outside.  Does that sound okay?

I think a lot of people are going to be out of town or busy with the families 
the next two weeks.  So, the first week of January is probably the earliest 
I'd think is reasonable to have the initial 1.0 issue list in place. 
Otherwise, we're running the risk of not having the 'right' people look at 
issues.

I'd branch now (i.e. Monday or whatever), then allow commits to proceed as 
normal to trunk.  If people think their commit should be in 1.0, they need to 
add it to the merging tracker - which we're having a parallel discussion on 
what that should be.  ;-)

I'd then say shoot for January 9th or so to have the next 1.0 candidate out 
with the merges.  People should have had time to get back, review the proposed 
candidates and vote on 'em, and merge 'em to the 1.0 branch.

What do you think?  Am I completely off base?  -- justin

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

Re: what voting means, what voting doesn't mean

Posted by kf...@collab.net.

mark benedetto king <mb...@lowlatency.com> writes:
> On Fri, Dec 19, 2003 at 10:58:51AM -0600, kfogel@collab.net wrote:
> > Today we begin deciding which fixes go into 1.0 and which don't (let's
> > wait until the 1.0-stabilization branch is created, though).
> 
> What should be considered a "drop-dead" date for new commits to be
> considered for 1.0?  I have two planned for this weekend.

Good question, yeah.

Let's say this Monday, Dec 22, is preferred, with Jan. 1 at the
outside.  Does that sound okay?

Of course, a serious bug can be discovered at any point, so it isn't a
hard-and-fast deadline.  However, after the voting is done and we see
roughly how much flux is anticipated in the 1.0-stabilization line,
I'll propose an actual 1.0 release date, roughly 4-6 weeks away.

Comments welcome, as always,
-Karl

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

Re: what voting means, what voting doesn't mean

Posted by mark benedetto king <mb...@lowlatency.com>.

On Fri, Dec 19, 2003 at 10:58:51AM -0600, kfogel@collab.net wrote:
> Today we begin deciding which fixes go into 1.0 and which don't (let's
> wait until the 1.0-stabilization branch is created, though).

What should be considered a "drop-dead" date for new commits to be
considered for 1.0?  I have two planned for this weekend.

--ben


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

Re: what voting means, what voting doesn't mean

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.

--On Friday, December 19, 2003 11:53 AM -0600 Ben Collins-Sussman 
<su...@collab.net> wrote:

> Hear, hear!

*stands up and cheers screaming +1 +1 +1!*

Go Karl!  ;-)  -- justin

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

Re: what voting means, what voting doesn't mean

Posted by Ben Collins-Sussman <su...@collab.net>.

On Fri, 2003-12-19 at 10:58, kfogel@collab.net wrote:

> Instead, a +1 vote should mean that:
> 
>    1. You are convinced if this is not fixed for 1.0, it will be much
>       more painful to deal with afterwards.  Various UI and/or API
>       changes probably meet this criterion, but a plain bug fix might
>       not, for example.
> 
>    2. You have personally reviewed every line of the proposed change,
>       and are willing to take equal responsibility with the original
>       author for it.  If you vote +1, your name will go in the log
>       message along with the original author's, and you should be as
>       willing to answer for any bugs that result.  If you don't have
>       the expertise to evaluate a change, then please don't vote on it
>       (you can still add a comment saying why you think it should go
>       in, and encouraging domain experts to give it consideration).

Hear, hear!

-- Ben, trying to back Karl's Wall of Conservatism against the floodtide
of potential 1.0 changes.



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

what voting means, what voting doesn't mean

Posted by kf...@collab.net.

Today we begin deciding which fixes go into 1.0 and which don't (let's
wait until the 1.0-stabilization branch is created, though).

I have a vision for how voting will work, and what the votes mean,
which I hope can give us some guidance.

First, do not vote +1 on a change just because you understand what the
issue is and would like to see it fixed for 1.0.  In other words,
*don't* just run down the list in one pass and mark everything you
like.  If we operate that way, it will simply guarantee that every
candidate issue finds at least three approvals and gets committed.

Instead, a +1 vote should mean that:

   1. You are convinced if this is not fixed for 1.0, it will be much
      more painful to deal with afterwards.  Various UI and/or API
      changes probably meet this criterion, but a plain bug fix might
      not, for example.

   2. You have personally reviewed every line of the proposed change,
      and are willing to take equal responsibility with the original
      author for it.  If you vote +1, your name will go in the log
      message along with the original author's, and you should be as
      willing to answer for any bugs that result.  If you don't have
      the expertise to evaluate a change, then please don't vote on it
      (you can still add a comment saying why you think it should go
      in, and encouraging domain experts to give it consideration).

As for the logistics:

Mention your committer name when you vote, if it's different from your
tigris.org username, and don't forget to adjust the "votes:N" field in
the issue's StatusSummary.

In addition to the vote itself, explain briefly why you have voted for
(or against) the change.  Followup discussion should happen on the dev
list, though.

If someone votes "-1", that's a veto, and it means the change doesn't
go in without at least some more discussion on the dev list.
Eventually, a straight vote can break a veto, but that should be a
separate process undertaken consciously.

We don't want to descend into a veto war, naturally (I'm hoping to get
all the way through it without any vetos).  But to achieve that also
requires a certain amount of conservativism from everyone in making
positive votes.  For example, take time to consider carefully whether
there's any way to achieve the desired API change after 1.0 without
breaking compatibility -- often there is.

By the way, I think it's best to have one person merging the changes,
since it's easier for one brain to keep track of potential conflicts
and do things in a sane order.  I'm guessing the voting process will
take a week or so.  When the final issue list is settled, I volunteer
to be Mr. Merge (I'm not traveling for the holidays anyway, so that'll
be a good time to take care of this, with not much else going on).

Following this mail, I'll make some separate posts about certain
individual issues and why I think they don't need to be solved for
1.0.

Thanks,
-Karl

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