You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2003/12/15 17:47:21 UTC
process for including changes in 1.0
We now have a number of changes proposed for 1.0 -- mostly API stuff,
but I'm sure there will be bugfixes too. We need a process for
deciding which ones get included. Below is a proposed patch to
HACKING about this. Any objections if I commit this?
Its main goals are:
* To gather all the proposed changes in one place, so we can easily
compare them with each other, and get a sense of how much total
destabilization we're looking at. It would be impossible to make
good decisions without such an overview.
* To provide a canonical place to record votes, so we don't have to
comb mailing list threads.
* To clearly separate the question of "Should this get fixed on
trunk?" from "Should the fix go into 1.0?". We'll be answering
the first question "Yes" much more often than the second.
Btw, this is unrelated to the version numbering discussion going on in
another thread. Sorry to have two process threads running at once,
but we need to figure this stuff out now so we won't have to go
through it all again in the future :-).
Also, note that we're creating the "1.0-stabilization" branch on
Friday, from the 0.35.0 tag. Thus, changes made on trunk since r7994
will *not* be in 1.0 unless merged to its branch -- after going
through the process below, or whatever process we come up with, of
course. I've mentioned that before, but wasn't sure whether everyone
heard it :-).
-Karl
Index: HACKING
===================================================================
--- HACKING (revision 8002)
+++ HACKING (working copy)
@@ -36,6 +36,7 @@
* How to release a distribution tarball
* Release numbering
* Compatibility
+ * Stabilizing a release branch
Participating in the community
@@ -1417,3 +1418,57 @@
This mechanism is a last resort, to be used when capability
keywords would be too hard to manage.
+
+
+Stabilizing a release branch
+============================
+
+[For clarity, this section is written specifically for the 1.0
+release. The same principles apply to future releases; it may be
+appropriate to generalize this section after 1.0 is out.]
+
+First, we create a "1.0-stabilization" branch based on the last
+interim release:
+
+ $ svn cp http://svn.collab.net/repos/svn/tags/0.35.0 \
+ http://svn.collab.net/repos/svn/branches/1.0-stabilization
+
+Trunk development can continue normally, since changes on trunk do not
+affect the 1.0 release unless explicitly merged in. However, we try
+to avoid major new initiatives on trunk while we're stabilizing 1.0.
+As developers must still review trunk commits, the more we can reduce
+that distraction, the more attention we can devote to the release
+line.
+
+Certain trunk changes are desirable: those that are meant to be merged
+into the 1.0-stabilization branch. The preferred way to get a change
+into the release is to make the change on trunk, then port it over.
+This is partly to ensure that the change will be in future Subversions
+as well as in the upcoming release; but also, it gives the developers
+something concrete to vote on for inclusion in the release line.
+
+A change needs three +1 votes and no vetoes from full committers to go
+into the 1.0-stablization branch. We use the STATUS file in the top
+level of the release branch for recording votes. Each item is a short
+identifying string (a revision number, an issue number, etc), a brief
+description of the change, followed by the votes. For example:
+
+ * r98765
+ Make the svn_read_user_mind() function accept NULL input.
+ See mailing list thread http://...
+
+ Votes for merging into 1.0:
+ +1 ghudson
+ +1 bliss
+
+We don't use the issue tracker for the voting, because the question of
+whether something should be fixed is separate from the question of
+whether the fix should go into 1.0. Issues are about recording the
+existence of the bug, feature request, whatever, and getting the
+change into the main development line of Subversion. The STATUS file
+is only about whether that particular change should go into the
+release -- which is why the STATUS file for a release lives on its
+branch, not on the trunk.
+
+The STATUS file is not the place for discussion; use the dev mailing
+list for that, and have the STATUS file point to the thread, instead.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> I would suggest including an at-most-one-line justification for why this
> should go into 1.0. ("Critical bug-fix", "API change", "Fixes privacy
> violation", etc.)
That's a good idea, will add that.
> Otherwise, this looks fine.
Cool.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2003-12-15 at 12:47, kfogel@collab.net wrote:
> +A change needs three +1 votes and no vetoes from full committers to go
> +into the 1.0-stablization branch. We use the STATUS file in the top
> +level of the release branch for recording votes. Each item is a short
> +identifying string (a revision number, an issue number, etc), a brief
> +description of the change, followed by the votes. For example:
> +
> + * r98765
> + Make the svn_read_user_mind() function accept NULL input.
> + See mailing list thread http://...
> +
> + Votes for merging into 1.0:
> + +1 ghudson
> + +1 bliss
I would suggest including an at-most-one-line justification for why this
should go into 1.0. ("Critical bug-fix", "API change", "Fixes privacy
violation", etc.)
Otherwise, this looks fine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Saturday, December 20, 2003 10:58 AM -0800 Ben Reser <be...@reser.org>
wrote:
> Does that mean 3 votes from any committer and no vetoes from full
> commiters? Or 3 votes from full committers and no vetoes from full
> committers?
If the work overlaps into a region where a committer has 'privs', then their
vote is binding and counts towards the quorum (or is a veto).
Say we had a developer who only had commit to libsvn_ra, would their vote be
binding to libsvn_wc? Unlikely, but they can still vote though.
Full committers are just that: their votes are binding everywhere. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Ben Reser <be...@reser.org>.
On Mon, Dec 15, 2003 at 11:47:21AM -0600, kfogel@collab.net wrote:
> +A change needs three +1 votes and no vetoes from full committers to go
> +into the 1.0-stablization branch.
Clarification request:
Does that mean 3 votes from any committer and no vetoes from full
commiters? Or 3 votes from full committers and no vetoes from full
committers?
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Erik Huelsmann <e....@gmx.net>.
> > +A change needs three +1 votes and no vetoes from full committers to go
> > +into the 1.0-stablization branch. We use the STATUS file in the top
>
> It would be nice to include an exception for harmless obviously correct
> fixes such as spelling fixes and most documentation fixes.
>
> It feels a bit strange to revision control the voting. How about
> creating an issue for each thing we want to include in the branch, just
> for the purpose of voting? Each issue would be named something like
> "merge rXXXX to branch-1.0", i.e. it would not be an issue that
> describes a bug. The committers would then vote by adding comments to
> the issue, and the issue can either be resolved or dismissed when the
> voting is complete.
+1.
It feels strange to use a file in the repository for voting. Using the issue
tracker to track the voting for a certain merge operation feels much better.
bye,
Erik.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> If we're going to be using Subversion as a makeshift issue tracker
> because of this requirement, we could consider setting up a separate
> repository for it. Then you wouldn't have to ask Jostein for permission
> to tinker with his 0.35 branch. :)
Oh, I'm not going to ask him for permission every time, just this
first time :-).
> But, just an idea. I don't relish the idea of filling up the Subversion
> commit logs with votes, but it wouldn't be the end of the world.
Oh, I don't think it's going to be so bad.
Remember, if you run 'svn log' on trunk, you won't see these. And
people can batch up their votes and enter them in one commit, where
possible. I think the advantages of having the file right there in
the relevant release branch outweighs the extra revisions.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2003-12-15 at 15:54, kfogel@collab.net wrote:
> As someone who's going to be spending a good part of the next few
> weeks deeply immersed in the list of 1.0 candidate changes, I am
> pretty sure I'll go crazy if that list is not in a text file :-). (I
> don't mean to suggest that no one else will spend comparable time
> immersed in the list, by the way... But I'll bet that those who do
> will be thankful it's a text file too, in the end).
If we're going to be using Subversion as a makeshift issue tracker
because of this requirement, we could consider setting up a separate
repository for it. Then you wouldn't have to ask Jostein for permission
to tinker with his 0.35 branch. :)
But, just an idea. I don't relish the idea of filling up the Subversion
commit logs with votes, but it wouldn't be the end of the world.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Erik Huelsmann <e....@gmx.net>.
> > I think most developers have a query set up for this already; if not,
> > http://subversion.tigris.org/project_tasks.html has a link.
>
> Do I have to have the developer role to design and save my own queries? I
> tried finding that function, but I couldn't. I am currently only Observer
> at
> Tigris.
Never mind... I wasn't logged in.
bye,
Erik.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Erik Huelsmann <e....@gmx.net>.
> > My real concern with the issue tracker is that there will be no
> > centralized location to know what to vote on. A specialized query
> > page? That'd require me to bookmark a special page. That won't
> > work for me as I'm constantly hopping between machines. All I have
> > centralized access to is my email. Almost every box does have a SVN
> > install on it, so I can checkout WCs. ;-) -- justin
>
> Just query for the "---" milestone.
>
> I think most developers have a query set up for this already; if not,
> http://subversion.tigris.org/project_tasks.html has a link.
Do I have to have the developer role to design and save my own queries? I
tried finding that function, but I couldn't. I am currently only Observer at
Tigris.
bye,
Erik.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by kf...@collab.net.
> My real concern with the issue tracker is that there will be no
> centralized location to know what to vote on. A specialized query
> page? That'd require me to bookmark a special page. That won't
> work for me as I'm constantly hopping between machines. All I have
> centralized access to is my email. Almost every box does have a SVN
> install on it, so I can checkout WCs. ;-) -- justin
Just query for the "---" milestone.
I think most developers have a query set up for this already; if not,
http://subversion.tigris.org/project_tasks.html has a link.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Ben Reser <be...@reser.org>.
On Mon, Dec 15, 2003 at 11:32:29PM -0800, Justin Erenkrantz wrote:
> My real concern with the issue tracker is that there will be no centralized
> location to know what to vote on. A specialized query page? That'd
> require me to bookmark a special page. That won't work for me as I'm
> constantly hopping between machines. All I have centralized access to is
> my email. Almost every box does have a SVN install on it, so I can checkout
> WCs. ;-) -- justin
The URL could always be added to the HACKING page.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, December 15, 2003 6:18 PM -0500 John Szakmeister
<jo...@szakmeister.net> wrote:
> It does... I think most developer's think it's a little too cumbersome to
> use, so we don't.
*ditto*
If I have to use a web page to cast votes, don't expect me to cast any votes.
If it's in a text file that I can check out and look at what is pending at a
glance, I'd be willing to cast votes - time permitting (of course).
My real concern with the issue tracker is that there will be no centralized
location to know what to vote on. A specialized query page? That'd require
me to bookmark a special page. That won't work for me as I'm constantly
hopping between machines. All I have centralized access to is my email.
Almost every box does have a SVN install on it, so I can checkout WCs. ;-)
-- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by John Szakmeister <jo...@szakmeister.net>.
On Monday 15 December 2003 18:02, Ben Reser wrote:
> [snip]
> Maybe the issue tracker should have some sort of voting system added to
> it? Obviously doesn't help us now. Mandrake added such a thing for
> its bugzilla and it's pretty handy.
It does... I think most developer's think it's a little too cumbersome to use,
so we don't.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Sander Striker <st...@apache.org>.
On Fri, 2003-12-19 at 19:10, Greg Hudson wrote:
> On Fri, 2003-12-19 at 11:59, Jani Averbach wrote:
> > I have found it really convience to look out the status of pending things
> > from STATUS of apr/apr-util/httpd. And I think it is quite nice to
> > have all of the issues in one file, where you can easily glance at
> > them, in one place.
> >
> > So I am
> > +1 for svn/1.0/STATUS
> > +0.5 for issue tracker
> > -1 for STATUS in separeted repository
>
> Please don't send vetos without justification.
Since this is a non-technical issue, vetos don't apply. As such, this
-1 is just a dislike for this option.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2003-12-19 at 11:59, Jani Averbach wrote:
> I have found it really convience to look out the status of pending things
> from STATUS of apr/apr-util/httpd. And I think it is quite nice to
> have all of the issues in one file, where you can easily glance at
> them, in one place.
>
> So I am
> +1 for svn/1.0/STATUS
> +0.5 for issue tracker
> -1 for STATUS in separeted repository
Please don't send vetos without justification.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2003-12-19 16:29+0000, Julian Foad wrote:
>
> -1 on committing votes into a "STATUS" file in our main source repository.
> I hate the thought of, between the source changes, a load of commits like
> this:
And I like it. =)
I have found it really convience to look out the status of pending things
from STATUS of apr/apr-util/httpd. And I think it is quite nice to
have all of the issues in one file, where you can easily glance at
them, in one place.
So I am
+1 for svn/1.0/STATUS
+0.5 for issue tracker
-1 for STATUS in separeted repository
Just for grain of salt for your statistical sample.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, December 19, 2003 1:29 PM -0800 Ben Reser <be...@reser.org>
wrote:
> Sounds like what you want is an email interface to the issue tracker.
That would not solve the 'bulk' updates problem. How do I easily know when
I'm off-line what the pending changes are? If I have a copy of the WC with
the STATUS file in it listing the changes, then I'm set. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Ben Reser <be...@reser.org>.
On Fri, Dec 19, 2003 at 11:43:17AM -0800, Justin Erenkrantz wrote:
> I'm more unlikely to use the web tracker for the reasons described above.
> A pull-based tool isn't right for us. We want push-based tools. ;-)
Sounds like what you want is an email interface to the issue tracker.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by kf...@collab.net.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> I'm more unlikely to use the web tracker for the reasons described
> above. A pull-based tool isn't right for us. We want push-based
> tools. ;-)
>
> Hope this better explains my rationale. -- justin
Thanks, yeah, it's a good summary.
Of course, if you win the vote, I'll have to pull a military coup and
declare myself dictator for life. But that's okay -- I'll be a *good*
dictator, don't worry.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, December 19, 2003 12:11 PM -0600 kfogel@collab.net wrote:
> Now I'm asking you to at least try it out. I personally have not
> found it that inconvenient yet, though that could just be me.
Using a web-based tool doesn't work well for me. I'm a slave to email.
But, let me summarize my concerns that are implicit in that statement:
I don't believe every committer follows issues@, so there could be a vote that
'misses' developers. So, if changes in votes are sent to our commit list,
then all developers can easily know when votes are casted. We could just
mandate that all committers must follow issues@ to know when votes are being
casted, but I'm not a fan of asking that.
The format of the issue tracker isn't particularly conducive to recording the
votes. Let me explain here: the way I'd see the typical life cycle go is:
1) Issue opened by user
2) Discussion occurs about what the bug is and the 'right' fix
3) Issue fixed by developer in trunk
4) Developer 'resolves' bug in tracker
5) Developer proposes issue should be merged to 1.0 by adding a vote
6) Other developers start casting votes
7) Enough developers cast +1s and no -1s casted
8) Issue merged to 1.0 by someone
9) Issue 'closed'
My concern is that 5 & 6 done in IZ aren't going to send an email to
committers when that happens - except to issues@. But, even if we all follow
issues@, it's not enough - we have to search through all commits to see when a
vote has been opened. Another way to resolve this would be to setup a
'special' IZ instance/CC list just for merging. But, that could be a bit
unwieldy.
It's hard to do bulk updates or off-line updates with the web-based tool. I,
for one, would be likely to review changes en masse while I'm traveling. With
a STATUS file, I'll have the rev number to merge listed in the STATUS file,
and I'd also have the commit emails for that rev number. So, I can do all of
my analysis (and see any commentary relevant to only the votes) just by
looking at my latest WC and mail archives. I can test it and then cast the +1
or -1 such as it'll be.
I can then record my vote in STATUS (and comments I have on the issue), then
perform a commit when I get back on the network. If there's a conflict (i.e.
someone else voted), I'll see that and take any additional input into
consideration before committing back to the trunk.
The potential drawback of having the STATUS file is that we're increasing the
barrier to entry here and we could be creating disjoint commentary (initially
on IZ, then in STATUS). Yet, I think that's acceptable because one of the
reasons that we want votes is that we want to ensure that the committers
themselves are 'happy' with a change and are willing to back it. There might
also be commentary in an issue that'd be relevant, but you don't have handy.
So, for that, it might be useful to have an issues@ archive that you can
browse off-line. (Since you know the IZ number, you can just look at that
issue in your mailbox. So, the information overload isn't as great. You know
how to find the needle in the haystack!)
> I must have missed that. So, if we don't use a STATUS file, you're
> just not going to participate in the process? And this is unconnected
I'm more unlikely to use the web tracker for the reasons described above. A
pull-based tool isn't right for us. We want push-based tools. ;-)
Hope this better explains my rationale. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by kf...@collab.net.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> You didn't even allow 24 hours after asking what to use before
> deciding on the issue tracker. IMHO, that's not enough time to say
> that everyone is on board and then claiming that anyone who chimes in
> is only reactive. Sorry.
That's fair (though I have been very careful *not* to claim that
"everyone is on board"!).
But consider: we really needed to start gathering those issue right
away. There wer a lot of them popping up, and they needed to be
organized. So rather than delay, I made a call, and emphasized that
it didn't have to be permanent, that it was just so we could start
getting this stuff organized.
At the time 1.0 candidate issues started popping up like dandelions,
there was no clear preference for file vs tracker, but there was
somewhat more lean toward tracker. I defended the file for a while,
then said, "What the heck, I don't have any direct experience with
either way, so let's just go with the tracker and see."
Now I'm asking you to at least try it out. I personally have not
found it that inconvenient yet, though that could just be me.
> And, many people (including myself) have said that we're not going to
> use the issue tracker. I think it's the wrong tool for the job. --
I must have missed that. So, if we don't use a STATUS file, you're
just not going to participate in the process? And this is unconnected
to whether a formal vote (not yet taken) chooses the STATUS file or
the issue tracker, because you simply think the tracker is the wrong
tool?
I guess I'm asking you not take such a hard line about it. Either:
1) Give the issue tracker a try, and see if you can work with it.
I'll happily be the one transfer all the information to a STATUS
file if we decide to do that.
2) Issue a formal call for votes on which way to go, where you take
ownership of organizing the ballot and counting the votes.
But don't make blanket statements about how you won't participate in
the 1.0 process unless we use the tools you're accustomed to (if
that's not what you meant, then sorry, and please clarify). I've
compromised on many process issues in this project, as I'm sure you
have. It's not really *that* painful, is it? :-)
Don't complain, organize! :-)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, December 19, 2003 11:41 AM -0600 kfogel@collab.net wrote:
> votes. Nor did all the posts in favor of a STATUS file even arrive
> before people had already started using the tracker -- many of those
> posts were reactive.
You didn't even allow 24 hours after asking what to use before deciding on the
issue tracker. IMHO, that's not enough time to say that everyone is on board
and then claiming that anyone who chimes in is only reactive. Sorry.
> means continue. I'd prefer if you actually tried the issue tracker
> way for a while, and then decided if you couldn't stand it, though.
And, many people (including myself) have said that we're not going to use the
issue tracker. I think it's the wrong tool for the job. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by kf...@collab.net.
Greg Stein <gs...@lyra.org> writes:
> The STATUS file presents a nice summary; hella better than trying to
> formulate some weirdo IZ query. It also presents the voting much better,
> since you can actually list people's names for each +1, rather than doing
> some funky running tally which totally loses history.
>
> And yah... I'm not sure why Karl is so hell-bent on the issue tracker when
> the voting seems to point towards a STATUS file.
You guys done painting the bikeshed yet? :-)
If you read the whole thread, there is no clear mandate for either
STATUS file or issue tracker. Nor was there ever a formal call for
votes. Nor did all the posts in favor of a STATUS file even arrive
before people had already started using the tracker -- many of those
posts were reactive.
I'm not "hell-bent" on the tracker. As I clearly said more than once,
I went with the issue tracker because I *wasn't sure* which way was
better, and it seemed like a good idea to try the tracker first, then
change if we didn't like it, since it required no new infrastructure.
That's your idea of "hell-bent"? :)
So far, the tracker seems to be working out okay. People haven't
really complained about the actual experience of using it very much,
though there have been some complaints from people who prefer a STATUS
file based on past experience doing things the file way.
"loses history"? Pure FUD. The issue descriptions preserve that
history, they just make it one more click to find out who voted +1.
The history is all there. "weirdo IZ query"? It's a very simple IZ
query, and there's a useful link from the project_tasks.html page too.
If you really think this thread is constructive at this time, by all
means continue. I'd prefer if you actually tried the issue tracker
way for a while, and then decided if you couldn't stand it, though.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 19, 2003 at 04:29:54PM +0000, Julian Foad wrote:
>...
> -1 on committing votes into a "STATUS" file in our main source repository. I hate the thought of, between the source changes, a load of commits like this:
>
> r10000: julianfoad: Voted for issue 9999.
> ...
What's wrong with that? The revision numbers don't mean anything. So what
if we burn through a bunch of them?
The STATUS file presents a nice summary; hella better than trying to
formulate some weirdo IZ query. It also presents the voting much better,
since you can actually list people's names for each +1, rather than doing
some funky running tally which totally loses history.
And yah... I'm not sure why Karl is so hell-bent on the issue tracker when
the voting seems to point towards a STATUS file.
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: process for including changes in 1.0
Posted by Julian Foad <ju...@btopenworld.com>.
Justin Erenkrantz wrote:
> --On Tuesday, December 16, 2003 11:50 PM +0100 Sander Striker
> <st...@apache.org> wrote:
>
>> On Tue, 2003-12-16 at 11:08, Greg Stein wrote:
>>
>>> +1 on the STATUS file.
>>
>> +1
>
> As I already said, +1.
>
> So, I count at least 4 +1s for STATUS.
>
> *looks around*
>
> I count at least 2 (Tobias and Erik) for using the issue tracker.
-1 on committing votes into a "STATUS" file in our main source repository. I hate the thought of, between the source changes, a load of commits like this:
r10000: julianfoad: Voted for issue 9999.
...
r10003: johndoe: Voted for issue 7777.
...
r10009: johndoe: After list discussion, retracted my vote for issue 7777.
...
r10023: julianfoad: Voted for issue 7777 and 7778.
...
+0.5 on using a "STATUS" file in another repository. We could still check it out to a convenient place near the root of our Subversion working copy, so that it is easy to access the file and commit and update it.
+0.5 on using the issue tracker. After all, that's what it is designed for, even if its voting system doesn't exactly match what we are proposing.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by kf...@collab.net.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> As I already said, +1.
>
> So, I count at least 4 +1s for STATUS.
>
> *looks around*
>
> I count at least 2 (Tobias and Erik) for using the issue tracker.
>
> Could be missing a few though either way.
You forgot me. I was +1 on both :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, December 16, 2003 11:50 PM +0100 Sander Striker
<st...@apache.org> wrote:
> On Tue, 2003-12-16 at 11:08, Greg Stein wrote:
>> +1 on the STATUS file.
>
> +1
As I already said, +1.
So, I count at least 4 +1s for STATUS.
*looks around*
I count at least 2 (Tobias and Erik) for using the issue tracker.
Could be missing a few though either way.
> Gee, who didn't see that coming?
Us sticks-in-mud gotta 'stick' together. ;-) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Sander Striker <st...@apache.org>.
On Tue, 2003-12-16 at 11:08, Greg Stein wrote:
> +1 on the STATUS file.
+1
Gee, who didn't see that coming?
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by "C. Michael Pilato" <cm...@collab.net>.
kfogel@collab.net writes:
> Heh. Okay, it's official -- there is just no way to tell which way
> (issue tracker vs STATUS file) most developers prefer without a formal
> poll. :-)
>
> Anyone who wants to conduct such a poll is welcome to. I'm content to
> try the issue tracker way and see if it hurts.
I would run such a poll, but I can't decide if I should do it with a
file in the source tree or with an issue tracker issue. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by kf...@collab.net.
Heh. Okay, it's official -- there is just no way to tell which way
(issue tracker vs STATUS file) most developers prefer without a formal
poll. :-)
Anyone who wants to conduct such a poll is welcome to. I'm content to
try the issue tracker way and see if it hurts.
-Karl
Greg Stein <gs...@lyra.org> writes:
> +1 on the STATUS file. Much easier to provide a short summary, to see
> *who* voted *which* way, and it is versioned. I can open the file, zip
> through and add a dozen votes, commit, and be done. Changing a dozen
> issues is *significantly* harder. (IZ isn't all that hard, but compared to
> a file edit?)
>
> Most developers are signed up for commit email, but a relative few are
> signed up on the issues@ mailing list. From an awareness standpoint, the
> file is better. Especially for people who are lurking/observing.
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Dec 15, 2003 at 07:09:45PM -0500, Garrett Rooney wrote:
> On Dec 15, 2003, at 5:28 PM, kfogel@collab.net wrote:
>...
> > Well, what the heck. It seems most people prefer the issue-based
> > solution, or are at least okay with it; I'm the one being picky here.
> > Let's try using the issue tracker and see if it works. If it's too
> > painful to be borne, we'll notice pretty quickly.
>
> For the record, I prefer a STATUS file, I think it's hugely easier to
> use than the issue tracker for this kind of thing.
+1 on the STATUS file. Much easier to provide a short summary, to see
*who* voted *which* way, and it is versioned. I can open the file, zip
through and add a dozen votes, commit, and be done. Changing a dozen
issues is *significantly* harder. (IZ isn't all that hard, but compared to
a file edit?)
Most developers are signed up for commit email, but a relative few are
signed up on the issues@ mailing list. From an awareness standpoint, the
file is better. Especially for people who are lurking/observing.
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: process for including changes in 1.0
Posted by kf...@collab.net.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> For the record, I prefer a STATUS file, I think it's hugely easier to
> use than the issue tracker for this kind of thing.
:-)
Yup, I knew it wasn't unanimous either way. (Heck, I disagreed even
with myself.) The thing that swung it for me was the realization that
a) This doesn't have to be a permanent decision, we're free to
change if it doesn't work, and
b) Since we can change, we should first try the solution that
doesn't require the creation of a new object (the STATUS file)
Let's see what happens. The information being recorded is the same
either way, it's not like we could lose ground at any point.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Dec 15, 2003, at 5:28 PM, kfogel@collab.net wrote:
> Ben Reser <be...@reser.org> writes:
>> Maybe the issue tracker should have some sort of voting system added
>> to
>> it? Obviously doesn't help us now. Mandrake added such a thing for
>> its bugzilla and it's pretty handy.
>
> Funny you should mention that. I'm sitting here looking at my issues
> summary, and realizing that the Status field is actually not a bad
> place for this. We've only used it for effort estimates up till now,
> but it could hold vote totals.
>
> Everything else about an issue summary is perfect for the task: we've
> got the P number, the milestone ("1.0" in this case, with option to
> move to "1.2" or "Post-1.0" if the votes don't reach the threshold).
> Maybe I'm wrong, and this isn't so much less convenient than a text
> file.
>
> Well, what the heck. It seems most people prefer the issue-based
> solution, or are at least okay with it; I'm the one being picky here.
> Let's try using the issue tracker and see if it works. If it's too
> painful to be borne, we'll notice pretty quickly.
For the record, I prefer a STATUS file, I think it's hugely easier to
use than the issue tracker for this kind of thing.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by kf...@collab.net.
Ben Reser <be...@reser.org> writes:
> Maybe the issue tracker should have some sort of voting system added to
> it? Obviously doesn't help us now. Mandrake added such a thing for
> its bugzilla and it's pretty handy.
Funny you should mention that. I'm sitting here looking at my issues
summary, and realizing that the Status field is actually not a bad
place for this. We've only used it for effort estimates up till now,
but it could hold vote totals.
Everything else about an issue summary is perfect for the task: we've
got the P number, the milestone ("1.0" in this case, with option to
move to "1.2" or "Post-1.0" if the votes don't reach the threshold).
Maybe I'm wrong, and this isn't so much less convenient than a text
file.
Well, what the heck. It seems most people prefer the issue-based
solution, or are at least okay with it; I'm the one being picky here.
Let's try using the issue tracker and see if it works. If it's too
painful to be borne, we'll notice pretty quickly.
I'll update HACKING.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Ben Reser <be...@reser.org>.
On Mon, Dec 15, 2003 at 02:54:37PM -0600, kfogel@collab.net wrote:
> The issue tracker is very nice for tracking each individual issue, and
> for roughly comparing sets of issues by summary. It's not very good
> for browsing a particular fact over all issues (such as the number of
> votes it has). Issues are just not laid out right for this task.
>
> As someone who's going to be spending a good part of the next few
> weeks deeply immersed in the list of 1.0 candidate changes, I am
> pretty sure I'll go crazy if that list is not in a text file :-). (I
> don't mean to suggest that no one else will spend comparable time
> immersed in the list, by the way... But I'll bet that those who do
> will be thankful it's a text file too, in the end).
>
> There are awkwardnesses both ways. There are some aspects of this
> process that would be nice to have in the tracker, but they'll be in a
> text file instead. C'est la vie. We don't have exactly the right
> tool for the job here, so I'm trying to balance the tools we have to
> get to a Point Of Least Pain.
Maybe the issue tracker should have some sort of voting system added to
it? Obviously doesn't help us now. Mandrake added such a thing for
its bugzilla and it's pretty handy.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by kf...@collab.net.
"Erik Huelsmann" <e....@gmx.net> writes:
> But they don't have repository wide log messages and revision
> numbers. And besides that: we would have everything about managing
> subversion issues in one place: what to fix and what to merge before
> a certain milestone will nicely be listed in one list when using the
> issue tracker.
The issue tracker is very nice for tracking each individual issue, and
for roughly comparing sets of issues by summary. It's not very good
for browsing a particular fact over all issues (such as the number of
votes it has). Issues are just not laid out right for this task.
As someone who's going to be spending a good part of the next few
weeks deeply immersed in the list of 1.0 candidate changes, I am
pretty sure I'll go crazy if that list is not in a text file :-). (I
don't mean to suggest that no one else will spend comparable time
immersed in the list, by the way... But I'll bet that those who do
will be thankful it's a text file too, in the end).
There are awkwardnesses both ways. There are some aspects of this
process that would be nice to have in the tracker, but they'll be in a
text file instead. C'est la vie. We don't have exactly the right
tool for the job here, so I'm trying to balance the tools we have to
get to a Point Of Least Pain.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Erik Huelsmann <e....@gmx.net>.
> Tobias Ringström wrote:
>
> > It feels a bit strange to revision control the voting. How about
> > creating an issue for each thing we want to include in the branch, just
> > for the purpose of voting? Each issue would be named something like
> > "merge rXXXX to branch-1.0", i.e. it would not be an issue that
> > describes a bug. The committers would then vote by adding comments to
> > the issue, and the issue can either be resolved or dismissed when the
> > voting is complete.
>
> I'd prefer to keep things all in one place, rather than scattered about
> in various issues, and the STATUS file does that quite nicely. Also,
> there's some history behind this approach, as it's pretty much what the
> Apache projects do for their voting.
But they don't have repository wide log messages and revision numbers. And
besides that: we would have everything about managing subversion issues in one
place: what to fix and what to merge before a certain milestone will nicely
be listed in one list when using the issue tracker.
bye,
Erik.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Tobias Ringström wrote:
> It feels a bit strange to revision control the voting. How about
> creating an issue for each thing we want to include in the branch, just
> for the purpose of voting? Each issue would be named something like
> "merge rXXXX to branch-1.0", i.e. it would not be an issue that
> describes a bug. The committers would then vote by adding comments to
> the issue, and the issue can either be resolved or dismissed when the
> voting is complete.
I'd prefer to keep things all in one place, rather than scattered about
in various issues, and the STATUS file does that quite nicely. Also,
there's some history behind this approach, as it's pretty much what the
Apache projects do for their voting.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, December 15, 2003 8:38 PM +0100 Tobias Ringström
<to...@ringstrom.mine.nu> wrote:
> It would be nice to include an exception for harmless obviously correct
> fixes such as spelling fixes and most documentation fixes.
I'll just chime in and say that I think that's a bad idea. It should require
3 +1s across the board.
The gray area of what is 'obviously' correct between you and I are probably
very different. If it's *that* obvious, then it should be easy to get the 3
+1s. Remember we're talking about the 1.0 branch, not the trunk. I don't
think it's especially urgent to get the 'obviously correct fixes' in - IMHO,
it's more important to make sure that we follow a standardized process. --
justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Erik Huelsmann <e....@gmx.net>.
> > It feels a bit strange to revision control the voting. How about
> > creating an issue for each thing we want to include in the branch,
> > just for the purpose of voting? Each issue would be named something
> > like "merge rXXXX to branch-1.0", i.e. it would not be an issue that
> > describes a bug. The committers would then vote by adding comments to
> > the issue, and the issue can either be resolved or dismissed when the
> > voting is complete.
>
> Garrett answered this question nicely; I'll just add that issues are
> more cumbersome to work with than text files.
I always say that you have to solve problems at their root. Otherwise
everybody has to keep working around them with different solutions. Seems like
issue 1640 has to have it's priority upped... :-)
bye,
Erik.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by kf...@collab.net.
Tobias Ringström <to...@ringstrom.mine.nu> writes:
> kfogel@collab.net wrote:
> > Garrett answered this question nicely; I'll just add that issues are
> > more cumbersome to work with than text files.
>
> You mean that there is less risk of voting in the wrong file than in
> the wrong issue? ;-)
Ouch. I suppose I earned that :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
kfogel@collab.net wrote:
> Garrett answered this question nicely; I'll just add that issues are
> more cumbersome to work with than text files.
You mean that there is less risk of voting in the wrong file than in the
wrong issue? ;-)
(Sorry man... couldn't resist...)
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by kf...@collab.net.
Tobias Ringström <to...@ringstrom.mine.nu> writes:
> > +A change needs three +1 votes and no vetoes from full committers to go
> > +into the 1.0-stablization branch. We use the STATUS file in the top
>
> It would be nice to include an exception for harmless obviously
> correct fixes such as spelling fixes and most documentation fixes.
I'm fine with these being excepted. For example, we want the book
documentation up-to-date in the 1.0 tarball, as much as possible.
They should still get fixed in trunk first, then ported, of course.
> It feels a bit strange to revision control the voting. How about
> creating an issue for each thing we want to include in the branch,
> just for the purpose of voting? Each issue would be named something
> like "merge rXXXX to branch-1.0", i.e. it would not be an issue that
> describes a bug. The committers would then vote by adding comments to
> the issue, and the issue can either be resolved or dismissed when the
> voting is complete.
Garrett answered this question nicely; I'll just add that issues are
more cumbersome to work with than text files.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: process for including changes in 1.0
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
kfogel@collab.net wrote:
> We now have a number of changes proposed for 1.0 -- mostly API stuff,
> but I'm sure there will be bugfixes too. We need a process for
> deciding which ones get included.
Thanks a lot for doing this, Karl!
> +A change needs three +1 votes and no vetoes from full committers to go
> +into the 1.0-stablization branch. We use the STATUS file in the top
It would be nice to include an exception for harmless obviously correct
fixes such as spelling fixes and most documentation fixes.
It feels a bit strange to revision control the voting. How about
creating an issue for each thing we want to include in the branch, just
for the purpose of voting? Each issue would be named something like
"merge rXXXX to branch-1.0", i.e. it would not be an issue that
describes a bug. The committers would then vote by adding comments to
the issue, and the issue can either be resolved or dismissed when the
voting is complete.
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org