On Tue, Dec 03, 2013 at 09:37:19AM -0600, David C. Rankin wrote: > 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. Now this is something I can get behind. Servers are not (or should not) be running [testing] or anything of that nature, and so should not be affected by the changes that going to 2.4 in [testing] would bring. However, people with a testing environment would have a clear upgrade path and the ability to test and give feedback to the Arch packagers and maintainers for issues or other things that happen with 2.4 while it's in [testing], instead of just complaining to upstream or that some AUR package is not working. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
Attachment:
pgpV7BZvWtoIJ.pgp
Description: PGP signature
