You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2002/10/17 18:42:57 UTC
[Vote] 2.1 fork near ready?
Here's my current proposal...
1) Effective now, designate 2.0 as 'maintainence mode'. Apache 2.0
will always be based on APR 0.9 forever from here on forward, until
we care to port the next release to APR 1.0
2) Create an APACHE_2_0_BRANCH from 2.0.43 if this vote passes.
Then, once we feel 'ready',
a) Tag APACHE_2_1_rcworktag from HEAD.
b) Remove mpm/experimental and modules/experimental from
APACHE_2_1_rcworktag.
d) All developers, review their changes to cvs HEAD, and simply
move the tag APACHE_2_1_rcworktag to an appropriate revision
(or backout, then tag, then reapply the unsuited changes.)
e) New changes that are appropriate for a stable release may be
tagged with APACHE_2_1_rcworktag.
f) Any time during this process, someone may tag APACHE_2_2_n,
votes, and we release the first development release of the 2.1/2.2
family. This may help with the final steps below, putting especially
into 3rd party author's hands.
g) Just as soon as someone wants to go out on a limb, they tag
APACHE_2_1_0_RC1 from APACHE_2_1_rcworktag. Votes.
h) Just as soon as the vote is +1 for the latest APACHE_2_1_0_RC#,
someone goes out on a limb and tags that candidate APACHE_2_1_0
and the fun begins.
i) Create an APACHE_2_1_BRANCH from APACHE_2_1_0.
I really do expect 2.1 to look very much like CVS head today, sans any
radical new unfinished ideas. But the more we can get broken and fixed
the 'right way' now, the longer we will avoid the 2.1/2.2 -> 2.3/2.4 bump.
So rethink the module names and directives of the 'New Auth'. Did we
consider it all? Does ugliness remain that we will spend all of 2.1 griping
about? Now is the time to open mouth, insert foot and make it 'right'.
It won't change again for a good six months :-)
Finally, I don't think we want to release 2.1/2.2 until APR 1.0 locks them
into their versioning rules, do we? Hopefully that is _VERY_ near since
the debate on APR pretty much left the status as "let's deal with this
small handful of versioning issues and call it 1.0 already!"
What if we put the energy into calling APR 1.0 and Apache HTTP
Server 2.1 released at AC2002? Only a few weeks remain to make
that happen. But it certainly could. We have good code, but there is
some breakage (API names et al) to do before we have that coup.
Thoughts?
Bill
Re: [Vote] 2.1 fork near ready?
Posted by Jeff Stuart <js...@computer-city.net>.
On Thu, 2002-10-17 at 12:42, William A. Rowe, Jr. wrote:
> Here's my current proposal...
>
For what it's worth as an end user, my vote is +1. :)
--
Jeff Stuart <js...@computer-city.net>
Re: [Vote] 2.1 fork near ready?
Posted by Aaron Bannert <aa...@clove.org>.
On Thu, Oct 17, 2002 at 07:42:21PM +0200, Sander Striker wrote:
> Are we ready for this vote?
>
> I know I'm not. I'm still going through a pile of mail
> on this subject (as I'm sure others are aswell). Let's
> not (try to) push this through in a few days.
I'm not ready for this either (although I like the enthousiasm on this
list to address some of the issues around our versioning system)
> Yes I know this is going on a lot longer than a
> few days or even a few weeks, but still. Now there
> is discussion, let's not smother that with a vote.
>
>
> Sander 'who is frantically trying to find some time to catch up'
Same here. :)
-aaron
Re: [Vote] 2.1 fork near ready?
Posted by Thom May <th...@planetarytramp.net>.
* William A. Rowe, Jr. (wrowe@apache.org) wrote :
> At 02:22 PM 10/17/2002, Justin Erenkrantz wrote:
> > The one main suggestion I have to OtherBill's rules is that the stable
> > release tree of httpd should be under RTC not CTR. This ensures
> > deliberation on our parts for integrating items into the stable tree.
>
> I was laughing at calling the whole process CTRTC (commit to dev,
> review, then commit to stable.) Doesn't slow anyone down from fixing
> bits in dev. Then (preferably as a single unified patch after all the little
> bits settle down) post for vote to commit into stable. This simplifies
> review, as all the bits can be worked and debated for days, weeks,
> months, as they relate to one big change, without constantly asking
> for votes.
This idea sounds brilliant, and exactly what is needed.
+1
Cheers,
-Thom
--
Thom May -> thom@planetarytramp.net
< robster> SHIT
< robster> woody doesnt support devfs
< willy> devfs is FUcking Shit
< liiwi> willy: quick now! tell it to stop before it gets itself dirty!
RE: [Vote] 2.1 fork near ready?
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 02:22 PM 10/17/2002, Justin Erenkrantz wrote:
> The one main suggestion I have to OtherBill's rules is that the stable
> release tree of httpd should be under RTC not CTR. This ensures
> deliberation on our parts for integrating items into the stable tree.
I was laughing at calling the whole process CTRTC (commit to dev,
review, then commit to stable.) Doesn't slow anyone down from fixing
bits in dev. Then (preferably as a single unified patch after all the little
bits settle down) post for vote to commit into stable. This simplifies
review, as all the bits can be worked and debated for days, weeks,
months, as they relate to one big change, without constantly asking
for votes. Once the whole big change to dev is satisfactory to the
(multiple) authors, that can be incorporated in stable with one big
up/down vote.
It's procedural, and doesn't belong in our external 'ROADMAP'
picture for the world. Of course some platform-specifics from the
maintainers won't get the same scrutiny (although they should be
posted for comment) because some tiny corners have very few
folks actually participating in that code.
Bill
Re: [Vote] 2.1 fork near ready?
Posted by Henning Brauer <hb...@bsws.de>.
On Sun, Oct 20, 2002 at 11:09:06PM -0700, Ask Bjoern Hansen wrote:
> On Sun, 20 Oct 2002, Justin Erenkrantz wrote:
>
> > I'm not suggesting RTC on the -development tree - the guarantee of
> > stability isn't there, but I believe it is on -stable. We should
> > enforce a policy that reflects our desire of stability.
>
> In other projects I've seen RTC - in the name of stability - put
> such a damper on development that stable became "doesn't change, not
> even the old bugs" instead of "works really well".
yes, hmm?
we do RTC for ALL branches in OpenBSD. or really TRTC.
Re: [Vote] 2.1 fork near ready?
Posted by Aaron Bannert <aa...@clove.org>.
On Sun, Oct 20, 2002 at 03:58:00PM -0700, Justin Erenkrantz wrote:
> --On Sunday, October 20, 2002 3:20 PM -0700 Aaron Bannert
> <aa...@clove.org> wrote:
>
> >I think this whole RTC vs. CTR debate is moot at this point. We all
> >trust each other not to mess up the repositories too much, and we
> >all hold code-level veto power over any commit (with technical
> >justification). Given that, I see no reason to put arbitrary
> >roadblocks in front of our trusted committers.
>
> Even with the best of intentions, people can unknowningly break the
> tree. It happens - we're human. By enforcing a policy that mandates
> prior peer review, we would ensure the integrity of the stable tree
> to the best of our ability.
Exactly. CVS commit emails are good enough peer review for me.
> One of OtherBill's stated goals was to ensure a level of stability at
> all times in the stable tree. Unless we follow RTC rules, I don't
> believe we can guarantee that stability.
I don't believe any complex piece of software in the world can ever make
such a definately guarantee, and surely by reading the Apache License one
would get the impression that the ASF does not make those kinds of claims
as a matter of policy. All we can say is that this release is probably
more stable (and has been in our own subjective opinion) than the last.
The difference between branches marked "stable" and "development" is
not the same as "it probably works" and "it probably doesn't work". The
difference is in how we as committers feel about what kinds of changes
are appropriate to make in each repository. I believe that only bug
fixes belong in the stable tree, while feature additions belong in the
development branch.
> I'm not suggesting RTC on the -development tree - the guarantee of
> stability isn't there, but I believe it is on -stable. We should
> enforce a policy that reflects our desire of stability. -- justin
I'm saying -1 to RTC ever in any openly democratic and strongly
peer-reviewed ASF project.
-aaron
p.s. I don't consider this to be a vetoable choice, -1 just reflects my
opposition. :)
Re: [Vote] 2.1 fork near ready?
Posted by Ask Bjoern Hansen <as...@develooper.com>.
On Sun, 20 Oct 2002, Justin Erenkrantz wrote:
> I'm not suggesting RTC on the -development tree - the guarantee of
> stability isn't there, but I believe it is on -stable. We should
> enforce a policy that reflects our desire of stability.
In other projects I've seen RTC - in the name of stability - put
such a damper on development that stable became "doesn't change, not
even the old bugs" instead of "works really well".
- ask
--
ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: [Vote] 2.1 fork near ready?
Posted by Justin Erenkrantz <je...@apache.org>.
--On Sunday, October 20, 2002 3:20 PM -0700 Aaron Bannert
<aa...@clove.org> wrote:
> I think this whole RTC vs. CTR debate is moot at this point. We all
> trust each other not to mess up the repositories too much, and we
> all hold code-level veto power over any commit (with technical
> justification). Given that, I see no reason to put arbitrary
> roadblocks in front of our trusted committers.
Even with the best of intentions, people can unknowningly break the
tree. It happens - we're human. By enforcing a policy that mandates
prior peer review, we would ensure the integrity of the stable tree
to the best of our ability.
One of OtherBill's stated goals was to ensure a level of stability at
all times in the stable tree. Unless we follow RTC rules, I don't
believe we can guarantee that stability.
I'm not suggesting RTC on the -development tree - the guarantee of
stability isn't there, but I believe it is on -stable. We should
enforce a policy that reflects our desire of stability. -- justin
Re: [Vote] 2.1 fork near ready?
Posted by Aaron Bannert <aa...@clove.org>.
On Thu, Oct 17, 2002 at 12:22:54PM -0700, Justin Erenkrantz wrote:
> ...
> The one main suggestion I have to OtherBill's rules is that the
> stable release tree of httpd should be under RTC not CTR. This
> ensures deliberation on our parts for integrating items into the
> stable tree.
I think this whole RTC vs. CTR debate is moot at this point. We all trust
each other not to mess up the repositories too much, and we all hold
code-level veto power over any commit (with technical justification).
Given that, I see no reason to put arbitrary roadblocks in front of our
trusted committers.
-aaron
RE: [Vote] 2.1 fork near ready?
Posted by Justin Erenkrantz <je...@apache.org>.
--On Thursday, October 17, 2002 7:42 PM +0200 Sander Striker
<st...@apache.org> wrote:
> Are we ready for this vote?
>
> I know I'm not. I'm still going through a pile of mail
> on this subject (as I'm sure others are aswell). Let's
> not (try to) push this through in a few days.
>
> Yes I know this is going on a lot longer than a
> few days or even a few weeks, but still. Now there
> is discussion, let's not smother that with a vote.
Agreed. I'm swamped with stuff right now. Hopefully will have time
this weekend. But, I'd also prefer to let some of these ideas kick
around in my head for a few days. These are fairly fundamental
changes in how we work - a few days to ponder is fair, I think.
Could we please add OtherBill's ROADMAP to CVS so we can collaborate
on the precise wording (don't call it roadmap - how about
VERSIONING)? And, that way, we all agree what the current wording
is. Oooooh, OtherBill already did that. Cool. But, I still say
that it should be separated from the long-term task items...
I'd prefer that we do a up/down vote on the version rules. Then, we
can determine how far we are from creating a stable release. I'd
rather not mix the two. But, agree upon the rules first.
I agree that I think we could have an APR 1.0/httpd 2.1 in a month.
We're close. How close? I'm not sure. Depending if we can light a
fire under our butts to nail the versioning implementation of APR and
separate the build system of apr and apr-util (Roy mumbled about the
fact that he could do this easily).
The one main suggestion I have to OtherBill's rules is that the
stable release tree of httpd should be under RTC not CTR. This
ensures deliberation on our parts for integrating items into the
stable tree.
Off to write some papers for a bit... -- justin
RE: [Vote] 2.1 fork near ready?
Posted by Sander Striker <st...@apache.org>.
Are we ready for this vote?
I know I'm not. I'm still going through a pile of mail
on this subject (as I'm sure others are aswell). Let's
not (try to) push this through in a few days.
Yes I know this is going on a lot longer than a
few days or even a few weeks, but still. Now there
is discussion, let's not smother that with a vote.
Sander 'who is frantically trying to find some time to catch up'