Re: Time for a 2.3/2.4 branch?
Jim Jagielski wrote: start cutting alpha releases :-) I suggested a 2.3.3a about a month ago and the silence was deafening. As wrowe pointed out, there is a lot of work still to do - modules need to be documented, or marked for removal if abandoned. If we branched v2.4.x now, we would have to do this work twice, once on trunk, and a second time on the v2.4 branch. I don't think we're quite ready to branch trunk yet, there is still more work to do, but cutting alphas will definitely get the momentum going. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Time for a 2.3/2.4 branch?
On Oct 5, 2009, at 7:34 AM, Graham Leggett wrote: Jim Jagielski wrote: start cutting alpha releases :-) I suggested a 2.3.3a about a month ago and the silence was deafening. I don't think we're quite ready to branch trunk yet, there is still more work to do, but cutting alphas will definitely get the momentum going. I'm going to go thru and see what tasks need to be done and try to start documenting them as release showstoppers, and in parallel try to get a 2.3.3-alpha out.
Time for a 2.3/2.4 branch?
If we are serious about trying to get a 2.4 out this year, what do people say about branching off trunk at this point, so we could focus on the required checks while still allowing trunk to continue unabated?
Re: Time for a 2.3/2.4 branch?
Jim Jagielski wrote: If we are serious about trying to get a 2.4 out this year, what do people say about branching off trunk at this point, so we could focus on the required checks while still allowing trunk to continue unabated? -1, until we have votes for a beta/almost GA from trunk, -or- until someone offers a breaking patch which is targeted to something later than 2.4/3.0. That's IMHO - vetos are irrelevant to this topic. If you can point to a recent commit as an example of what we shouldn't pick up in 2.4/3.0, you could probably shift my opinion about this. My reasoning; Trunk was split to allow people to make rapid progress without the overhead of choosing the backport path and slowing down progress. In fact, progress on httpd is mostly at a standstill by anyone other than some committed folks happy to work through the STATUS files. The process had chased them off, much as Aaron Bannert and others had argued. On the other hand 2.2 is very dependable and stable as compared to other open source efforts. So forking too early isn't healthy, and forking too late (your fear) also isn't healthy to finally accomplish a release. Let's get to alpha and then discuss. (Obviously, if trunk is taken in a strange direction, it's always possible to pull the branch later from the same rev as a particular tag.) Does this make sense? Bill
Re: Time for a 2.3/2.4 branch?
William A. Rowe, Jr. wrote: Jim Jagielski wrote: If we are serious about trying to get a 2.4 out this year, what do people say about branching off trunk at this point, so we could focus on the required checks while still allowing trunk to continue unabated? -1, until we have votes for a beta/almost GA from trunk, -or- until someone offers a breaking patch which is targeted to something later than 2.4/3.0. That's IMHO - vetos are irrelevant to this topic. If you can point to a recent commit as an example of what we shouldn't pick up in 2.4/3.0, you could probably shift my opinion about this. My reasoning; FWIW, if you question had been if we are serious about getting 2.4 out this year, without my suggested Apache 3.0 development getting in the way, can we please fork now? the answer would be different. But I'm not seeing a desire from any folks to be working n+2 versions ahead of the next major release, and those that might ponder it also know how to fork sandboxes :)
Re: Time for a 2.3/2.4 branch?
On Oct 4, 2009, at 2:21 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: If we are serious about trying to get a 2.4 out this year, what do people say about branching off trunk at this point, so we could focus on the required checks while still allowing trunk to continue unabated? -1, until we have votes for a beta/almost GA from trunk, -or- until someone offers a breaking patch which is targeted to something later than 2.4/3.0. That's IMHO - vetos are irrelevant to this topic. If you can point to a recent commit as an example of what we shouldn't pick up in 2.4/3.0, you could probably shift my opinion about this. My reasoning; Trunk was split to allow people to make rapid progress without the overhead of choosing the backport path and slowing down progress. In fact, progress on httpd is mostly at a standstill by anyone other than some committed folks happy to work through the STATUS files. The process had chased them off, much as Aaron Bannert and others had argued. On the other hand 2.2 is very dependable and stable as compared to other open source efforts. So forking too early isn't healthy, and forking too late (your fear) also isn't healthy to finally accomplish a release. Let's get to alpha and then discuss. (Obviously, if trunk is taken in a strange direction, it's always possible to pull the branch later from the same rev as a particular tag.) Does this make sense? Yep. My only fear, as you state, is without some clear consensus that we want to get a 2.4 out sometime soon, we will be stuck in that never-ending loop of polishing the turd. ;)
Re: Time for a 2.3/2.4 branch?
On Sun, Oct 4, 2009 at 11:48 AM, Jim Jagielski j...@jagunet.com wrote: On Oct 4, 2009, at 2:21 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: If we are serious about trying to get a 2.4 out this year, what do people say about branching off trunk at this point, so we could focus on the required checks while still allowing trunk to continue unabated? -1, until we have votes for a beta/almost GA from trunk, -or- until someone offers a breaking patch which is targeted to something later than 2.4/3.0. That's IMHO - vetos are irrelevant to this topic. If you can point to a recent commit as an example of what we shouldn't pick up in 2.4/3.0, you could probably shift my opinion about this. My reasoning; Trunk was split to allow people to make rapid progress without the overhead of choosing the backport path and slowing down progress. In fact, progress on httpd is mostly at a standstill by anyone other than some committed folks happy to work through the STATUS files. The process had chased them off, much as Aaron Bannert and others had argued. On the other hand 2.2 is very dependable and stable as compared to other open source efforts. So forking too early isn't healthy, and forking too late (your fear) also isn't healthy to finally accomplish a release. Let's get to alpha and then discuss. (Obviously, if trunk is taken in a strange direction, it's always possible to pull the branch later from the same rev as a particular tag.) Does this make sense? Yep. My only fear, as you state, is without some clear consensus that we want to get a 2.4 out sometime soon, we will be stuck in that never-ending loop of polishing the turd. ;) start cutting alpha releases :-) last timed we tried trunk on www.apache.org it didn't go so well... so... we should do that again.
Re: Time for a 2.3/2.4 branch?
Paul Querna wrote: On Sun, Oct 4, 2009 at 11:48 AM, Jim Jagielski j...@jagunet.com wrote: Yep. My only fear, as you state, is without some clear consensus that we want to get a 2.4 out sometime soon, we will be stuck in that never-ending loop of polishing the turd. ;) start cutting alpha releases :-) last timed we tried trunk on www.apache.org it didn't go so well... so... we should do that again. +1 - note that to get from alpha to GA, the biggest problem right now is the state of docs (as Stefan hinted at). LOTS of modules are entirely undocumented. We might want to look at these and consider dumping these from the next 2.4 release if no documentation magically appears, courtesy of their authors. But documentation need not block an alpha :) My worries about going GA today mostly revolve around; * introduction of many new hard-dependencies rather than registered functions (one solution; for the guilty to go back and correct their designs or revert) * problematic design of ap_internal_fast_redirect (solution; replace all calls within httpd to ap_internal_redirect, then remove it entirely) * problematic design of Limit - looks like it's time to commit Method since it's probably premature to lock in all users to use mod_lua (remaining issue; determining where the Method merge is evaluated) * problematic introduction of redundant (and often error-prone) code. For example, socache moves us partly in the right direction, but didn't remove the redundant directive handlers from the many consumers (fortunately I'm writing an socache consumer right now, so I'm likely to just address this) * undocumented modules and new features (solution; document, or remove from final release branch) None of these are months-long efforts, it's just a matter of enough contributors who would be looking to polish up trunk/, in proportion to those dedicating dozens of man-months to reviewing backports to yesterday's server :)
