Re: Most likely 1.3 1st then 2.x

2007-08-25 Thread Jim Jagielski


On Aug 24, 2007, at 7:47 PM, Sander Temme wrote:


Ruediger Pluem wrote:


On 08/24/2007 02:54 PM, Jim Jagielski wrote:

To be honest, I can't see holding off the 1.3 release any longer
while we're waiting on APR as well as stuff is being added
to the 2.x trees... It's kind of embarrassing.


+1.

As far as I understand this downgrade scenario is one of the  
reasons

why we aim to release all stable branches at the same point of time.


It might help to keep the release quiet: put the code out there and
update the page, but keep it off the front page and out of the public
channels.

We can even do the same for 2.0.x once we have our regression  
fixed, and

then make a splash for all three when 2.2.x is done.



This is all well and good, except, to be honest, how confident
are we that 2.x will be released any time soon? If they
were, I'd say wait and release/announce all 3 together.

We've pushed back the releases at least 3 times already;
1.3 is ready; 2.0 and 2.2 aren't, yet, and we have no
real idea when then will be. Like I said, I can't
see keeping 1.3.38 from our 1.3 users simply because
2.x isn't ready



Most likely 1.3 1st then 2.x

2007-08-24 Thread Jim Jagielski


To be honest, I can't see holding off the 1.3 release any longer
while we're waiting on APR as well as stuff is being added
to the 2.x trees... It's kind of embarrassing.

So even though I have most of the files setup for triple
release, I think next week I'll just release 1.3 and we
can the release 2.x when ready and not continue to hold
our 1.3 users hostage.


Re: Most likely 1.3 1st then 2.x

2007-08-24 Thread Ruediger Pluem


On 08/24/2007 02:54 PM, Jim Jagielski wrote:
 
 To be honest, I can't see holding off the 1.3 release any longer
 while we're waiting on APR as well as stuff is being added
 to the 2.x trees... It's kind of embarrassing.
 
 So even though I have most of the files setup for triple
 release, I think next week I'll just release 1.3 and we
 can the release 2.x when ready and not continue to hold
 our 1.3 users hostage.

+1. I think the number of people going back to 1.3 from 2.0 / 2.2
because this 1.3 release is newer than the latest 2.0 / 2.2 release
is comparable low.
As far as I understand this downgrade scenario is one of the reasons
why we aim to release all stable branches at the same point of time.

Regards

RĂ¼diger





Re: Most likely 1.3 1st then 2.x

2007-08-24 Thread Sander Temme
Ruediger Pluem wrote:

 On 08/24/2007 02:54 PM, Jim Jagielski wrote:
 To be honest, I can't see holding off the 1.3 release any longer
 while we're waiting on APR as well as stuff is being added
 to the 2.x trees... It's kind of embarrassing.

+1.

 As far as I understand this downgrade scenario is one of the reasons
 why we aim to release all stable branches at the same point of time.

It might help to keep the release quiet: put the code out there and
update the page, but keep it off the front page and out of the public
channels.

We can even do the same for 2.0.x once we have our regression fixed, and
then make a splash for all three when 2.2.x is done.

S.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: Most likely 1.3 1st then 2.x

2007-08-24 Thread William A. Rowe, Jr.
Sander Temme wrote:
 
 We can even do the same for 2.0.x once we have our regression fixed, and
 then make a splash for all three when 2.2.x is done.

2.0 and 2.2 both have piped log issues.

For 2.0 this is slightly more critical, we still invoke the log pipe app
directly, and then pid_kill the thing on plog teardown.  This means
there is a lag between now-dead logger and new open_logs hook, which
is especially uncool.  On 2.2 it's not quite so bad, since we pid_kill
bin/sh leaving bin/sh's invoked process running.

r569535 doesn't quite clean on either 2.0 or 2.2, so I'll post up the link
a bit later to tweaked patches.