Branko Čibej writes:
> I'd suggest simply renaming branches/1.0-stabilization to
> branches/1.0.x. The 1.0 series releases shoudl be made straight off this
> branch, since it should always remain stable.
Excellent suggestion. I'll do that instead, and...
> (IMHO it was a mistake to create a 0.37.0 branch, but that's counting
> birds flown. Obviously any changes that were made on 0.37.0 should be
> merged back to 1.0-stabilization.)
... also this :-). (Will doc this all up, too, so we remember.)
> We should define what "showstopper" means, and be very strict about it.
> IMHO crashes and data corruption bugs would be the only candidates at
> this point.
Let's use that as a guideline. I don't think we can predict all
possible showstoppers in advance. If someone discovers a bug that is
not a crash or a corruption problem, yet nevertheless is so serious
that everyone agrees it should hold up the release, we're not going to
tolerate it just because it didn't meet the official definition. So
yes, let's say that crashes and data corruption are the threshold of
seriousness, but also be open to judgement calls.
(If by some freak of fate we can't consense on whether a bug is
tolerable, then a vote among the full committers is the last resort,
as always. I really don't expect this to happen, though.)
Mike Mason and Mark Benedetto King wrote:
> [about a path-leakage security buglet]
This is only an information-leakage bug, a lesser class of security
bug than (say) root exploit or httpd-user exploits. While it should
be fixed in 1.0.1 or so, it's not worth holding up 1.0.0 for IMHO.
Mike mentioned BugTraq:
> There was some discussion about the importance of applying an
> information-leak fix before 1.0, because otherwise it'd come out on
> BugTraq and tarnish Subversion's reputation. I'm not sure if the fix
> got applied or not.
I think we should worry more about the real consequences of the bug,
and trust BugTraq's readership to do the same. [Also, we should mail
BugTraq ourselves with a description, and a prediction of a fix in
1.0.1 or whenever we schedule it for. Better to be in control of your
own bad news than let someone drive it :-) ]
Not saying reputation isn't important, just that this very minor
tarnishing isn't going to be a huge blow for Subversion.
I'll take Brane's suggestion and create the 1.0.x branch right now, so
we can start proposing >=1.0.1 bug fixes in STATUS right now (also,
Josander wanted to be able to start making dist changes in that line
I think that answers everything that's come up in this thread. If
anyone has any concerns not yet addressed, please make a noise :-).
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Jan 27 18:13:10 2004