You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by wr...@apache.org on 2002/11/23 20:15:29 UTC
cvs commit: httpd-2.0 STATUS ROADMAP
wrowe 2002/11/23 11:15:29
Modified: . Tag: APACHE_2_0_BRANCH STATUS
Removed: . Tag: APACHE_2_0_BRANCH ROADMAP
Log:
The roadmap means nothing in the 2_0 branch ... let's maintain it on the
sandbox branch alone. Fix some notes in STATUS and remove or warn against
some changes for the lifetime of 2.0.
Revision Changes Path
No revision
No revision
1.751.2.1 +33 -60 httpd-2.0/STATUS
Index: STATUS
===================================================================
RCS file: /home/cvs/httpd-2.0/STATUS,v
retrieving revision 1.751
retrieving revision 1.751.2.1
diff -u -r1.751 -r1.751.2.1
--- STATUS 21 Nov 2002 17:03:40 -0000 1.751
+++ STATUS 23 Nov 2002 19:15:28 -0000 1.751.2.1
@@ -53,54 +53,34 @@
Contributors looking for a mission:
- * just do an egrep on "TODO" and see what's there
-
+ * just do an egrep on "TODO", "XXX" and see what's there
CURRENT RELEASE NOTES:
+ * This branch is operating under R-T-C guidelines.
+
+ * Backwards compatibility is expected of future Apache 2.0 releases,
+ such that no MMN major number changes will occur until 2.1.
+
+ * The current sandbox (cvs HEAD) operating under C-T-R guidelines
+ is version 2.1-dev.
+
+ * All commits to APACHE_2_0_BRANCH must be reflected in cvs HEAD
+ as well, if they apply. Logical progression is commit to HEAD,
+ get feedback (3 +1's) and then commit to APACHE_2_0_BRANCH.
+
+ * The 'modules/experimental' tree will evaporate soon. Anything
+ in the development branch should be located under it's eventual
+ home (such as modules/cache/.)
RELEASE SHOWSTOPPERS:
+ * The Auth module overhaul of module names and directives need to
+ be reverted to their 2.0.43 names. The new hooks remain.
CURRENT VOTES:
- * Adopt backwards compatibility for future Apache 2.0 releases
- such that MMN major number changes and eliminating non-experimental
- modules are deferred for the next minor version bump (e.g. 2.1, 2.2
- or 3.0).
- +1: wrowe, jerenkrantz, aaron, brianp, trawick, stoddard, jwoolley,
- rbowen, rederpj, jim, striker
- 0:
- -1:
-
- * Defer the Auth module overhaul to the next minor version bump
- (e.g. 2.1, 2.2, 3.0) on the condition that forward compatibility
- resolution is adopted.
- +1: wrowe, aaron, trawick, stoddard, jwoolley, rbowen, gregames,
- rederpj, jim
- 0: jerenkrantz
- -1: striker
-
- * Adopt an even/odd release paradigm (see VERSIONING) such that
- even numbered releases are stable, and odd numbered releases
- are development efforts, keeping in the tradition of Linux,
- Perl, etc. In pratical terms, this implies C-T-R-T-C, where
- patches are (generally) first applied to the development branch,
- tested, and then (after vote) applied to the stable branch.
- +1: wrowe, jerenkrantz, aaron, trawick, stoddard, jwoolley, rbowen,
- gregames, rederpj, jim, striker
- 0:
- -1:
-
- * Branch APACHE_2_0_BRANCH today, changing the version in CVS HEAD
- to 2.1.0-dev.
- +1 [from APACHE_2_0_43]: wrowe, aaron, trawick, stoddard, jwoolley,
- gregames, rederpj, jim
- +1 [from HEAD]: striker
- 0: jerenkrantz
- -1:
-
- * httpd-std.conf and friends
+ * httpd-std.conf and friends;
a) httpd-std.conf should be tailored by install (from src or
binbuild) even if user has existing httpd.conf
@@ -143,10 +123,10 @@
something useful?)
* Make the worker MPM the default MPM for threaded Unix boxes.
- +1: Justin, Ian, Cliff, BillS, striker, wrowe
+ +1: Justin, Ian, Cliff, BillS, striker
+0: BrianP, Aaron (mutex contention is looking better with the
latest code, let's continue tuning and testing), rederpj, jim
- -0: Lars
+ -0: Lars, wrowe (let's make this defacto for the 2.2 release.)
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
@@ -166,7 +146,7 @@
* pipes deadlock on all platforms with limited pipe buffers (e.g. both
Linux and Win32, as opposed to only Win32 on 1.3). The right solution
is either GStein's proposal for a "CGI Brigade", or OtherBill's proposal
- for "Poll Buckets" for "Polling Filter Chains".
+ for "Poll Buckets" for "Polling Filter Chains". Or perhaps both :-)
* All handlers should always send content down even if r->header_only
is set. If not, it means that the HEAD requests don't generate the
@@ -295,6 +275,12 @@
sequence causes the request to fail! This happens notably in
the ja-jis encoding.
+ OtherBill is -0.5 for even considering this until 2.2 because
+ it removes some protection we provided to third party modules
+ that would mysteriously 'evaporate', exposing potential holes
+ in security. Putting this change into 2.1 development now (with
+ strong warnings!) will give authors a chance to vet their code.
+
* FreeBSD, threads, and worker MPM. All seems to work fine
if you only have one worker process with many threads. Add
a second worker process and the accept lock seems to be
@@ -348,17 +334,6 @@
to both parent and child for writing. Then we just need to
figure out how to do graceless on non-threaded MPMs.
- * Allow the DocumentRoot directive within <Location > scopes? This
- allows the beloved (crusty) Alias /foo/ /somepath/foo/ followed
- by a <Directory /somepath/foo> to become simply
- <Location /foo/> DocumentRoot /somefile/foo (IMHO a bit more legible
- and in-your-face.) DocumentRoot unset would be accepted [and would
- not permit content to be served, only virtual resources such as
- server-info or server-status.
- This proposed change would _not_ depricate Alias.
- striker: See the thread starting with Message-ID:
- JLEGKKNELMHCJPNMOKHOGEEJFBAA.striker@apache.org.
-
* Win32: Rotatelogs sometimes is not terminated when Apache
goes down hard. FirstBill was looking at possibly tracking the
child's-child processes in the parent process.
@@ -373,12 +348,6 @@
* Combine log_child and piped_log_spawn. Clean up http_log.c.
Common logging API.
- * Document mod_file_cache.
-
- * Platforms that do not support fork (primarily Win32 and AS/400)
- Architect start-up code that avoids initializing all the modules
- in the parent process on platforms that do not support fork.
-
* Win32: Migrate the MPM over to use APR thread/process calls. This
would eliminate some code in the Win32 branch that essentially
duplicates what is in APR.
@@ -418,6 +387,10 @@
ap_sort_hooks() [to reduce the logic in main()]
* read the config tree just once, and process N times (as necessary)
+ OtherBill adds that the 'good' solution of three passes against the
+ config tree within one read is the better solution, but breaks many
+ modules. Best left for 2.2?
+ -0.5: OtherBill
* (possibly) use UUIDs in mod_unique_id and/or mod_usertrack
Re: Review then Commit discussion
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Nov 23, 2002 at 04:43:27PM -0800, Aaron Bannert wrote:
> On Saturday, November 23, 2002, at 03:33 PM, Henning Brauer wrote:
> > On Sat, Nov 23, 2002 at 02:19:35PM -0800, Aaron Bannert wrote:
> >> What will R-T-C give us that we don't already have right now?
> >
> > code quality...
> >
> > really, this isn't meant as flame. There's enough room for code quality
> > increase, and with C-T-R you will not get it.
> >
> > the analogy for our stable maintainers is most probably your RM.
> > so after you've done a release in the 2.0 branch, you select a RM for
> > the
> > next release, who then is 2.0 branch maintainer until next release.
>
> I simply do not believe that code quality in httpd will be improved
> by a R-T-C policy, and I have seen nothing to disprove this belief.
>
> To the contrary, I believe that by placing more speedbumps on the
> path between patch and commit, we have a possibility to reduce
> quality. In C-T-R a patch can be tested simply by running a "cvs up",
> recompiling, and rerunning. In the proposed R-T-C, a committer
> must first acquire the patch and apply it before they can even start
> testing.
>
> We have a revision control system, use it!
Right. RTC is just a mechanism to slow down the things that are right. As
Aaron pointed out, we *are* adults. We know what should be committed to the
stable branch, and what shouldn't. We know what should only go onto the dev
branch.
We do that today w.r.t Apache 2.0 and Apache 1.3. The problem is that there
isn't an outlet for rapid advance of the 2.x series, so 2.0 gets the churn
even while we're trying to be stable. Apache 1.3 is nice and stable because
people can "play" elsewhere. We need to play somewhere besides the 2.0
stable branch.
Call 2.0 stable and create a 2.1 dev area. The developers will take the
changes to the right location. Trust them to do that. Don't impose rules --
those do nothing put piss off a properly functioning dev community.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Review then Commit discussion
Posted by Aaron Bannert <aa...@clove.org>.
On Saturday, November 23, 2002, at 03:33 PM, Henning Brauer wrote:
> On Sat, Nov 23, 2002 at 02:19:35PM -0800, Aaron Bannert wrote:
>> What will R-T-C give us that we don't already have right now?
>
> code quality...
>
> really, this isn't meant as flame. There's enough room for code quality
> increase, and with C-T-R you will not get it.
>
> the analogy for our stable maintainers is most probably your RM.
> so after you've done a release in the 2.0 branch, you select a RM for
> the
> next release, who then is 2.0 branch maintainer until next release.
I simply do not believe that code quality in httpd will be improved
by a R-T-C policy, and I have seen nothing to disprove this belief.
To the contrary, I believe that by placing more speedbumps on the
path between patch and commit, we have a possibility to reduce
quality. In C-T-R a patch can be tested simply by running a "cvs up",
recompiling, and rerunning. In the proposed R-T-C, a committer
must first acquire the patch and apply it before they can even start
testing.
We have a revision control system, use it!
-aaron
Re: Review then Commit discussion
Posted by Henning Brauer <hb...@bsws.de>.
On Sat, Nov 23, 2002 at 02:19:35PM -0800, Aaron Bannert wrote:
> What will R-T-C give us that we don't already have right now?
code quality...
really, this isn't meant as flame. There's enough room for code quality
increase, and with C-T-R you will not get it.
the analogy for our stable maintainers is most probably your RM.
so after you've done a release in the 2.0 branch, you select a RM for the
next release, who then is 2.0 branch maintainer until next release.
--
Henning Brauer, BS Web Services, http://bsws.de
hb@bsws.de - henning@openbsd.org
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)
Re: Review then Commit discussion
Posted by Jeff Trawick <tr...@attglobal.net>.
Aaron Bannert <aa...@clove.org> writes:
> On Saturday, November 23, 2002, at 02:08 PM, Henning Brauer wrote:
>
> > On Sat, Nov 23, 2002 at 03:44:48PM -0600, William A. Rowe, Jr. wrote:
> >> FWIW I agree with Jeff here. I retracted the statement since JimJ,
> >> Cliff and Aaron all seem to want to err on the side of C-T-R.
> >>
> >> So count this
> >>
> >> R-T-C: Jeff, Will
> >> C-T-R: JimJ, Cliff, Aaron
> >>
> >> More voices are always welcome.
> >
> > I don't get your problem with R-T-C. we're doing so for all branches in
> > OpenBSD. our stable branches have maintainers, so if someone fixes a
> > bug he
> > thinks should go to stable he sends it to the stable maintainer and he
> > checks again before commiting. I do not see any developent slowdown
> > due to
> > R-T-C, but just a quality improvement.
>
> We don't have any concept of code ownership within httpd, and therefore
> can't have official "maintainers" of portions of httpd.
substitute "anybody interested in looking over code for inclusion in
the stable tree" for "stable maintainer"
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: Review then Commit discussion
Posted by Aaron Bannert <aa...@clove.org>.
On Saturday, November 23, 2002, at 02:08 PM, Henning Brauer wrote:
> On Sat, Nov 23, 2002 at 03:44:48PM -0600, William A. Rowe, Jr. wrote:
>> FWIW I agree with Jeff here. I retracted the statement since JimJ,
>> Cliff and Aaron all seem to want to err on the side of C-T-R.
>>
>> So count this
>>
>> R-T-C: Jeff, Will
>> C-T-R: JimJ, Cliff, Aaron
>>
>> More voices are always welcome.
>
> I don't get your problem with R-T-C. we're doing so for all branches in
> OpenBSD. our stable branches have maintainers, so if someone fixes a
> bug he
> thinks should go to stable he sends it to the stable maintainer and he
> checks again before commiting. I do not see any developent slowdown
> due to
> R-T-C, but just a quality improvement.
We don't have any concept of code ownership within httpd, and therefore
can't have official "maintainers" of portions of httpd. If we
had more strict responsibilities, then R-T-C might work the way
you have described it above.
What will R-T-C give us that we don't already have right now?
-aaron
Re: Review then Commit discussion
Posted by Henning Brauer <hb...@bsws.de>.
On Sat, Nov 23, 2002 at 03:44:48PM -0600, William A. Rowe, Jr. wrote:
> FWIW I agree with Jeff here. I retracted the statement since JimJ,
> Cliff and Aaron all seem to want to err on the side of C-T-R.
>
> So count this
>
> R-T-C: Jeff, Will
> C-T-R: JimJ, Cliff, Aaron
>
> More voices are always welcome.
I don't get your problem with R-T-C. we're doing so for all branches in
OpenBSD. our stable branches have maintainers, so if someone fixes a bug he
thinks should go to stable he sends it to the stable maintainer and he
checks again before commiting. I do not see any developent slowdown due to
R-T-C, but just a quality improvement.
--
Henning Brauer, BS Web Services, http://bsws.de
hb@bsws.de - henning@openbsd.org
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)
Review then Commit discussion
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 03:01 PM 11/23/2002, Jeff Trawick wrote:
>"William A. Rowe, Jr." <wr...@apache.org> writes:
>
>> At 01:25 PM 11/23/2002, Aaron Bannert wrote:
>>
>> >On Saturday, November 23, 2002, at 11:15 AM, wrowe@apache.org wrote:
>> >> CURRENT RELEASE NOTES:
>> >>
>> >> + * This branch is operating under R-T-C guidelines.
>> >
>> >Huh? No way. We're all adults here. If someone commits something
>> >that you are uncomfortable with, bring it up on the list. There's
>> >no reason for any ASF project to be R-T-C, IMHO. Our voting
>> >rules are sufficient enough to protect against bogus commits to
>> >stable or "maintenance" trees.
>>
>> One 'advantage' of R-T-C is eliminating the 'last minute breakage'
>> of trees as we approach releases. I understand that most httpd'ers
>> haven't operated under R-T-C for a very long time, we enjoy treating
>> cvs as a sandbox for rapid development.
>>
>> I think Jeff's original appeal for some known, stable branch (he actually
>> asked for 2.0.43.xxx in perpetutity) was that the release should not be
>> the sandbox for new ideas.
>>
>> But I was only interpreting other's comments, committers, how do you
>> feel about this policy? Should we operate C-T-R on 2_0_BRANCH?
>> Aaron, if you like, put this to a vote in 2_0_BRANCH'es STATUS.
>
>I think that R-T-C is the most likely way we'll get good reviews of
>code moved to the stable tree. I don't see that it is a big burden
>that several people have to actually agree with the purpose and
>implementation of the patch. It is very important to avoid the burden
>on ourselves and the user community when the occasional patch turns
>out to be a bad idea.
>
>The R in C-T-R is often a skim of the change. Not so rarely, C-T-R is
>C-T-something-screws-up-T-R :) That's okay with dev, where most
>people want to travel light and move fast, but that's not okay with
>stable (well, if you want to provide a very stable tree to our users
>with a minimum of debugging work).
>
>The problem we'll likely have with R-T-C is that people are out of
>practice on the R part and sometimes we'll have to nag. But I think
>that is better than an occasionally-disrupted stable tree. And people
>who want to get fixes into the stable tree will be motivated to give
>good feedback to colleagues with similar goals.
FWIW I agree with Jeff here. I retracted the statement since JimJ,
Cliff and Aaron all seem to want to err on the side of C-T-R.
So count this
R-T-C: Jeff, Will
C-T-R: JimJ, Cliff, Aaron
More voices are always welcome.
Bill
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Posted by David Reid <dr...@jetnet.co.uk>.
Whoops...not enough sleep :) That should read as R-T-C not C-T-R...
I also tend to think this should be applied to the 1.3 tree.
david
----- Original Message -----
From: "David Reid" <dr...@jetnet.co.uk>
To: <de...@httpd.apache.org>
Sent: Sunday, November 24, 2002 8:36 PM
Subject: Re: cvs commit: httpd-2.0 STATUS ROADMAP
> Given the recent behavior of some I'm actually now in favour of C-T-R for
> any stable tree...
>
> Treat adults as adults until they prove they can't be so treated.
>
> +1 for C_T_R for stable branches
>
> david
>
> ----- Original Message -----
> From: "Jeff Trawick" <tr...@attglobal.net>
> To: <de...@httpd.apache.org>
> Sent: Sunday, November 24, 2002 2:20 PM
> Subject: Re: cvs commit: httpd-2.0 STATUS ROADMAP
>
>
> > "Bill Stoddard" <bi...@wstoddard.com> writes:
> >
> > > > I think that R-T-C is the most likely way we'll get good reviews of
> > > > code moved to the stable tree.
> > >
> > > Jeff is speaking from his experience with 2.0 development and I would
> have to
> > > agree with him in this regard.
> >
> > I believe that our experiences with 2.0 development (and recent 1.3
> > maintenance) are indicative of what is going to happen with
> > 2.0-stable, or at least much more so than any experiences from several
> > years ago.
> >
> > Obviously the interpretation of that experience is subject to debate :)
> >
> > --/--
> >
> > Everybody has their own vision and we have to find the greatest
> > commonality to decide how to work. Here are some aspects of mine:
> >
> > . 1.3 maintenance needs to be a bit healthier... more involvement of
> > people when somebody wants to fix something... right now it can be
> > hard to get anybody to give a shit when you want to fix
> > something...
> >
> > . 2.0-stable maintenance along the lines of 1.3, but I think that
> > fixing things in 2.0-stable is much more important than fixing
> > things in 1.3.. 2.0-stable maintenance right now is for the
> > relatively few who try 2.x before the hoped-for avalanche, and
> > fixing their problems is going to prevent a world of hurt later on
> > (1.3 clearly works well-enough for almost anybody)
> >
> > . 2.1... just like what has happened with 2.0 thus far...
> >
> > This has nothing to do with C-T-R vs. R-T-C; that is just a choice of
> > which crude tool can best be used to achieve a goal.
> >
> > One of the useful properties of R-T-C is that if you don't have enough
> > interest to keep a tree maintained in a healthy manner it becomes
> > painfully obvious almost immediately.
> >
> > --
> > Jeff Trawick | trawick@attglobal.net
> > Born in Roswell... married an alien...
> >
>
>
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Posted by Aaron Bannert <aa...@clove.org>.
[assuming you meant R-T-C]
I don't know of any recent violations of our implied rules [in httpd];
when has this ever been a problem?
-aaron
On Sunday, November 24, 2002, at 12:36 PM, David Reid wrote:
> Given the recent behavior of some I'm actually now in favour of C-T-R
> for
> any stable tree...
>
> Treat adults as adults until they prove they can't be so treated.
>
> +1 for C_T_R for stable branches
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Posted by David Reid <dr...@jetnet.co.uk>.
Given the recent behavior of some I'm actually now in favour of C-T-R for
any stable tree...
Treat adults as adults until they prove they can't be so treated.
+1 for C_T_R for stable branches
david
----- Original Message -----
From: "Jeff Trawick" <tr...@attglobal.net>
To: <de...@httpd.apache.org>
Sent: Sunday, November 24, 2002 2:20 PM
Subject: Re: cvs commit: httpd-2.0 STATUS ROADMAP
> "Bill Stoddard" <bi...@wstoddard.com> writes:
>
> > > I think that R-T-C is the most likely way we'll get good reviews of
> > > code moved to the stable tree.
> >
> > Jeff is speaking from his experience with 2.0 development and I would
have to
> > agree with him in this regard.
>
> I believe that our experiences with 2.0 development (and recent 1.3
> maintenance) are indicative of what is going to happen with
> 2.0-stable, or at least much more so than any experiences from several
> years ago.
>
> Obviously the interpretation of that experience is subject to debate :)
>
> --/--
>
> Everybody has their own vision and we have to find the greatest
> commonality to decide how to work. Here are some aspects of mine:
>
> . 1.3 maintenance needs to be a bit healthier... more involvement of
> people when somebody wants to fix something... right now it can be
> hard to get anybody to give a shit when you want to fix
> something...
>
> . 2.0-stable maintenance along the lines of 1.3, but I think that
> fixing things in 2.0-stable is much more important than fixing
> things in 1.3.. 2.0-stable maintenance right now is for the
> relatively few who try 2.x before the hoped-for avalanche, and
> fixing their problems is going to prevent a world of hurt later on
> (1.3 clearly works well-enough for almost anybody)
>
> . 2.1... just like what has happened with 2.0 thus far...
>
> This has nothing to do with C-T-R vs. R-T-C; that is just a choice of
> which crude tool can best be used to achieve a goal.
>
> One of the useful properties of R-T-C is that if you don't have enough
> interest to keep a tree maintained in a healthy manner it becomes
> painfully obvious almost immediately.
>
> --
> Jeff Trawick | trawick@attglobal.net
> Born in Roswell... married an alien...
>
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Posted by Jeff Trawick <tr...@attglobal.net>.
"Bill Stoddard" <bi...@wstoddard.com> writes:
> > I think that R-T-C is the most likely way we'll get good reviews of
> > code moved to the stable tree.
>
> Jeff is speaking from his experience with 2.0 development and I would have to
> agree with him in this regard.
I believe that our experiences with 2.0 development (and recent 1.3
maintenance) are indicative of what is going to happen with
2.0-stable, or at least much more so than any experiences from several
years ago.
Obviously the interpretation of that experience is subject to debate :)
--/--
Everybody has their own vision and we have to find the greatest
commonality to decide how to work. Here are some aspects of mine:
. 1.3 maintenance needs to be a bit healthier... more involvement of
people when somebody wants to fix something... right now it can be
hard to get anybody to give a shit when you want to fix
something...
. 2.0-stable maintenance along the lines of 1.3, but I think that
fixing things in 2.0-stable is much more important than fixing
things in 1.3.. 2.0-stable maintenance right now is for the
relatively few who try 2.x before the hoped-for avalanche, and
fixing their problems is going to prevent a world of hurt later on
(1.3 clearly works well-enough for almost anybody)
. 2.1... just like what has happened with 2.0 thus far...
This has nothing to do with C-T-R vs. R-T-C; that is just a choice of
which crude tool can best be used to achieve a goal.
One of the useful properties of R-T-C is that if you don't have enough
interest to keep a tree maintained in a healthy manner it becomes
painfully obvious almost immediately.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
RE: cvs commit: httpd-2.0 STATUS ROADMAP
Posted by Bill Stoddard <bi...@wstoddard.com>.
> I think that R-T-C is the most likely way we'll get good reviews of
> code moved to the stable tree.
Jeff is speaking from his experience with 2.0 development and I would have to
agree with him in this regard. However, I think it is possible to maintain CTR
and ask committers to be more conservative in what they commit to the tree
before reviewing it on the dev list first. That's how we ran the entire 1.3
development (I join about 1.3b1 time). By comparison, 2.0 (and recent 1.3)
development has been sloppy.
Bill
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Posted by Jeff Trawick <tr...@attglobal.net>.
"William A. Rowe, Jr." <wr...@apache.org> writes:
> At 01:25 PM 11/23/2002, Aaron Bannert wrote:
>
> >On Saturday, November 23, 2002, at 11:15 AM, wrowe@apache.org wrote:
> >> CURRENT RELEASE NOTES:
> >>
> >> + * This branch is operating under R-T-C guidelines.
> >
> >Huh? No way. We're all adults here. If someone commits something
> >that you are uncomfortable with, bring it up on the list. There's
> >no reason for any ASF project to be R-T-C, IMHO. Our voting
> >rules are sufficient enough to protect against bogus commits to
> >stable or "maintenance" trees.
>
> One 'advantage' of R-T-C is eliminating the 'last minute breakage'
> of trees as we approach releases. I understand that most httpd'ers
> haven't operated under R-T-C for a very long time, we enjoy treating
> cvs as a sandbox for rapid development.
>
> I think Jeff's original appeal for some known, stable branch (he actually
> asked for 2.0.43.xxx in perpetutity) was that the release should not be
> the sandbox for new ideas.
>
> But I was only interpreting other's comments, committers, how do you
> feel about this policy? Should we operate C-T-R on 2_0_BRANCH?
> Aaron, if you like, put this to a vote in 2_0_BRANCH'es STATUS.
I think that R-T-C is the most likely way we'll get good reviews of
code moved to the stable tree. I don't see that it is a big burden
that several people have to actually agree with the purpose and
implementation of the patch. It is very important to avoid the burden
on ourselves and the user community when the occasional patch turns
out to be a bad idea.
The R in C-T-R is often a skim of the change. Not so rarely, C-T-R is
C-T-something-screws-up-T-R :) That's okay with dev, where most
people want to travel light and move fast, but that's not okay with
stable (well, if you want to provide a very stable tree to our users
with a minimum of debugging work).
The problem we'll likely have with R-T-C is that people are out of
practice on the R part and sometimes we'll have to nag. But I think
that is better than an occasionally-disrupted stable tree. And people
who want to get fixes into the stable tree will be motivated to give
good feedback to colleagues with similar goals.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 02:43 PM 11/23/2002, Jim Jagielski wrote:
>My own POV is that a R-T-C on 2.0 will almost ensure a very slow
>development environ on that effort. We haven't felt the need
>to do so with 1.3, so, unless the idea is that: (1) no one will
>be looking at 2.0 compared to 2.1 and therefore c-t-r is a noop
>or (2) we don't want a heathly development environ on 2.0. Neither
>option fills me with happy and warm thoughts :)
It's my understanding that 1.3 does operate on R-T-C. Correct me
if I'm wrong (a pointer to a final determination would be nice.)
Bill
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Posted by Aaron Bannert <aa...@clove.org>.
On Saturday, November 23, 2002, at 11:51 AM, William A. Rowe, Jr.
wrote:
> At 01:25 PM 11/23/2002, Aaron Bannert wrote:
>
>> On Saturday, November 23, 2002, at 11:15 AM, wrowe@apache.org wrote:
>>> CURRENT RELEASE NOTES:
>>>
>>> + * This branch is operating under R-T-C guidelines.
>>
>> Huh? No way. We're all adults here. If someone commits something
>> that you are uncomfortable with, bring it up on the list. There's
>> no reason for any ASF project to be R-T-C, IMHO. Our voting
>> rules are sufficient enough to protect against bogus commits to
>> stable or "maintenance" trees.
>
> One 'advantage' of R-T-C is eliminating the 'last minute breakage'
> of trees as we approach releases. I understand that most httpd'ers
> haven't operated under R-T-C for a very long time, we enjoy treating
> cvs as a sandbox for rapid development.
It is up to the release manager to decide what goes in to their
own release. If they want to take something that was just committed,
then that's their choice. R-T-C may improve that, but only as
a side-effect of a more global slowing down of commits.
> I think Jeff's original appeal for some known, stable branch (he
> actually
> asked for 2.0.43.xxx in perpetutity) was that the release should not be
> the sandbox for new ideas.
+1
> But I was only interpreting other's comments, committers, how do you
> feel about this policy? Should we operate C-T-R on 2_0_BRANCH?
> Aaron, if you like, put this to a vote in 2_0_BRANCH'es STATUS.
Let's discuss this a little more, I'm curious what others think. Is
there really a problem now with people committing things that shouldn't
be committed? Take the 1.3 branch for example.
Lets put this another way. Why would we want to stop anyone from
volunteering
wherever they wanted?
>
> + * The 'modules/experimental' tree will evaporate soon. Anything
>>> + in the development branch should be located under it's
>>> eventual
>>> + home (such as modules/cache/.)
>>
>> There's no reason to remove this from the 2.0 releases. They are
>> experimental
>> not matter way, and if someone grabs a 2.0 tarball and wants to start
>> hacking on experimental stuff, all the better!
>
> I'm taking this from the vote. Again, if you want to phrase this very
> specific
> issue as a vote (in 2_0_BRANCH'es STATUS) I sure won't object.
Again, let's discuss this a little more before we jump to vote. Does
anyone
really see a reason to remove this? I'm just thinking that they are
marked
very explicitly as "experimental", and so by having them there we're not
hurting anything. OTOH, if they are there, maybe it'll give those new
ideas a little visibility in to what we have coming down the pipe, and
maybe encourage some other contributions.
-aaron
RE: cvs commit: httpd-2.0 STATUS ROADMAP
Posted by Bill Stoddard <bi...@wstoddard.com>.
> At 01:25 PM 11/23/2002, Aaron Bannert wrote:
>
> >On Saturday, November 23, 2002, at 11:15 AM, wrowe@apache.org wrote:
> >> CURRENT RELEASE NOTES:
> >>
> >> + * This branch is operating under R-T-C guidelines.
> >
> >Huh? No way. We're all adults here. If someone commits something
> >that you are uncomfortable with, bring it up on the list. There's
> >no reason for any ASF project to be R-T-C, IMHO. Our voting
> >rules are sufficient enough to protect against bogus commits to
> >stable or "maintenance" trees.
>
> One 'advantage' of R-T-C is eliminating the 'last minute breakage'
> of trees as we approach releases. I understand that most httpd'ers
> haven't operated under R-T-C for a very long time, we enjoy treating
> cvs as a sandbox for rapid development.
>
> I think Jeff's original appeal for some known, stable branch (he actually
> asked for 2.0.43.xxx in perpetutity) was that the release should not be
> the sandbox for new ideas.
>
> But I was only interpreting other's comments, committers, how do you
> feel about this policy? Should we operate C-T-R on 2_0_BRANCH?
> Aaron, if you like, put this to a vote in 2_0_BRANCH'es STATUS.
I liked the way we worked in Apache 1.3 before 2.0 came along. It was CTR but
folks were generally MUCH more careful about the code they committed. If the
code was even somewhat likely to break or change some expected bahaviour, the
patch was submitted to the mailing list for peer review first. I would be in
favor of staying CTR -if- we (the committers) individually adopt somewhat more
conservative policy in what we commit to the tree w/o first getting dev list
feedback.
Bill
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 01:25 PM 11/23/2002, Aaron Bannert wrote:
>On Saturday, November 23, 2002, at 11:15 AM, wrowe@apache.org wrote:
>> CURRENT RELEASE NOTES:
>>
>> + * This branch is operating under R-T-C guidelines.
>
>Huh? No way. We're all adults here. If someone commits something
>that you are uncomfortable with, bring it up on the list. There's
>no reason for any ASF project to be R-T-C, IMHO. Our voting
>rules are sufficient enough to protect against bogus commits to
>stable or "maintenance" trees.
One 'advantage' of R-T-C is eliminating the 'last minute breakage'
of trees as we approach releases. I understand that most httpd'ers
haven't operated under R-T-C for a very long time, we enjoy treating
cvs as a sandbox for rapid development.
I think Jeff's original appeal for some known, stable branch (he actually
asked for 2.0.43.xxx in perpetutity) was that the release should not be
the sandbox for new ideas.
But I was only interpreting other's comments, committers, how do you
feel about this policy? Should we operate C-T-R on 2_0_BRANCH?
Aaron, if you like, put this to a vote in 2_0_BRANCH'es STATUS.
+ * The 'modules/experimental' tree will evaporate soon. Anything
>> + in the development branch should be located under it's eventual
>> + home (such as modules/cache/.)
>
>There's no reason to remove this from the 2.0 releases. They are experimental
>not matter way, and if someone grabs a 2.0 tarball and wants to start
>hacking on experimental stuff, all the better!
I'm taking this from the vote. Again, if you want to phrase this very specific
issue as a vote (in 2_0_BRANCH'es STATUS) I sure won't object.
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 02:44 PM 11/23/2002, Brian Pane wrote:
>On Sat, 2002-11-23 at 12:19, Cliff Woolley wrote:
>> On Sat, 23 Nov 2002, Aaron Bannert wrote:
>
>
>> > > + * The 'modules/experimental' tree will evaporate soon. Anything
>> > > + in the development branch should be located under it's eventual
>> > > + home (such as modules/cache/.)
>> >
>> > There's no reason to remove this from the 2.0 releases. They are
>> > experimental not matter way, and if someone grabs a 2.0 tarball and
>> > wants to start hacking on experimental stuff, all the better!
>>
>> -1 to removing them from 2.0. The modules are 'experimental' not just
>> because they are development projects, but more because we don't put the
>> same level of faith in those modules working as advertised as we do in
>> regular modules. But some people are willing to take the chance and DO
>> use them in production! We can't just snatch them out from under those
>> people.
>
>I agree: we should keep the experimental modules.
>
>The cache code is a good example of a beta-quality component
>that's getting a healthy amount of testing and feedback from
>users because it's available as an experimental subsystem in
>the stable release.
I think we have a universal consensus here about 2.0.
I'm not certain I want to persist the experimental concept into 2.2,
since those users who love "life on the bleeding edge" should be
encouraged to grab a 2.1 alpha or beta, and play with the modules
that are "almost ready". I'd like to see us quit putting modules into
the next release branch that are "far from ready".
The other half of the coin; we want those users testing 2.1. We think
2.1 is pretty cool. We hope to have a stable 2.2 rollout without a ton
of bugs. The more testers, due to their desire to test the latest and
greatest, or their desire to get 'experimental' features, the better for
the code we will release as 2.2.
Bill
RE: cvs commit: httpd-2.0 STATUS ROADMAP
Posted by Bill Stoddard <bi...@wstoddard.com>.
> On Sat, 2002-11-23 at 12:19, Cliff Woolley wrote:
> > On Sat, 23 Nov 2002, Aaron Bannert wrote:
>
>
> > > > + * The 'modules/experimental' tree will evaporate soon. Anything
> > > > + in the development branch should be located under it's eventual
> > > > + home (such as modules/cache/.)
> > >
> > > There's no reason to remove this from the 2.0 releases. They are
> > > experimental not matter way, and if someone grabs a 2.0 tarball and
> > > wants to start hacking on experimental stuff, all the better!
> >
> > -1 to removing them from 2.0. The modules are 'experimental' not just
> > because they are development projects, but more because we don't put the
> > same level of faith in those modules working as advertised as we do in
> > regular modules. But some people are willing to take the chance and DO
> > use them in production! We can't just snatch them out from under those
> > people.
>
> I agree: we should keep the experimental modules.
>
> The cache code is a good example of a beta-quality component
> that's getting a healthy amount of testing and feedback from
> users because it's available as an experimental subsystem in
> the stable release.
Exactly. I see the same thing with the cache code.
>
> Brian
>
>
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Posted by Brian Pane <br...@cnet.com>.
On Sat, 2002-11-23 at 12:19, Cliff Woolley wrote:
> On Sat, 23 Nov 2002, Aaron Bannert wrote:
> > > + * The 'modules/experimental' tree will evaporate soon. Anything
> > > + in the development branch should be located under it's eventual
> > > + home (such as modules/cache/.)
> >
> > There's no reason to remove this from the 2.0 releases. They are
> > experimental not matter way, and if someone grabs a 2.0 tarball and
> > wants to start hacking on experimental stuff, all the better!
>
> -1 to removing them from 2.0. The modules are 'experimental' not just
> because they are development projects, but more because we don't put the
> same level of faith in those modules working as advertised as we do in
> regular modules. But some people are willing to take the chance and DO
> use them in production! We can't just snatch them out from under those
> people.
I agree: we should keep the experimental modules.
The cache code is a good example of a beta-quality component
that's getting a healthy amount of testing and feedback from
users because it's available as an experimental subsystem in
the stable release.
Brian
RE: cvs commit: httpd-2.0 STATUS ROADMAP
Posted by Bill Stoddard <bi...@wstoddard.com>.
> On Sat, 23 Nov 2002, Aaron Bannert wrote:
>
> > Huh? No way. We're all adults here. If someone commits something
> > that you are uncomfortable with, bring it up on the list. There's
> > no reason for any ASF project to be R-T-C, IMHO. Our voting
> > rules are sufficient enough to protect against bogus commits to
> > stable or "maintenance" trees.
>
> Agreed.
Ditto.
>
> > > + * The 'modules/experimental' tree will evaporate soon. Anything
> > > + in the development branch should be located under it's eventual
> > > + home (such as modules/cache/.)
> >
> > There's no reason to remove this from the 2.0 releases. They are
> > experimental not matter way, and if someone grabs a 2.0 tarball and
> > wants to start hacking on experimental stuff, all the better!
>
> -1 to removing them from 2.0.
Yep, I agree.
Bill
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Posted by Cliff Woolley <jw...@virginia.edu>.
On Sat, 23 Nov 2002, Aaron Bannert wrote:
> Huh? No way. We're all adults here. If someone commits something
> that you are uncomfortable with, bring it up on the list. There's
> no reason for any ASF project to be R-T-C, IMHO. Our voting
> rules are sufficient enough to protect against bogus commits to
> stable or "maintenance" trees.
Agreed.
> > + * The 'modules/experimental' tree will evaporate soon. Anything
> > + in the development branch should be located under it's eventual
> > + home (such as modules/cache/.)
>
> There's no reason to remove this from the 2.0 releases. They are
> experimental not matter way, and if someone grabs a 2.0 tarball and
> wants to start hacking on experimental stuff, all the better!
-1 to removing them from 2.0. The modules are 'experimental' not just
because they are development projects, but more because we don't put the
same level of faith in those modules working as advertised as we do in
regular modules. But some people are willing to take the chance and DO
use them in production! We can't just snatch them out from under those
people.
--Cliff
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Posted by Aaron Bannert <aa...@clove.org>.
On Saturday, November 23, 2002, at 11:15 AM, wrowe@apache.org wrote:
> CURRENT RELEASE NOTES:
>
> + * This branch is operating under R-T-C guidelines.
Huh? No way. We're all adults here. If someone commits something
that you are uncomfortable with, bring it up on the list. There's
no reason for any ASF project to be R-T-C, IMHO. Our voting
rules are sufficient enough to protect against bogus commits to
stable or "maintenance" trees.
> + * Backwards compatibility is expected of future Apache 2.0
> releases,
> + such that no MMN major number changes will occur until 2.1.
Well, we hope. :)
> + * The current sandbox (cvs HEAD) operating under C-T-R
> guidelines
> + is version 2.1-dev.
> +
> + * All commits to APACHE_2_0_BRANCH must be reflected in cvs HEAD
> + as well, if they apply. Logical progression is commit to
> HEAD,
> + get feedback (3 +1's) and then commit to APACHE_2_0_BRANCH.
Yeah, well of course. Bug fixes go in both, features go in HEAD...
> +
> + * The 'modules/experimental' tree will evaporate soon. Anything
> + in the development branch should be located under it's
> eventual
> + home (such as modules/cache/.)
There's no reason to remove this from the 2.0 releases. They are
experimental
not matter way, and if someone grabs a 2.0 tarball and wants to start
hacking on experimental stuff, all the better!
>
> RELEASE SHOWSTOPPERS:
>
> + * The Auth module overhaul of module names and directives need
> to
> + be reverted to their 2.0.43 names. The new hooks remain.
-aaron