Re: [PROPOSAL] Branch 2.1.x on May 13
William A. Rowe, Jr. wrote: At 04:48 PM 5/2/2005, Paul Querna wrote: Personally, I have held off on starting refactors of code, because I do not want to be detrimental to the ability to make a 2.2 Branch. I would like to investigate making more parts of httpd async, in conjunction with the Event MPM. I would also like to redo some of the configuration system -- but I have avoided working on these, because of my personal belief that 2.1-dev has enough for a new GA branch. First - let me say I TOTALLY agree with your concept for more async features and design!!! Second - there is no way that disconnected/async events that can jump threads will ever fit into httpd-2. That quantum leap must be httpd-3 because it breaks the assumptions and gross hacks of many module authors. Even if we 1. never leap threads between translate_name and finalize_request, therefore 2. restrict all async to the reception of the request packet; there will still be affected modules, mod_sspi and user tracking apps that span pipelines - which don't expect data to jump threads on the connection layer. I think there is wide agreement that /trunk/ should always be open for commits. I don't imagine that my personal development ideas match everyone, and they are not my only reason for wanting a 2.1.x branch. Absolute rule, trunk/ should always build as well. If it can't build, it should be reparable within a very short window. Hopefully not by the committer, but more likely, by platform maintainers 'catching up'. That said, I'm strongly -1 on dropping such radical changes directly into trunk/. There is no way code changes on this scale are ever CTR. We have SVN, so creating sandboxes/experimental/proof-of-concept branches are trivial :) This was true of every major refactoring of Apache since Shambala. Create a sandbox today to start experimenting with async models. I agree, a sandbox would be good for these types of changes, but I haven't even started a sandbox, because I do not want to try to land it back into the current trunk of 2.1-dev. The types of things that making it more async could change would significantly change the compatibility with existing modules -- and like you hint at, could imply a 3.0 type change. I didn't mean to paint my disinterest in doing this work now as not making sandboxes or working directly in trunk, but, mostly that I don't think merging them back into trunk is reasonable, if we expect 2.2 to come out any time soon.
Re: [PROPOSAL] Branch 2.1.x on May 13
William A. Rowe, Jr. wrote: This has somewhat turned into the real question, What are the show stoppers for a 2.2 GA Branch? If you believe an issue is a show stopper for a GA Branch, please add it to the STATUS File. So to amend your original proposal; on May 13; * tagging an alpha candidate * identifying all showstoppers to GA and if that list is short enough, we will be able to read how long the window from 2.1-dev to 2.2 GA actually is, and if we are fitting into something that resembles a one month timeframe. Whats wrong with updating the STATUS File today? AFAIK, the only other major issue is to do with apr-iconv 1.x conflicting with apr-iconv 0.9.x. -- and as previously discussed, this does not affect most unix platforms, since they do not use apr-iconv. I don't have the best understanding of this issue, since it doesn't effect me, but if no one else does it, I will add it later today to the STATUS file. Are there other issues anyone believes to be show stoppers? Get them out on the table now. Waiting for another 'alpha' is silly. If something is so detrimental to block making a 'beta' release, it should be documented so everyone knows about it, and we can get more ideas on how to fix it. -Paul
Re: [PROPOSAL] Branch 2.1.x on May 13
At 03:24 AM 5/3/2005, Paul Querna wrote: William A. Rowe, Jr. wrote: This has somewhat turned into the real question, What are the show stoppers for a 2.2 GA Branch? If you believe an issue is a show stopper for a GA Branch, please add it to the STATUS File. So to amend your original proposal; on May 13; * tagging an alpha candidate * identifying all showstoppers to GA Whats wrong with updating the STATUS File today? AFAIK, the only other major issue is to do with apr-iconv 1.x conflicting with apr-iconv 0.9.x. -- and as previously discussed, this does not affect most unix platforms, since they do not use apr-iconv. I don't have the best understanding of this issue, since it doesn't effect me, but if no one else does it, I will add it later today to the STATUS file. Are there other issues anyone believes to be show stoppers? Get them out on the table now. Waiting for another 'alpha' is silly. If something is so detrimental to block making a 'beta' release, it should be documented so everyone knows about it, and we can get more ideas on how to fix it. You are talking about beta showstoppers; and yes I will have iconv ready to release this week. Think we have consensus on the fix. But I'm asking about the showstoppers to GA. I want that list, to know we won't be stalled in the beta phase for long. I'll add what I know of. Bill
Fw: [PROPOSAL] Branch 2.1.x on May 13
- Original Message - From: Paul Querna [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Tuesday, May 03, 2005 12:24 PM Subject: Re: [PROPOSAL] Branch 2.1.x on May 13 William A. Rowe, Jr. wrote: This has somewhat turned into the real question, What are the show stoppers for a 2.2 GA Branch? If you believe an issue is a show stopper for a GA Branch, please add it to the STATUS File. So to amend your original proposal; on May 13; * tagging an alpha candidate * identifying all showstoppers to GA and if that list is short enough, we will be able to read how long the window from 2.1-dev to 2.2 GA actually is, and if we are fitting into something that resembles a one month timeframe. Whats wrong with updating the STATUS File today? AFAIK, the only other major issue is to do with apr-iconv 1.x conflicting with apr-iconv 0.9.x. -- and as previously discussed, this does not affect most unix platforms, since they do not use apr-iconv. I don't have the best understanding of this issue, since it doesn't effect me, but if no one else does it, I will add it later today to the STATUS file. Are there other issues anyone believes to be show stoppers? Get them out on the table now. Waiting for another 'alpha' is silly. If something is so detrimental to block making a 'beta' release, it should be documented so everyone knows about it, and we can get more ideas on how to fix it. -Paul
Re: [PROPOSAL] Branch 2.1.x on May 13
Why do I suddenly have the I Have A Dream speech flashes? ;-) - Dmitri. Paul Querna wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think that most other developers agree that 2.1.x/trunk has enough features for a 2.2.x GA branch. I believe 2.1.x is a moving target. I think it is hard to stabilize a moving target. I believe we should always keep trunk open for development. I believe in order to create a stable 2.1.x, in preparation for a 2.2.x GA branch. I think we should branch 2.1.x from trunk to stabilize it. Once 2.1.x is in a branch, I believe trunk should become 2.3.x. I believe having 2.1.x in a stabilization branch will speed the release of 2.2.x. I believe that 2.1.x should have a set branch date. Based on past history, I do not think we have been successful without a set date. I am proposing the branch date be May 13, 2005. Votes/Comments/Alternatives/Ideas/etc are all welcome. Thanks, - -Paul -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCcrj/94h19kJyHwARAr0uAKC2giVIv+alNrM2WATOa6QZKN+58QCgktoe i/FE+UING3GZU80G/NEpeX4= =DCRq -END PGP SIGNATURE-
Re: [PROPOSAL] Branch 2.1.x on May 13
--On Friday, April 29, 2005 3:45 PM -0700 Paul Querna [EMAIL PROTECTED] wrote: I am proposing the branch date be May 13, 2005. ++1. -- justin
Re: [PROPOSAL] Branch 2.1.x on May 13
I'm +1 for branching 2.2-alpha... However, there are 2 outstanding show-stoppers. Do we expect these to be addressed before the branch. I think so, especially if they require API changes
Re: [PROPOSAL] Branch 2.1.x on May 13
Justin Erenkrantz wrote: Why couldn't we fix those up after the branch? The point would be to stop making 2.1.x a moving target so that we can fix the showstoppers. +1 on that. Not on the timing, though: I won't have time for apache until after Xtech[1], so that's a definite abstension on anything happening on May 13th. [1] where I'm giving a presentation on Apache as a platform for XML apps on the Web. -- Nick Kew
Re: [PROPOSAL] Branch 2.1.x on May 13
--On Monday, May 2, 2005 3:33 PM -0400 Jim Jagielski [EMAIL PROTECTED] wrote: I thought the whole idea about having a 2.1 dev version was to avoid monkeying around with the API and the problems when we were doing 1.3 and 2.0. Once we branch, it is possible that we'll run into issues that may require a bump, but I think entering into a 2.2 tree expecting one may not be prudent. And it's only the 2nd showstopper which could be considered valid enough to delay the branch. Paul proposed branching 2.1.x not 2.2.x. -- justin
Re: [PROPOSAL] Branch 2.1.x on May 13
Justin Erenkrantz wrote: --On Monday, May 2, 2005 3:33 PM -0400 Jim Jagielski [EMAIL PROTECTED] wrote: I thought the whole idea about having a 2.1 dev version was to avoid monkeying around with the API and the problems when we were doing 1.3 and 2.0. Once we branch, it is possible that we'll run into issues that may require a bump, but I think entering into a 2.2 tree expecting one may not be prudent. And it's only the 2nd showstopper which could be considered valid enough to delay the branch. Paul proposed branching 2.1.x not 2.2.x. -- justin Ahh yes. +1 then. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: [PROPOSAL] Branch 2.1.x on May 13
+1 Brad [EMAIL PROTECTED] Friday, April 29, 2005 4:45:19 PM -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think that most other developers agree that 2.1.x/trunk has enough features for a 2.2.x GA branch. I believe 2.1.x is a moving target. I think it is hard to stabilize a moving target. I believe we should always keep trunk open for development. I believe in order to create a stable 2.1.x, in preparation for a 2.2.x GA branch. I think we should branch 2.1.x from trunk to stabilize it. Once 2.1.x is in a branch, I believe trunk should become 2.3.x. I believe having 2.1.x in a stabilization branch will speed the release of 2.2.x. I believe that 2.1.x should have a set branch date. Based on past history, I do not think we have been successful without a set date. I am proposing the branch date be May 13, 2005. Votes/Comments/Alternatives/Ideas/etc are all welcome. Thanks, - -Paul -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCcrj/94h19kJyHwARAr0uAKC2giVIv+alNrM2WATOa6QZKN+58QCgktoe i/FE+UING3GZU80G/NEpeX4= =DCRq -END PGP SIGNATURE-
Re: [PROPOSAL] Branch 2.1.x on May 13
At 05:45 PM 4/29/2005, Paul Querna wrote: I think that most other developers agree that 2.1.x/trunk has enough features for a 2.2.x GA branch. +1 I believe 2.1.x is a moving target. +/- 0. I see the tree is fairly stable, has some decent bug fixing activity, and nothing destabling. To the extent that 'I want this feature in version x.y' that always happens, and can be ignored unless there is code to consider. I think it is hard to stabilize a moving target. +1 if it was moving. -1 to your statement. I believe we should always keep trunk open for development. Ack. I believe in order to create a stable 2.1.x, in preparation for a 2.2.x GA branch. We discussed this at ApacheCon. When we have something betaworthy, the candidate should be simply svn cp'ed to a branch. I think we should branch 2.1.x from trunk to stabilize it. -1 - I don't see trunk as unstable. Once 2.1.x is in a branch, I believe trunk should become 2.3.x. -1 - but close. Once 2.2 is branched, then 2.1 is dead. Trunk does immediately become 2.3.x at that point, yes. I believe having 2.1.x in a stabilization branch will speed the release of 2.2.x. disagree... I believe that 2.1.x should have a set branch date. Based on past history, I do not think we have been successful without a set date. I am proposing the branch date be May 13, 2005. The 'problems' aren't with the branch date, although an alpha tag (with the intent to become beta) as of that date would always be welcomed. The problem is really that there will be alot of float between first beta and final. I'm suggesting the goal isn't date setting the branch, it's date setting the final release after branch. I'm not convinced branching before beta buys us anything, but sure am convinced that we have to branch when we go beta. The nice bit is that rather than copying from trunk, once we have some 2.1.6-alpha we want to decree as 2.2.0-beta, we copy from the 2.1.6 tag. So trunk really isn't in our way. From discussion - I see us branching 2.1.x anyways, but still object since we will now be maintaining two or three backports for every bugfix commit to trunk/. Humbly suggest this isn't the conclusion we reached at AC Las Vegas, and suggest it's still the wrong solution to a non-problem. In short IMHO - get alpha to beta; set a short date for GA (keep pain minimal); spin 1x - 3x on beta till release, get 2.2 out the door. A one month window of parallel 2.3 Trunk/2.2 Branch/2.0 Branch backports are a pain, but if we can keep the window short we shouldn't suffer to greatly. Bill
Re: [PROPOSAL] Branch 2.1.x on May 13
William A. Rowe, Jr. wrote: From discussion - I see us branching 2.1.x anyways, but still object since we will now be maintaining two or three backports for every bugfix commit to trunk/. Humbly suggest this isn't the conclusion we reached at AC Las Vegas, and suggest it's still the wrong solution to a non-problem. Bill makes some good points... it seems that branching would simply be renaming trunk. The good thing is that with svn this is cheap and easy, but will it really do what we want? Also, the gotta backport this to yet another branch issue is valid. In other words, trunk is 2.1 anyway, so what does a branch provide? I would say it's a perception advantage mostly. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: [PROPOSAL] Branch 2.1.x on May 13
Jim Jagielski wrote: William A. Rowe, Jr. wrote: From discussion - I see us branching 2.1.x anyways, but still object since we will now be maintaining two or three backports for every bugfix commit to trunk/. Humbly suggest this isn't the conclusion we reached at AC Las Vegas, and suggest it's still the wrong solution to a non-problem. Bill makes some good points... it seems that branching would simply be renaming trunk. The good thing is that with svn this is cheap and easy, but will it really do what we want? Also, the gotta backport this to yet another branch issue is valid. In other words, trunk is 2.1 anyway, so what does a branch provide? I would say it's a perception advantage mostly. Yes. I think it is almost 90% about perception. This is about 'drawing the line in the sand'. Personally, I have held off on starting refactors of code, because I do not want to be detrimental to the ability to make a 2.2 Branch. I would like to investigate making more parts of httpd async, in conjunction with the Event MPM. I would also like to redo some of the configuration system -- but I have avoided working on these, because of my personal belief that 2.1-dev has enough for a new GA branch. I think there is wide agreement that /trunk/ should always be open for commits. I don't imagine that my personal development ideas match everyone, and they are not my only reason for wanting a 2.1.x branch. Right now, I see 2.1-dev as a never ending version. There are always problems, and there will always be new problems with trunk. Yes, it makes back ports harder, and I believe, rightfully so, because we already have enough features for 2.2. This has somewhat turned into the real question, What are the show stoppers for a 2.2 GA Branch? I don't think the two listed in the STATUS file reflect reality. If you believe an issue is a show stopper for a GA Branch, please add it to the STATUS File. -Paul
Re: [PROPOSAL] Branch 2.1.x on May 13
Jim Jagielski wrote: William A. Rowe, Jr. wrote: From discussion - I see us branching 2.1.x anyways, but still object since we will now be maintaining two or three backports for every bugfix commit to trunk/. If the trees are so in sync that the same patch applies it's trivial to do the backports. Humbly suggest this isn't the conclusion we reached at AC Las Vegas, and suggest it's still the wrong solution to a non-problem. If there was a 2.1.x beta out there right now I would agree it was a non-problem. It would be a good thing to restate what the conclusions were at AC 2004 US. Bill makes some good points... it seems that branching would simply be renaming trunk. The good thing is that with svn this is cheap and easy, but will it really do what we want? Also, the gotta backport this to yet another branch issue is valid. No it isn't. That's the whole point of stabilizing. No more worries about whether someone actually reviewed the slew of changes the night before the RM intended to tag. The backport issue will still stay FWIW. If not now, it will come at the time we have 2.0 and 2.2 out there, and trunk is at 2.3-dev. It's not like we can drop support for 2.0 then. In other words, trunk is 2.1 anyway, so what does a branch provide? I would say it's a perception advantage mostly. Well, it would let people continue to have a place where they can develop the larger features/refactoring jobs. That's indeed only a handful of people, but at the same time a group of people who do a lot of work. Sander
Re: [PROPOSAL] Branch 2.1.x on May 13
Sander Striker wrote: If the trees are so in sync that the same patch applies it's trivial to do the backports. The backport issue will still stay FWIW. If not now, it will come at the time we have 2.0 and 2.2 out there, and trunk is at 2.3-dev. It's not like we can drop support for 2.0 then. Well, it would let people continue to have a place where they can develop the larger features/refactoring jobs. That's indeed only a handful of people, but at the same time a group of people who do a lot of work. I submit that we can't have it both ways, and expect 2 trees to be both easily in sync and yet one where major refactoring is taking place... Look at the proxy diffs between 2.0 and 2.1 as an example. I think our goal should be in getting 2.2 out, rather than creating yet another branch, which would result in 3 versions of 2.x being in active development. Will branching 2.1 help that? Maybe the large refactoring place should be branch instead? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: [PROPOSAL] Branch 2.1.x on May 13
At 05:26 PM 5/2/2005, Sander Striker wrote: Bill makes some good points... it seems that branching would simply be renaming trunk. The good thing is that with svn this is cheap and easy, but will it really do what we want? Also, the gotta backport this to yet another branch issue is valid. No it isn't. That's the whole point of stabilizing. No more worries about whether someone actually reviewed the slew of changes the night before the RM intended to tag. Tag, fix, retag, fix, and bless. Once the candidate is 99% of where the beta should be, such cosmetics are trivial. The backport issue will still stay FWIW. If not now, it will come at the time we have 2.0 and 2.2 out there, and trunk is at 2.3-dev. It's not like we can drop support for 2.0 then. Not so much ... Do we all believe that after 2.2 is Released, there will be much activity on 2.0, other than closing security holes? Unlike 1.3 - 2.0 - the migration to 2.2 is relatively straightforward. Not entirely, because we break binary compatibility, and users will have some lag before everything just works and all 3rd party binary modules become available. That said; if you want a BETTER Apache, installing 2.2 will become the stock answer. We couldn't expect that of 1.3 users in the same, simple way we can encourage 2.0 users. Obviously 1.3 and 2.0 were night and day. In other words, trunk is 2.1 anyway, so what does a branch provide? I would say it's a perception advantage mostly. Well, it would let people continue to have a place where they can develop the larger features/refactoring jobs. That's indeed only a handful of people, but at the same time a group of people who do a lot of work. Larger features/Refactoring belong pre-committed to a sandbox or work branch. That's been true since before most of our time. Bill
Re: [PROPOSAL] Branch 2.1.x on May 13
At 04:48 PM 5/2/2005, Paul Querna wrote: Personally, I have held off on starting refactors of code, because I do not want to be detrimental to the ability to make a 2.2 Branch. I would like to investigate making more parts of httpd async, in conjunction with the Event MPM. I would also like to redo some of the configuration system -- but I have avoided working on these, because of my personal belief that 2.1-dev has enough for a new GA branch. First - let me say I TOTALLY agree with your concept for more async features and design!!! Second - there is no way that disconnected/async events that can jump threads will ever fit into httpd-2. That quantum leap must be httpd-3 because it breaks the assumptions and gross hacks of many module authors. Even if we 1. never leap threads between translate_name and finalize_request, therefore 2. restrict all async to the reception of the request packet; there will still be affected modules, mod_sspi and user tracking apps that span pipelines - which don't expect data to jump threads on the connection layer. I think there is wide agreement that /trunk/ should always be open for commits. I don't imagine that my personal development ideas match everyone, and they are not my only reason for wanting a 2.1.x branch. Absolute rule, trunk/ should always build as well. If it can't build, it should be reparable within a very short window. Hopefully not by the committer, but more likely, by platform maintainers 'catching up'. That said, I'm strongly -1 on dropping such radical changes directly into trunk/. There is no way code changes on this scale are ever CTR. We have SVN, so creating sandboxes/experimental/proof-of-concept branches are trivial :) This was true of every major refactoring of Apache since Shambala. Create a sandbox today to start experimenting with async models. This has somewhat turned into the real question, What are the show stoppers for a 2.2 GA Branch? If you believe an issue is a show stopper for a GA Branch, please add it to the STATUS File. So to amend your original proposal; on May 13; * tagging an alpha candidate * identifying all showstoppers to GA and if that list is short enough, we will be able to read how long the window from 2.1-dev to 2.2 GA actually is, and if we are fitting into something that resembles a one month timeframe. Bill
[PROPOSAL] Branch 2.1.x on May 13
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think that most other developers agree that 2.1.x/trunk has enough features for a 2.2.x GA branch. I believe 2.1.x is a moving target. I think it is hard to stabilize a moving target. I believe we should always keep trunk open for development. I believe in order to create a stable 2.1.x, in preparation for a 2.2.x GA branch. I think we should branch 2.1.x from trunk to stabilize it. Once 2.1.x is in a branch, I believe trunk should become 2.3.x. I believe having 2.1.x in a stabilization branch will speed the release of 2.2.x. I believe that 2.1.x should have a set branch date. Based on past history, I do not think we have been successful without a set date. I am proposing the branch date be May 13, 2005. Votes/Comments/Alternatives/Ideas/etc are all welcome. Thanks, - -Paul -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCcrj/94h19kJyHwARAr0uAKC2giVIv+alNrM2WATOa6QZKN+58QCgktoe i/FE+UING3GZU80G/NEpeX4= =DCRq -END PGP SIGNATURE-
