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 2004/01/24 06:10:08 UTC
tomorrow's 0.37
Note that Josander is rolling 0.37 around 6pm his time tomorrow (I
think he's in the European GMT+1 timezone).
It's terribly bad form for me to suggest that developers review and
vote on changes at the last minute. But I'm going to anyway, because
the changes in question are mostly very small and low-risk (with the
exception of r8463, which looks big although it's actually not
complex, and prevents a really stupid bug). Also, some of these
changes got held up by unexpectedly long discussions settling on
unexpectedly small tweaks. Seems a shame, etc, etc.
So:
* Issue #1705 (patch 291)
Change blame receiver's line_no argument from apr_off_t to apr_int64_t.
Votes: +1: ghudson, kfogel
* Issue #1713
Change svn_filesize_t to signed, for consistency and SVN_INVALID_FILESIZE
Votes: +1: ghudson, kfogel
Those two are the unexpectedly small result of the apr_off_t thread
(the other result is discussion on dev@apr, at least for now). In
#1713's case, there are good reasons to do it independently of the
whole apr_off_t thing, and it's a truly tiny change.
* r8463 (fix for issue #1709)
Make mod_dav_svn stop spewing huge responses at dead sockets.
Votes: +1: cmpilato, kfogel
You may recall from the dev@ list that there's still a bug where
hitting ^C on the client side doesn't correctly shut down the socket.
But having r8463 on the server side is much more important -- it means
when we get the ^C bug fixed on the client side, servers will be ready
to Do The Right Thing. So I think this is worth having. (I'm not
sure I agree with the DoS claim in STATUS, because the DoS attack is
still there -- all the attacker has to do is not shut down the socket.
But it's still a stupid bug with ugly server-side consequences.)
* r8139
Fix authentication bugs.
Votes: +1: ghudson
I'm not particularly advocating r8139, but if Tobias (bliss) thinks it
should have gone in, and was just missed because of an oversight, then
I hope he'll vote for it as early as possible tomorrow. I'll watch
for such a change, and any mails from him.
Finally, there's this:
* r8368, r8417, r8418, r8438, r8439, r8440, r8441, r8442
Support SWIG 1.3.20 and newer and require at least 1.3.19.
Justification: An increasingly common version of SWIG that we
need to support. And have proper requirements.
Votes:
+1: breser
+1 (concept and build system changes): ghudson
Personally, I've had a greater-than-random tendency to miss mistakes
in build system changes :-), so I'm reluctant to provide a +1 on this
if others more competent can review it. I'll check back tomorrow
morning and see if anyone has had a chance. (Remember, the build
system portion needs three +1's, and only has Greg Hudson's right
now.)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: omorrow's 0.37
Posted by Ben Reser <be...@reser.org>.
On Sat, Jan 24, 2004 at 12:20:20AM -0600, kfogel@collab.net wrote:
> kfogel@collab.net writes:
> > to Do The Right Thing. So I think this is worth having. (I'm not
> > sure I agree with the DoS claim in STATUS, because the DoS attack is
> > still there -- all the attacker has to do is not shut down the socket.
> > But it's still a stupid bug with ugly server-side consequences.)
>
> Looking at issue #1709, it seems that in some environments, there
> really is a DoS attack unique to r8463. In Greg Stein's words from
> the issue: "Without the network I/O present to throttle the CPU, it
> takes all it can."
I hope this IRC transcript helps people in understanding the issue from
a security standpoint.
11:17 < ghudson> sussman: Did you read jackr's last comment in issue
#1709?
11:18 < ghudson> dionisos: The definition varies. But I don't think
fixing #1709 makes it particularly harder to DOS an
svn server.
11:18 < dionisos> hmm. ok. I have to think about that one...
11:19 <@sussman> hm
11:19 < ghudson> Hm, I suppose the network does act as a throttle on
httpd's CPU usage when the checkout is progressing
normally.
11:19 <@sussman> yah
11:19 < jackr> ghudson: my last comment was "my case ain't like the
others," but then everybody else says "me, too," so I
think my last is essentially void....
11:19 <@sussman> people were complaining that their httpd jumped to
100% cpu
11:20 < ghudson> jackr: No, your last comment isn't void. The point
is, httpd will eventually finish the checkout and
return to normal. It's doing more work than it has
to, but no more work (in total) than it would be doing
if the checkout had proceeded.
11:20 <@sussman> so it's not a DoS in the sense of "bringing down a
server"
11:21 <@sussman> it's just an easy way to make a server's cpu load spike
11:21 <@sussman> for a few minutes.
11:21 < ghudson> I guess it's sort of a DOS situation if the unthrottled
httpd is competing too hard against the other work the
server is doing. Later comments in the thread seem to
indicate that the server isn't hurt all that badly.
11:21 < ghudson> My point is, if I want to make the server do that much
work, I can just do a checkout.
11:22 < jackr> It could be used to reduce the "D" needed for a "D"DOS
11:22 < holsta> DDoS != DoS
11:23 * sussman files an issue: 'svn checkout' == potential DoS!
11:25 < jackr> the server doing this dance is using more CPU (but less
of other resources) than the one doing a healthy checkout
11:25 < ghudson> Let's say I want to DOS svn.collab.net. With the
current bug, I can start ten checkouts and close the
sockets, and that will cause a high load on the CPU.
Without the bug, I can start ten checkouts and throw
the resulting data away, which will cause a lower load
on the CPU but also a big load on the network. I
suppose if I don't have a big pipe, my ability to
figure out which ACKs I need to send to keep the data
flowing is limited.
11:26 < jackr> But still, the order of the problem to DoS with or
without this defect is pretty much the same.
11:27 < holsta> Even from a 'application responsiveness' this should be
fixed; never mind the CPU usage.
11:28 < holsta> People are going to be pretty annoyed if they have to
wait for minutes simply because they abort a checkout.
11:28 < jackr> holsta: +1. Just meant "it's not really a security
thang."
11:29 < holsta> security thong. Now there's a thought.
11:29 < jackr> Ouch!
11:30 <@sussman> wait for minutes?
11:30 <@sussman> there's no waiting.
11:30 <@sussman> the client disconnects and quits.
11:30 <@sussman> then httpd keeps spewing data at the dead socket,
spiking up the cpu load.
11:31 < holsta> Hm, I got that impression from Heap's session transcript
in the bug.
11:31 < jackr> yeah, we shouldn't muddle this with that other problem:
^C doesn't work.
11:32 < jackr> Still, if I so something like "svn co -m'bogus comment'
http://repo/with/lots/of/stuff", then kill it, fix the
comment, kill it, fix the comment again, kill it, ...
Pretty soon, I'm turkey-DoSsing the site.....
11:32 * jackr has been there
11:32 < jackr> s/so something/do something/
11:32 <@sussman> I just wanna know if anyone is going to veto the
change, before I bother to review it.
11:34 < dsp> VETO
11:34 < dionisos> no veto; I think it's a good thing. (no +1 either; I'm
too bus y with other stuff atm)
11:36 < ghudson> I'm not going to veto it.
11:38 * sussman reviews
11:42 * dionisos wonders if sussman reads philips mail while reviewing...
11:43 < breser> The issue with this as DoS issue is not that it's unique
in the amount of work it creates for the server, but that
it allows a client to request the server to do work
without the overhead of receiving it.
11:43 < breser> It creates a situation where with very little resources
you can hurt the server.
11:43 < breser> Whereas a large checkout while actually listening would
requiring receiving a large amount of data.
11:44 < breser> This makes an attackers potential effect greater than he
would ordinarily be able to have.
11:44 < djh> sussman: The client does wait for a long time after Ctrl-C
a checkout
11:44 < breser> Now granted a DDoS attack negates the value in that.
11:45 < breser> The DDoS attacker doesn't care about the resources he is
using generally and has a lot more resources in
aggregate than the server is likely to have.
11:46 < breser> So it's not a DoS issue in and of itself. It just makes
it easier to carry out a DoS attack.
--
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: tomorrow's 0.37
Posted by kf...@collab.net.
kfogel@collab.net writes:
> to Do The Right Thing. So I think this is worth having. (I'm not
> sure I agree with the DoS claim in STATUS, because the DoS attack is
> still there -- all the attacker has to do is not shut down the socket.
> But it's still a stupid bug with ugly server-side consequences.)
Looking at issue #1709, it seems that in some environments, there
really is a DoS attack unique to r8463. In Greg Stein's words from
the issue: "Without the network I/O present to throttle the CPU, it
takes all it can."
So this fix is even more important than I said :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> >So let's branch from the 0.37.0 tag and make a new STATUS file so I can
> >write an item there as soon as possible (I do even have more changes to
> >do there before 1.0).
>
> I disagree; simply merge from tags/0.37.0 to branches/1.0.x.
Just so you're both aware:
There are *no* changes in 0.37.0 from 1.0-stabilization. Therefore,
now that 1.0-stabilization has been renamed to 1.0.x, there is no need
to merge anything over from 0.37.0. We're completely up-to-date.
(I don't think Josander necessarily disagrees with you, Brane, I think
he just responded to my mail before seeing your followup suggestion.)
> I really don't know why this is necessary. All necessary changes to
> installers should be made on the release branch before the release is
> tagged, otherwise people can't make their own packages from the tarball.
Agree. What we should be doing from now on, in general, is:
Make changes in branches/1.0.x/. When ready, snap a tarball from it.
Never create another branch for it, but when the tarball is released,
do 'svn cp -r XXX branches/1.0.x tags/1.0.1' (or whatever), where XXX
is the revision used for the tarball.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by "Jostein Chr. Andersen" <jo...@josander.net>.
On Tuesday 27 January 2004 20.27, Branko Čibej wrote:
> Jostein Chr. Andersen wrote:
> >The packages too? I have used the installer source from the trunk all
> > the time (while the branched code have been older and older).
> >
> >The only win32 installer code that works is that one in the trunk
> > (it's even the most stable installer so far :-).
>
> This is not a good situation. IMHO the installer on the branch should
> be kept up-to-date -- remember, Win32 build on the trunk is already
> significantly different than the one on the branch (trunk uses APR
> DLLs)
I have been asking about how to handle this both on IRC and several times
on the dev list without getting any response, thanks :-)
So let's branch from the 0.37.0 tag and make a new STATUS file so I
> > can write an item there as soon as possible (I do even have more
> > changes to do there before 1.0).
>
> I disagree; simply merge from tags/0.37.0 to branches/1.0.x.
The inno setup in tags/0.37.0 are outdated, the inno setup in the trunk
are a perfect match for 0.37.0 and (have you noticed: -Not a single
problem or complain about the Windows installer this time? :-)
> >Please, remember that packages/installers are made _after_ the
> > tarball. Changes in this might occure after a release tag.
>
> I really don't know why this is necessary. All necessary changes to
> installers should be made on the release branch before the release is
> tagged, otherwise people can't make their own packages from the
> tarball. That's weird
In my case, the Windows installer are made after you have made the
binaries. Hopefully, some bindings will come on regular basis (jave,
perl)as well so I can make a full Installer as well.
The thing is that I really don't know what to include in the installer
every time it's created.
> We can do this at least for Windows, where the package maintainer and
> release manager are the same person. :-)
Me to (RM have a multi personality... ..oh, so do I, cool! ;-)
Jostein
--
http://www.josander.net/kontakt/ ||
http://www.josander.net/en/contact/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by Branko Čibej <br...@xbc.nu>.
Jostein Chr. Andersen wrote:
>On Monday 26 January 2004 17.59, kfogel@collab.net wrote:
>
>
>>I think the above categories don't even need voting, let's just treat
>>them like trunk commits, with post-facto review. Meanwhile, the
>>categories below would use the voting system, but still not affect the
>>soak time:
>>
>> * Anything in tools/, packages/.
>>
>>
>
>The packages too? I have used the installer source from the trunk all the
>time (while the branched code have been older and older).
>
>The only win32 installer code that works is that one in the trunk (it's
>even the most stable installer so far :-).
>
>
This is not a good situation. IMHO the installer on the branch should be
kept up-to-date -- remember, Win32 build on the trunk is already
significantly different than the one on the branch (trunk uses APR DLLs)
>So let's branch from the 0.37.0 tag and make a new STATUS file so I can
>write an item there as soon as possible (I do even have more changes to
>do there before 1.0).
>
>
I disagree; simply merge from tags/0.37.0 to branches/1.0.x.
>Please, remember that packages/installers are made _after_ the tarball.
>Changes in this might occure after a release tag.
>
>
I really don't know why this is necessary. All necessary changes to
installers should be made on the release branch before the release is
tagged, otherwise people can't make their own packages from the tarball.
That's weird.
We can do this at least for Windows, where the package maintainer and
release manager are the same person. :-)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> On Tue, 2004-01-27 at 11:14, kfogel@collab.net wrote:
> > 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 :-) ]
>
> I don't really agree; just because someone on bugtraq thinks a path leak
> is a real security hole doesn't make it true. (Not saying we shouldn't
> fix it, just that we shouldn't pollute bugtraq with unimportant
> revelations.)
If someone else does post this to BugTraq, is there a mechanism by
which we can follow up with an addendum?
What I want to avoid is someone making the bug sound more serious than
it is. As long as there's a way for us to correct any misimpressions,
then I'm happy with doing nothing until if/when we see a first post.
(Of course, agree we should fix it in trunk and 1.0.1.)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by kf...@collab.net.
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
soon).
I think that answers everything that's come up in this thread. If
anyone has any concerns not yet addressed, please make a noise :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by "Jostein Chr. Andersen" <jo...@josander.net>.
On Monday 26 January 2004 17.59, kfogel@collab.net wrote:
> I think the above categories don't even need voting, let's just treat
> them like trunk commits, with post-facto review. Meanwhile, the
> categories below would use the voting system, but still not affect the
> soak time:
>
> * Anything in tools/, packages/.
The packages too? I have used the installer source from the trunk all the
time (while the branched code have been older and older).
The only win32 installer code that works is that one in the trunk (it's
even the most stable installer so far :-).
So let's branch from the 0.37.0 tag and make a new STATUS file so I can
write an item there as soon as possible (I do even have more changes to
do there before 1.0).
Please, remember that packages/installers are made _after_ the tarball.
Changes in this might occure after a release tag.
Jostein
--
http://www.josander.net/kontakt/ ||
http://www.josander.net/en/contact/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Tue, Jan 27, 2004 at 09:40:36AM +0000, Mike Mason wrote:
> Branko ??ibej wrote:
>
> >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.
> >
> >
>
> How about security bugs? 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 would like to see this fixed before 1.0, but I'm not in a position to
provide a patch right now.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by Mike Mason <mg...@thoughtworks.net>.
Branko Čibej wrote:
> 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.
>
>
How about security bugs? 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.
Cheers,
Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
>kfogel@collab.net wrote:
>
>
>>If we do find a showstopper bug in 0.37.0, then we release 0.37.1 as
>>per usual procedures, then run the above algorithm with "0.37.1"
>>substituted for "0.37.0". In which case, the four-week countdown
>>would start from 0.37.1's release date, not 0.37.0's, of course.
>>
>>That's all. Thoughts?
>>
>>
>>
>>
>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.
>
>
Just to be clear, I mean server crashes or client crashes without a
workaround. I don't think a crash in an edge case in some obscure
feature should hold up the release.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.0.0, 1.0.x plan
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>However, for a clear lineage from 0.37.0->1.0, what I'd like to do is:
>
> 1. Remove the 1.0-stabilization branch, which has had no changes
> since r8509, when josander branched 0.37.0.
>
> 2. Create branches/1.0.0, copied from the 0.37.0 tag.
>
>
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.
(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.)
[...]
>If we do find a showstopper bug in 0.37.0, then we release 0.37.1 as
>per usual procedures, then run the above algorithm with "0.37.1"
>substituted for "0.37.0". In which case, the four-week countdown
>would start from 0.37.1's release date, not 0.37.0's, of course.
>
>That's all. Thoughts?
>
>
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.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
1.0.0, 1.0.x plan
Posted by kf...@collab.net.
This is the first of two mails. This one deals with how to treat the
0.37/1.0 line between now and the 1.0.0 release, and how to treat the
1.0.x line after that release.
The second mail will be about the larger Post-1.0 universe -- about
achieving consensus on what should go into 1.x versus 2.0. (The
second mail will also talk about release numbering, but I need to go
carefully back over our long thread on that before making a serious
proposal.)
Needless to say, this first mail is the simpler of the two :-).
Everything below is merely one proposal, just how I envision the
process working. Although written in declarative tone for clarity,
I'm not trying to present it as the only possible path. Feedback
(negative or positive) is welcome.
Release 0.37.0 is our first "1.0 candidate" release, meaning that
barring the discovery of serious bugs, it is what we will release as
1.0. We should aim to have four weeks of "soak time" for this code,
so we can be confident it contains no surprises.
Note that I said "surprises", not "bugs" :-). We should assume we'll
find *some* bugs in 0.37.0, the question is only how serious will they
be. We should evaluate them on a case-by-case basis. If a bug is
deemed acceptable for the 1.0 release (and I expect/hope most will
be), we can treat it like any other bug: file an issue, maybe fix it
in trunk right then if we want.
Of course, there will be some fixes that we feel should eventually get
into the 1.0.x line, just not into 1.0.0. (I'm punting on the release
numbering question for the moment -- for the sake of discussion, let's
talk as though "1.0.0", "1.0.1", and "1.0.2", are successive public
releases on the stable 1.0 line.) To keep track of such changes,
let's use the STATUS file as before. Since 1.0.x is supposed to be a
stable, ABI-compatible line, let's also use the same voting system
there, for as long as the line lasts.
However, for a clear lineage from 0.37.0->1.0, what I'd like to do is:
1. Remove the 1.0-stabilization branch, which has had no changes
since r8509, when josander branched 0.37.0.
2. Create branches/1.0.0, copied from the 0.37.0 tag.
3. Accept certain kinds of innocuous commits in the 1.0.0 branch for
the next four weeks [details below], including STATUS commits.
An "innocuous commit" is one that doesn't affect our four-week
soak time.
4. When Feb. 23rd arrives, josander rolls subversion-1.0.0.tar.gz
from the 1.0.0 branch, tags it, and goes contentedly to bed :-).
Obviously, no core code change is innocuous. But these kinds of
changes are:
* Any documentation changes, including book changes, INSTALL,
HACKING, www/ area, etc. (The www/ area we can just update all
at once from trunk on the day of the release, if we want.)
* Any dist.sh changes josander wants.
* STATUS file updates, such as inserting 1.0.1 candidate changes.
I think the above categories don't even need voting, let's just treat
them like trunk commits, with post-facto review. Meanwhile, the
categories below would use the voting system, but still not affect the
soak time:
* Anything in tools/, packages/.
* Bindings-only changes. (I'm hoping there aren't any more 1.0
bindings changes left, but if there are, it's more important to
ship with the latest bindings than to soak the bindings for a
whole month.)
* Doc fixes in core code header files or source files.
If we do find a showstopper bug in 0.37.0, then we release 0.37.1 as
per usual procedures, then run the above algorithm with "0.37.1"
substituted for "0.37.0". In which case, the four-week countdown
would start from 0.37.1's release date, not 0.37.0's, of course.
That's all. Thoughts?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: omorrow's 0.37
Posted by Ben Reser <be...@reser.org>.
On Sat, Jan 24, 2004 at 07:59:41AM -0800, Ben Reser wrote:
> Once you get past the conflicts and the number of patches the change is
> not particularly complex. So to try and save everyone the time of doing
> that in reviewing this I'm attaching a patch that would be the merge
> from those changes listed above.
r8457 was missing from this on accident. New patch attached.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
Re: tomorrow's 0.37
Posted by Ben Reser <be...@reser.org>.
On Sat, Jan 24, 2004 at 12:10:08AM -0600, kfogel@collab.net wrote:
> Finally, there's this:
>
> * r8368, r8417, r8418, r8438, r8439, r8440, r8441, r8442
> Support SWIG 1.3.20 and newer and require at least 1.3.19.
> Justification: An increasingly common version of SWIG that we
> need to support. And have proper requirements.
> Votes:
> +1: breser
> +1 (concept and build system changes): ghudson
>
> Personally, I've had a greater-than-random tendency to miss mistakes
> in build system changes :-), so I'm reluctant to provide a +1 on this
> if others more competent can review it. I'll check back tomorrow
> morning and see if anyone has had a chance. (Remember, the build
> system portion needs three +1's, and only has Greg Hudson's right
> now.)
We really need this. I just answered private emails from a SuSE
employee and a gentoo contributor asking for my patch that I had
mentioned on the announcement list. If we don't get this merged and
reviewed all the major distros are likely to be using it anyway. I know
Mandrake will because I'll be doing it myself.
Someone mentioned on IRC that some projects no longer support 1.3.19
bcause they've found bugs that make their bindings not work properly. I
don't believe we have run into this. But because of that distros are
going to be under pressure to use a newer SWIG.
r8368 can be dropped from this patch set. The effect of that change has
already been merged by a different change. r8417 creates a small
conflict on Makefile.PL where we added a line that was nearby and both
lines are needed.
Once you get past the conflicts and the number of patches the change is
not particularly complex. So to try and save everyone the time of doing
that in reviewing this I'm attaching a patch that would be the merge
from those changes listed above.
The perl sections of this patch were approved by clkao and haven't
changed since then. The stuff that has changed is documentation and
build system stuff that neither he nor I can approve.
I'll be around on IRC if anyone has any questions they need answered.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken