Paul Querna wrote: > On Sun, Oct 4, 2009 at 11:48 AM, Jim Jagielski <[email protected]> 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 :)
