Tenative schedule for Tor 0.2.4 [Or, why I might reject your patches in November->March]
Hi, all!
Last year, I announced a tenative schedule for 0.2.3.x. We didn't stick to it, and things have gone a little pear-shaped with getting 0.2.3.x stabilized, but I think with a few tweaks we can use something similar to get a good schedule out for 0.2.4.x.
My goals remain about what they were before: get release out faster by getting better at saying "no" to features after a release window. My target is March or April 2013.
To that end:
October 10, 2012: Big feature proposal checkpoint. Any large complicated feature which requires a design proposal must have its first design proposal draft by this date.
November 10, 2012: Big feature checkpoint. If I don't know about a large feature by this date, it might have to wait. November 10, 2012: Big feature proposal freeze. Any small feature which requires a design proposal must have its design proposal finished by this date.
December 10, 2012: Big feature merge freeze. No big features will be merged after this date. December 10, 2012: Small feature proposal freeze. Any small feature which requires a design proposal must have its design proposal finished by this date.
January 10, 2013: Feature merge freeze. No features after this date. I mean it.
Feb 20, 2013: Buggy feature backout date. Any feature which seems intractably buggy by this date may be disabled, deprecated, or removed until the next release.
On the meaning of "feature": I'm probably going to argue that some things that you think are bugfixes are features. I'm probably going to argue that your security bugfix is actually a security feature. I'm probably even going to argue that most non-regression bugfixes are features. Let's try to get a release out *early* in 2013 this time, come heck or high water.
(This is all subject to change, but let's not push it.)
[0] https://lists.torproject.org/pipermail/tor-dev/2011-July/002851.html
happy hacking,
Minor typo noted. -Paul
On Fri, Sep 07, 2012 at 12:09:30PM -0400, Nick Mathewson wrote:
Hi, all!
Last year, I announced a tenative schedule for 0.2.3.x. We didn't stick to it, and things have gone a little pear-shaped with getting 0.2.3.x stabilized, but I think with a few tweaks we can use something similar to get a good schedule out for 0.2.4.x.
My goals remain about what they were before: get release out faster by getting better at saying "no" to features after a release window. My target is March or April 2013.
To that end:
October 10, 2012: Big feature proposal checkpoint. Any large complicated feature which requires a design proposal must have its first design proposal draft by this date.
November 10, 2012: Big feature checkpoint. If I don't know about a large feature by this date, it might have to wait. November 10, 2012: Big feature proposal freeze. Any small feature
s/small/big/
which requires a design proposal must have its design proposal finished by this date.
December 10, 2012: Big feature merge freeze. No big features will be merged after this date. December 10, 2012: Small feature proposal freeze. Any small feature which requires a design proposal must have its design proposal finished by this date.
January 10, 2013: Feature merge freeze. No features after this date. I mean it.
Feb 20, 2013: Buggy feature backout date. Any feature which seems intractably buggy by this date may be disabled, deprecated, or removed until the next release.
On the meaning of "feature": I'm probably going to argue that some things that you think are bugfixes are features. I'm probably going to argue that your security bugfix is actually a security feature. I'm probably even going to argue that most non-regression bugfixes are features. Let's try to get a release out *early* in 2013 this time, come heck or high water.
(This is all subject to change, but let's not push it.)
[0] https://lists.torproject.org/pipermail/tor-dev/2011-July/002851.html
happy hacking,
Nick _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Thus spake Nick Mathewson (nickm@freehaven.net):
Last year, I announced a tenative schedule for 0.2.3.x. We didn't stick to it, and things have gone a little pear-shaped with getting 0.2.3.x stabilized, but I think with a few tweaks we can use something similar to get a good schedule out for 0.2.4.x.
My goals remain about what they were before: get release out faster by getting better at saying "no" to features after a release window. My target is March or April 2013.
To that end:
[*snip schedule dates I'm certain to forget anyways*]
On the meaning of "feature": I'm probably going to argue that some things that you think are bugfixes are features. I'm probably going to argue that your security bugfix is actually a security feature. I'm probably even going to argue that most non-regression bugfixes are features. Let's try to get a release out *early* in 2013 this time, come heck or high water.
For people who are only occasionally/tangentially involved in tor-core development like myself, it might be useful to have some kind of active ping/reminder on tickets with the Tor-0.2.4.x-final trac milestone around the deadline deadline date(s) you deem applicable for that ticket.
Unless it is way more work for you, I think I would prefer per-ticket reminders on trac to blanket email announcements, so I know exactly what and when I should care about getting something done if I really want it done, and what deadline category you think each thing falls in to.
Thus spake Mike Perry (mikeperry@torproject.org):
Thus spake Nick Mathewson (nickm@freehaven.net):
Last year, I announced a tenative schedule for 0.2.3.x. We didn't stick to it, and things have gone a little pear-shaped with getting 0.2.3.x stabilized, but I think with a few tweaks we can use something similar to get a good schedule out for 0.2.4.x.
My goals remain about what they were before: get release out faster by getting better at saying "no" to features after a release window. My target is March or April 2013.
To that end:
[*snip schedule dates I'm certain to forget anyways*]
On the meaning of "feature": I'm probably going to argue that some things that you think are bugfixes are features. I'm probably going to argue that your security bugfix is actually a security feature. I'm probably even going to argue that most non-regression bugfixes are features. Let's try to get a release out *early* in 2013 this time, come heck or high water.
For people who are only occasionally/tangentially involved in tor-core development like myself, it might be useful to have some kind of active ping/reminder on tickets with the Tor-0.2.4.x-final trac milestone around the deadline deadline date(s) you deem applicable for that ticket.
Unless it is way more work for you, I think I would prefer per-ticket reminders on trac to blanket email announcements, so I know exactly what and when I should care about getting something done if I really want it done, and what deadline category you think each thing falls in to.
Just saw that there's already 184 tickets currently in Tor-0.2.4.x-final. Wow.
So maybe instead: We can all try to tag things in Tor-0.2.4.x-final with the right deadline tag, and then you can just do announcement emails? And/or the project coordinator can handle pinging people/tickets at the deadline points?
On Fri, Sep 7, 2012 at 5:53 PM, Mike Perry mikeperry@torproject.org wrote:
Thus spake Mike Perry (mikeperry@torproject.org):
Thus spake Nick Mathewson (nickm@freehaven.net):
Last year, I announced a tenative schedule for 0.2.3.x. We didn't stick to it, and things have gone a little pear-shaped with getting 0.2.3.x stabilized, but I think with a few tweaks we can use something similar to get a good schedule out for 0.2.4.x.
My goals remain about what they were before: get release out faster by getting better at saying "no" to features after a release window. My target is March or April 2013.
To that end:
[*snip schedule dates I'm certain to forget anyways*]
On the meaning of "feature": I'm probably going to argue that some things that you think are bugfixes are features. I'm probably going to argue that your security bugfix is actually a security feature. I'm probably even going to argue that most non-regression bugfixes are features. Let's try to get a release out *early* in 2013 this time, come heck or high water.
For people who are only occasionally/tangentially involved in tor-core development like myself, it might be useful to have some kind of active ping/reminder on tickets with the Tor-0.2.4.x-final trac milestone around the deadline deadline date(s) you deem applicable for that ticket.
Unless it is way more work for you, I think I would prefer per-ticket reminders on trac to blanket email announcements, so I know exactly what and when I should care about getting something done if I really want it done, and what deadline category you think each thing falls in to.
It is indeed more work for me to re-evaluate every Tor ticket every month; maybe we can come up with some way to make it less work so that everybody gets the info they need without me doing monthly triage? Or maybe I should just commit to monthly triage.
Just saw that there's already 184 tickets currently in Tor-0.2.4.x-final. Wow.
TBF, probably not every one is really for 0.2.4. People put stuff in the next release's milestone as an aspiration pretty often. Also, there are probably things (proposals, intended proposals, stuff in Tor: undecided, vague intentions) that ought to have tickets for 0.2.4.x but don't.
So maybe instead: We can all try to tag things in Tor-0.2.4.x-final with the right deadline tag, and then you can just do announcement emails? And/or the project coordinator can handle pinging people/tickets at the deadline points?
AFAIK, the right deadline tag would be small vs large and proposal-needed vs no-proposal-needed? I'd be glad for these tags to exist, so long as somebody else helps me make them, and so long as I have the freedom to decide after the fact that I was wrong about something.
yrs,
-
Mike Perry -
Nick Mathewson -
Nick Mathewson -
Paul Syverson