Hi there, Now that Wheezy is ehrm virtually released ..., we'd like to reboot the Apache 2.4 transition process as soon as possible. In other words, we'd like to break Sid - as far as Apache is involved - in a foreseeable future. With your permission to proceed as suggested pending, we'd like to propose this procedure to continue with the Apache 2.4 transition:
*) Aim for an upload of Apache 2.4 in June. The exact date is not fixed and determined by two factors: You approving the process itself, and the availability of a 2.4 port for certain reverse dependencies (see next point). *) Since this upload is going to break all existing module reverse dependencies, this causes bad breakage to users of Apache in Sid. We're aware of that, but it can't be avoided entirely since a transition in Experimental only does not seem to work out that well, as we're trying to prod the maintainers of affected packages for over a year. However, to smoothen the transition as much as possible, we'd like to wait with an upload to Sid until these reverse dependencies have updated packages available and then do a coordinated upload with the respective maintainers (they're all CC:-ed): - mod_php - mod_security - mod_wsgi - mod_dnssd (gnome-user-share) - mod_jk - mod_fcgid - subversion This is a somewhat biased choice, based on the popularity of the modules, and their relative importance in the Apache eco-system itself. PHP, and WSGI for example have reverse dependencies on their own, which are affected by our transition, too. Please maintainers of these package, do help us so that we can do the upload in a timely manner. Maintainers, if you need help us to transition with these modules, let the Apache maintainers know. We'll help you. *) Once the package is uploaded to Unstable together with a reasonably small subset of reverse dependencies as defined above, we'd like to successively increase the amount of transitioned packages to a larger amount (see the full list in previous posts) before considering a migration to Testing. It is up to decide together with you when exactly this is going to happen, but I do not suspect this being the case until (end of) summer. At some point we'd like to ask you to remove remaining non-transitioned packages from Testing so that we migrate the already transitioned packages, including our own. Until then, we'd file a "testing migration blocking bug" against our own package, so that it can't migrate to Testing by accident. *) Once the package has reached Testing, we'd like to address a transition of web-applications reverse depending on Apache. This cannot be parallelized easily, because most of them are depending on some other third party module, too. On the upside, web applications are somewhat broken during the migration, but this may only affect the integration of the Apache web server, whereas the application itself remains functional. Does this make sense to you? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D
signature.asc
Description: OpenPGP digital signature