On 12/02/2013 04:43 PM, Anatol Pomozov wrote: > What I am trying to say is that keeping software up-to-date is one of > the main maintainer's responsibilities. Especially in Arch Linux that > "strives to stay bleeding edge, and typically offers the latest stable > versions of most software" (quote from > https://wiki.archlinux.org/index.php/Arch_Linux). Re-read "typically offer the latest stable release of MOST software" What any distribution has to do is remain reliable and usable to the installed userbase above all. This apache 2.2/2.4 situation is somewhat of an aberration, but you need to think about this from a logistical/usability standpoint. Think about the sheer number of apache 2.2 installs, some very complex. Forcing a knee-jerk move to 2.4 requires every user with a 2.2 install to set aside the time and resources required to pick through the changelogs, and implement configuration changes to each and every Arch apache 2.2 site in existence, and then to troubleshoot the unintended consequences of the changes. With apache being the supporting software for numerous groupware and e-commerce sites, the economic impact is not trivial. The 2.2->2.4 update represents a "major" update to crucial parts of apache including: o removal of modules mod_authn_default, mod_authz_default, mod_mem_cache o All load balancing moved to individual, self-contained mod_proxy submodules o --> significant changes in authorization configuration <-- o removal of AuthzLDAPAuthoritative, AuthzDBDAuthoritative, etc... o numerous modules and options have been renamed see: http://httpd.apache.org/docs/2.4/upgrading.html Arch is bleeding edge, much to my chagrin at times, but I fully support the conservative approach being taken with regard to apache 2.2/2.4. If you just have to have 2.4 right now, then it is simple to install, go do it. Don't push a whole distribution to jump forward to the latest apache release where there is a real-world downside of breakage to the installed userbase. On 7/9/13 there was a discussion about whether Arch was appropriate for use with servers, see: "[arch-general] Arch Linux on servers?". That is the crux of this issue. Arch, while remaining at the "bleeding edge", must provide sane updates that do not break or destroy critical applications jolting the userbase to implement time-consuming and costly updates. To Arch's credit, they do a darn good job striking a balance, but it is a balance nonetheless between usability, reliability and bleeding-edge. Without reliability and usability for core server applications, a distribution is relegated to being nothing more than a desktop plaything for hobbyists or enthusiasts. For something as fundamental to server operations as apache, Arch should continue to provide 2.2 as the core package while providing 2.4 in testing for an extended period. A clear timeline for the move of 2.4 from testing to core should be developed by reasoned discussion with input from the user base. Once 2.4 moves to core, 2.2 should be maintained in core as (eg. apache22) for so long as support is provided by apache.org. -- David C. Rankin, J.D.,P.E.
