Q1: Rollup Release Format - Score So Far...

[Graham Leggett <mi...@sharp.fm>]

Hi all,

> o Option A: apache-2.x.x.tar.gz

+1: justin, cliff, wrowe, chuck, ianh, stoddard

> o Option B: apache-2.x.x.tar.gz, apache-modules-2.x.x.tar.gz

+1: gstein, rbb
+0.5: aaron

> o Option C: apache-2.x.x.tar.gz, apache-proxy-2.x.x.tar.gz,

+0.5: aaron

> o Option D: something else...

Please check whether your opinion has been correctly attributed. Do we
have enough consensus here, or is there more discussion needed?

The winner seems to be that the Apache group releases a rollup release
with all (at least apr, apr-util, httpd-2.0, httpd-proxy, httpd-ldap)
the projects included, and that release is called "apache-2.x.x.tar.gz".
Am I right on this one?

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: Q1: Rollup Release Format - Score So Far...

[Graham Leggett <mi...@sharp.fm>]

"William A. Rowe, Jr." wrote:

> Not if a module has released an incremental bugfix/securityfix between
> major core httpd releases, it doesn't.

If there is a security or serious bug fix, we should fire off another
rollup release. If it's a minor bugfix, a module should just wait till
the next rollup release comes around.

Right now, it seems that every now and again someone will still up their
head and say "time for another release?". At this point, people get
their ducks in a row and clear out any showstoppers, then the release is
issued and based on quality called beta/gold/whatever.

In future, anyone in any module project will stick up their head and say
"time for another release?". At this point, people in httpd-proxy,
httpd-ldap, httpd-2.0, apr and apr-util will get their ducks in a row
and clear out any showstoppers, then the release is issued and based on
quality called beta/gold/whatever.

The technique works well now, I believe it will still work even where
there is more than one module - perhaps an httpd-all mailing list needs
to be set up (containing all the sub lists) to which the "time for
another release?" message can be sent, so everyone is warned at the same
time of a coming release.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: Q1: Rollup Release Format - Score So Far...

[Alex Stewart <al...@foogod.com>]

Graham Leggett wrote:

> Alex Stewart wrote:
>>There seems to be a big assumption here that "release" is the same as
>>"version", which seems like an unnecessary restriction.
>>
>>Frankly, if these are separate subprojects we're talking about (which it
>>seems pretty clear they're going to be evolving into, if they aren't
>>already), they should have separate, independent versioning.
>>
> 
> But consensus has just been reached that there will be a single rollup
> release, so out of necessity there will have to be one version per
> release.


Why?  It's the necessity for the one-to-one mapping between versions and 
releases that I'm questioning.  I don't see the requirement.  My point 
is that there is (and should be) a difference between _release_ 
numbering and _version_ numbering.  The same version of a module may go 
in multiple releases (if nothing's changed in that particular bit), so 
why change the module's version number just because it's being packaged 
again?  Likewise, why restrict module versioning such that its version 
can't change unless there's another rollup (or worse yet, its version 
can't change unless there's a new httpd released)?


>>Trying to
>>coordinate the version numbers of umpteen different projects just
>>because one of their possible distribution channels distributes them
>>together is silly and a lot of unnecessary extra work.
>>
> 
> We are currently coordinating three different projects (httpd-core, apr,
> apr-util) being released together and things are working fine. I don't
> see how expanding this to 4 or 5 is such a problem?


Well, your previous message demonstrated one reason:  It requires a lot 
more coordination (the "enormous trumpet call") to make sure things are 
consistent at rollup time, and there's no advantage (that I see) gained 
from it.  It also doesn't scale well at all.  (As somebody who's 
designed and administrated a few different large-scale CVS-based 
software release systems, I'm speaking from personal experience on that 
bit.)

In the short term, we may not be scaling to more than 4 or 5 projects, 
but I don't see why we should deliberately limit ourselves to that 
either, particularly since there's the potential for splitting this 
whole thing out into quite a few more groups (or bringing more things 
into the fold) later on if people decide it's worth it.

>>I agree with the global tagging thing, but I don't see why this much
>>effort has to be put into making everything ready concurrently just so
>>it can be rolled together.  Automatic coordination of this sort of thing
>>is part of what CVS (and in particular CVS tags) is supposed to be good for.
>>
> 
> "Making everything ready" just means "make sure it's not currently
> broken". This is exactly how we do things now, I don't think anything
> should change.


Except that you're going to get multiple semi-independent groups working 
on multiple internal timelines and all of a sudden you have to hold off 
the release of module A because module B's got a big problem that'll 
take a few days to fix, then by the time module B is fixed, module C has 
a problem, and when everything finally gets straightened out, something 
you could have gotten out the door in an hour has taken a week and a half.

>>It seems to me that each subproject should attempt to maintain at all
>>times a tag that says "current rollup-candidate", which isn't
>>necessarily the latest-and-greatest, but is the latest version that's
>>stable and without showstoppers.


[Actually, I should have said "it's a _recent_ version that's stable and 
without showstoppers".]

> I suggested this a while back - but after thinking about it some more I
> realised this just means extra work. Instead of tagging it once when the
> trumpet call is released, we must now update the latest-known-working
> tag every time we make a commit - yuck.


Umm, no.  All it means is that each group maintains its own release 
schedule, and updates its "releasable" tag appropriately for their 
schedule.  This doesn't have to be every commit, it could be every day, 
or every week, or whenever somebody feels like it (and it _can_ be that 
flexible, because each group doesn't have to drop everything and 
coordinate with everybody each time somebody wants to update things).

-alex

Re: Q1: Rollup Release Format - Score So Far...

[Graham Leggett <mi...@sharp.fm>]

Rodent of Unusual Size wrote:

> > But consensus has just been reached that there will be a
> > single rollup release, so out of necessity there will
> > have to be one version per release.
> 
> That is a consensus that was built quite quickly, so it
> is certainly non-binding if new data suggest it is not
> the best alternative.

This is true - but if we can't start agreeing to and sticking with
certain basic decisions about how the release will be issued then the
rollup release is never going to happen. So many times this discussion
has been started, but then it fragments into many little "what if we do
it completely differently" discussions and we're right back to where we
started.

As a result of this, mod_proxy - which was finished and ready for
testing almost six months ago - is still not getting the testing it
needs. At this stage if it's too hard to get the rollup release going
now with v2.0 trying to get out there, then we should just put proxy
back (as agreed before) and try sort out the rollup for v2.1.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: Q1: Rollup Release Format - Score So Far...

[Alex Stewart <al...@foogod.com>]

Rodent of Unusual Size wrote:

> Graham Leggett wrote:
> 
>>But consensus has just been reached that there will be a
>>single rollup release, so out of necessity there will
>>have to be one version per release.
>>
> 
> That is a consensus that was built quite quickly, so it
> is certainly non-binding if new data suggest it is not
> the best alternative.
> 

Just for clarification here, I would like to point out that I'm all in 
favor of the apparent consensus regarding the single rollup release, and 
nothing in my response was intended to change that in any way.

It had appeared that, given the consensus on the "what" (single rollup), 
people had started to move on to the "how" (CVS tagging and rollup 
procedures), and I was responding to some of the details of that topic.

My point was really that _given_ there's going to be a single rollup 
with a particular release number, that rollup release number doesn't 
necessarily have to be tied to the version numbers of the multiple 
components that are in it, and it might be easier if it wasn't.

Sorry if there was any confusion..

-alex

Re: Q1: Rollup Release Format - Score So Far...

[Rodent of Unusual Size <Ke...@Golux.Com>]

Graham Leggett wrote:
> 
> But consensus has just been reached that there will be a
> single rollup release, so out of necessity there will
> have to be one version per release.

That is a consensus that was built quite quickly, so it
is certainly non-binding if new data suggest it is not
the best alternative.
-- 
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist      http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: Q1: Rollup Release Format - Score So Far...

[Graham Leggett <mi...@sharp.fm>]

Alex Stewart wrote:

> There seems to be a big assumption here that "release" is the same as
> "version", which seems like an unnecessary restriction.
> 
> Frankly, if these are separate subprojects we're talking about (which it
> seems pretty clear they're going to be evolving into, if they aren't
> already), they should have separate, independent versioning.

But consensus has just been reached that there will be a single rollup
release, so out of necessity there will have to be one version per
release.

> Trying to
> coordinate the version numbers of umpteen different projects just
> because one of their possible distribution channels distributes them
> together is silly and a lot of unnecessary extra work.

We are currently coordinating three different projects (httpd-core, apr,
apr-util) being released together and things are working fine. I don't
see how expanding this to 4 or 5 is such a problem?

> I agree with the global tagging thing, but I don't see why this much
> effort has to be put into making everything ready concurrently just so
> it can be rolled together.  Automatic coordination of this sort of thing
> is part of what CVS (and in particular CVS tags) is supposed to be good for.

"Making everything ready" just means "make sure it's not currently
broken". This is exactly how we do things now, I don't think anything
should change.

> It seems to me that each subproject should attempt to maintain at all
> times a tag that says "current rollup-candidate", which isn't
> necessarily the latest-and-greatest, but is the latest version that's
> stable and without showstoppers.

I suggested this a while back - but after thinking about it some more I
realised this just means extra work. Instead of tagging it once when the
trumpet call is released, we must now update the latest-known-working
tag every time we make a commit - yuck.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: Q1: Rollup Release Format - Score So Far...

[Alex Stewart <al...@foogod.com>]

Graham Leggett wrote:

> mod_foo wants to make a release, so they release v2.0.45.1 of the rollup
> tree, containing 2.0.45 of core and 2.0.45.1 of mod_foo. But what about
> mod_bar and the other modules? Will their tags need to be bumped up to

> 2.0.45.1 also? I would imagine they would, which is a problem.


There seems to be a big assumption here that "release" is the same as 
"version", which seems like an unnecessary restriction.

Frankly, if these are separate subprojects we're talking about (which it 
seems pretty clear they're going to be evolving into, if they aren't 
already), they should have separate, independent versioning.  Trying to 
coordinate the version numbers of umpteen different projects just 
because one of their possible distribution channels distributes them 
together is silly and a lot of unnecessary extra work.  At the same 
time, saying that we can't have a specific bundle release number because 
all the contents have different versions is equally silly.  The bundle 
release number reflects the number of the bundle, not necessarily the 
version of any of the contents.

Well, ok, it makes sense that the rollup bundle of "httpd and friends" 
should reflect the version number of the httpd core that's in it (that's 
the one version number that most people on the outside would probably 
expect to be consistent).  It also makes sense that there may be 
incremental bundles released between httpd version changes, so a 
sub-release identifier of some sort is needed.  The number on the 
bundle, however, in no way has to have any relationship to any of the 
extra module version numbers:

For example, apache-httpd-complete-2.0.1-12.tar.gz might contain:
   httpd version 2.0.1 (obviously)
   mod_foo version 2.0.1
   mod_bar version 1.7
   mod_baz version 18.7.3

apache-httpd-complete-2.0.1-13.tar.gz could contain exactly the same 
thing, except mod_bar is now at version 1.8, or whatever.

Now, admittedly, you could do the same thing with a date stamp instead 
of a revision number, but for these purposes "12" works just as well as 
"20020423", and is arguably more readable/usable (for one thing, you can 
tell that "13" is the next release after "12", but who knows what 
"20020611" is).  Anyway, the filenames we're looking at using are 
getting long enough already, IMO.


> Ideally the rollup release should commence with an enormous trumpet
> call, followed by the tagging of *all* the modules (including core) with
> the same tag. At this point *all* modules (including core) have to fix
> any showstoppers, and a release follows shortly afterwards to testers.
> If the release works, woohoo - it's a release. If not, oh well, it's an
> alpha.


I agree with the global tagging thing, but I don't see why this much 
effort has to be put into making everything ready concurrently just so 
it can be rolled together.  Automatic coordination of this sort of thing 
is part of what CVS (and in particular CVS tags) is supposed to be good for.

It seems to me that each subproject should attempt to maintain at all 
times a tag that says "current rollup-candidate", which isn't 
necessarily the latest-and-greatest, but is the latest version that's 
stable and without showstoppers.  At any point in time (any day of any 
week) and with no special warning, somebody should ideally be able to 
pull from all the appropriate CVS sources using that tag and get 
something that's appropriate to be made into a rollup tarball.  When a 
subproject has an update worthy of a new rollup, they tag it with that 
tag in their tree, and ask whoever's in charge of rolling releases to do 
another run.  At that point, a general notice might go out just so that 
everyone can do a quick double-check that what's tagged in their 
repositories is the stuff they really want going out, and then it gets 
pulled and rolled.  No big fanfare or mad scrambling needed, though.

Anyway, that's my $.02..

-alex

Re: Q1: Rollup Release Format - Score So Far...

[Graham Leggett <mi...@sharp.fm>]

Cliff Woolley wrote:

> Subrevision numbers should do... either use 2.0.x's x value for this or
> use 2.0.x.y's y value if x is meant to match httpd-core 2.0.x's x, which
> it probably should.

I don't see how this will work.

mod_foo wants to make a release, so they release v2.0.45.1 of the rollup
tree, containing 2.0.45 of core and 2.0.45.1 of mod_foo. But what about
mod_bar and the other modules? Will their tags need to be bumped up to
2.0.45.1 also? I would imagine they would, which is a problem.

Ideally the rollup release should commence with an enormous trumpet
call, followed by the tagging of *all* the modules (including core) with
the same tag. At this point *all* modules (including core) have to fix
any showstoppers, and a release follows shortly afterwards to testers.
If the release works, woohoo - it's a release. If not, oh well, it's an
alpha.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: Q1: Rollup Release Format - Score So Far...

[Cliff Woolley <cl...@yahoo.com>]

On Wed, 19 Sep 2001, William A. Rowe, Jr. wrote:

> > I am +0 on httpd-2... and +1 on apache-httpd-2...
> >
> > btw, no dates in those either (a suggestion from otherbill). The version
> > number tells us what we need to know.
>
> Not if a module has released an incremental bugfix/securityfix between
> major core httpd releases, it doesn't.

Subrevision numbers should do... either use 2.0.x's x value for this or
use 2.0.x.y's y value if x is meant to match httpd-core 2.0.x's x, which
it probably should.

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA

Re: Q1: Rollup Release Format - Score So Far...

["William A. Rowe, Jr." <wr...@lnd.com>]

From: "Greg Stein" <gs...@lyra.org>
Sent: Wednesday, September 19, 2001 4:35 PM


> On Wed, Sep 19, 2001 at 04:32:12PM -0400, Joshua Slive wrote:
> 
> > But I think we also have concensus that the name shouldn't be "apache".
> > "apache-httpd-2.x.x.tar.gz" seems better.
> 
> Agreed.

That was my take on things, we made it *really* clear that this can't be
ambigious.

> I am +0 on httpd-2... and +1 on apache-httpd-2...
>
> btw, no dates in those either (a suggestion from otherbill). The version
> number tells us what we need to know.

Not if a module has released an incremental bugfix/securityfix between
major core httpd releases, it doesn't.

Re: Q1: Rollup Release Format - Score So Far...

[Greg Stein <gs...@lyra.org>]

On Wed, Sep 19, 2001 at 04:32:12PM -0400, Joshua Slive wrote:
> > -----Original Message-----
> > From: Graham Leggett [mailto:minfrin@sharp.fm]
> 
> > The winner seems to be that the Apache group releases a rollup release
> > with all (at least apr, apr-util, httpd-2.0, httpd-proxy, httpd-ldap)
> > the projects included, and that release is called "apache-2.x.x.tar.gz".
> > Am I right on this one?
> 
> I have no problem with that (although it seems that the only difference
> between this and what the group has always done is that everything lives in
> different cvs repositories).

Seems that way. We can have multiple CVS repositories and then make
decisions on which ones go into the rollup.

For example, we could include mod_proxy and mod_ldap repositories, but
exclude the mod_pop3 repository. And on into the future...

> But I think we also have concensus that the name shouldn't be "apache".
> "apache-httpd-2.x.x.tar.gz" seems better.

Agreed.

I am +0 on httpd-2... and +1 on apache-httpd-2...

btw, no dates in those either (a suggestion from otherbill). The version
number tells us what we need to know.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: Q1: Rollup Release Format - Score So Far...

[Graham Leggett <mi...@sharp.fm>]

Joshua Slive wrote:

> I have no problem with that (although it seems that the only difference
> between this and what the group has always done is that everything lives in
> different cvs repositories).
> But I think we also have concensus that the name shouldn't be "apache".
> "apache-httpd-2.x.x.tar.gz" seems better.

I think this is jumping the gun a little - question two can be "what
should it be called", in the meantime we need to decide whether we are
going to release a single file as a rollup release. (I made a mistake by
focusing on the name of the release, sorry)...

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

RE: Q1: Rollup Release Format - Score So Far...

[Joshua Slive <jo...@slive.ca>]

> -----Original Message-----
> From: Graham Leggett [mailto:minfrin@sharp.fm]

> The winner seems to be that the Apache group releases a rollup release
> with all (at least apr, apr-util, httpd-2.0, httpd-proxy, httpd-ldap)
> the projects included, and that release is called "apache-2.x.x.tar.gz".
> Am I right on this one?
>

I have no problem with that (although it seems that the only difference
between this and what the group has always done is that everything lives in
different cvs repositories).
But I think we also have concensus that the name shouldn't be "apache".
"apache-httpd-2.x.x.tar.gz" seems better.

Joshua.