Upcoming 2.0.56 release (?)

[Of course this message doesn't make a whole lot of sense
on devapr, reposting]

AFAIK - we were simply holding on apr[-util] 0.9 to be
baked.  Vote is
in-progress on devapr (in case you weren't watching that
list - it might
interest you to follow the low-level discussions there.)

Provided that passes, and if nobody speaks quickly and
loudly, I'll RM a
tarball once that vote on devapr flies.  Speak now if
there are issues 

Bill

On Mon, Mar 27, 2006 at 02:26:39AM -0600, William A. Rowe,
Jr. wrote:
> Provided that passes, and if nobody speaks quickly and
loudly, I'll RM a
> tarball once that vote on devapr flies.  Speak now if
there are issues 

I don't know if it's implicit or not, but we shouldn't
bundle unreleased
libraries, so it shouldn't be enough that an apr(-util)
passed the vote,
it should be GA too. We need thicker chinese walls  

Just a minor change to our sometime-adopted procedure that
might help
non-APR httpd-committers out. 

I've finally deleted that patch proposal which made no
sense and taken a
look at some more of the proposals. 

Since this is our first post 2.2 GA release, do we still
want feedback
from infra? downgrading a.o might send some bad signals  Or maybe
there's a subdomain or two running 2.0 still?

-- 
Colm MacCárthaigh                        Public Key:
colm+pgpstdlib.net

On Monday 27 March 2006 11:07, Colm MacCarthaigh wrote:

> Since this is our first post 2.2 GA release, do we
still want feedback
> from infra? downgrading a.o might send some bad signals
 Or
maybe
> there's a subdomain or two running 2.0 still?

Huh?  Who's talking about downgrading?

-- 
Nick Kew

Colm MacCarthaigh wrote:
> On Mon, Mar 27, 2006 at 02:26:39AM -0600, William A.
Rowe, Jr. wrote:
> 
>>Provided that passes, and if nobody speaks quickly
and loudly, I'll RM a
>>tarball once that vote on devapr flies.  Speak now if
there are issues 
> 
> I don't know if it's implicit or not, but we
shouldn't bundle unreleased
> libraries, so it shouldn't be enough that an
apr(-util) passed the vote,
> it should be GA too. We need thicker chinese walls  

Explain the distinction   AFAIK APR
is holding a vote on releasing 0.9.11.
AFAIK APR just held a vote and released 1.2.6.  APR hasn't
released any
alpha/beta versions in a very long time (probably wouldn't
either, until they
get ready for APR 2.)

> I've finally deleted that patch proposal which made no
sense and taken a
> look at some more of the proposals. 

Rather than delete it - you could have also added the
subsequent patches that
were applied to server/mpm/winnt/mpm_winnt.c.  I put in that
comment to prod
FirstBill to clarify which later patches were necessary.

> Since this is our first post 2.2 GA release, do we
still want feedback
> from infra? downgrading a.o might send some bad signals
 Or
maybe
> there's a subdomain or two running 2.0 still?

I think we have alot of sandboxes, but it's true that we
aren't quite in
shape to eat our own dogfood on 2.0.x anymore.  On the other
hand, we haven't
been running 1.3.x in a very long time, and yet (and rarely)
ship a 1.3.x
without passing that metric.  I doubt we can ever return to
that state, but
if there are zones running 2.0 it would be nice to get this
validated in the
real world.

On the other hand, it's a sorry state that we can't run
anything other than
-dev today, I do expect 2.2.1 to be running on our post 2.0
infrastructure
before it will garner my +1.

Bill

On Mon, Mar 27, 2006 at 12:46:05PM -0600, William A. Rowe,
Jr. wrote:
> >>Provided that passes, and if nobody speaks
quickly and loudly, I'll
> >>RM a tarball once that vote on devapr
flies.  Speak now if there
> >>are issues 
> >
> >I don't know if it's implicit or not, but we
shouldn't bundle
> >unreleased libraries, so it shouldn't be enough
that an apr(-util)
> >passed the vote, it should be GA too. We need
thicker chinese walls
> > 
> 
> Explain the distinction   AFAIK APR
is holding a vote on releasing
> 0.9.11.  AFAIK APR just held a vote and released 1.2.6.
 APR hasn't
> released any alpha/beta versions in a very long time
(probably
> wouldn't either, until they get ready for APR 2.)

Oh I just mean that the tarballs be generally available, ie
that apr
actually have released. In the past, there have been httpd
votes which
incorporated an unreleased apr, though it was clear that it
would be
released by the time httpd was. Now there are some more
httpd folk who
are not apr folk, and it can be confusing.

> >I've finally deleted that patch proposal which
made no sense and
> >taken a look at some more of the proposals. 
> 
> Rather than delete it - you could have also added the
subsequent
> patches that were applied to
server/mpm/winnt/mpm_winnt.c.  I put in
> that comment to prod FirstBill to clarify which later
patches were
> necessary.

I brought it up on list 3 times, including specifically
asking what
people meant by the proposal and got nothing, so now it's
gone. 

I couldn't add those patches (it's not even clear what
patches were
being talked about), as it's not clear that that's what
the people voted
on. I guess I could have replaced it with a different
proposal and reset
the vote count to zero. 

> >Since this is our first post 2.2 GA release, do we
still want
> >feedback from infra? downgrading a.o might send
some bad signals 
> >Or maybe there's a subdomain or two running 2.0
still?
> 
> I think we have alot of sandboxes, but it's true that
we aren't quite
> in shape to eat our own dogfood on 2.0.x anymore.  On
the other hand,
> we haven't been running 1.3.x in a very long time, and
yet (and
> rarely) ship a 1.3.x without passing that metric.  I
doubt we can ever
> return to that state, but if there are zones running
2.0 it would be
> nice to get this validated in the real world.
> 
> On the other hand, it's a sorry state that we can't
run anything other
> than -dev today, I do expect 2.2.1 to be running on our
post 2.0
> infrastructure before it will garner my +1.

+1

-- 
Colm MacCárthaigh                        Public Key:
colm+pgpstdlib.net