Felix Schwarz wrote: > 1. Python 2.4 support. RHEL 5 ships 2.4 and is one of the major Linux > distributions out there (especially for shared hosting). Currently I > have problems installing 0.12 on some production servers as they are > still running RHEL 4 (Python 2.3!) which will change in 2012. > RHEL 5 will be supported until 2014 and I'd like to make a point of > supporting it for a couple of years more.
While I understand the idea of stability advertised for RHEL, I wouldn't want to bear the cost of supporting such a policy. I mean, we're two and a half developers here, and we should be doing the work for a multi-million dollar company? I don't see that happen. Red Hat is of course free to provide old patched versions, but I don't want to restrict our available feature set (and therefore development speed) for that. > 3. Long-term support for certain releases. > Currently Fedora EPEL 4/5 (RHEL 5) are shipping trac 0.10, Fedora > EPEL 6 (RHEL 6) will ship 0.11 because of Genshi 0.5. There is > interest from the Fedora/Red Hat side to fix security issues in > these versions. Can you think of a process of doing so? > My main point is that I want to avoid having a couple of custom > patches that every distribution need to maintain themself. I'd like > to gather at least all produced patches in one place (even if they > don't fix all issues). From experience the best place for this is > upstream svn. Now that we have git and Mercurial mirrors of Trac (both trunk and stable branches), why not set up a "security fix" clone and commit the patches there? Another option would be that someone takes over maintenance of "closed" stable branches in SVN. Then again, I agree with Christian in that I would rather encourage distributions to use the latest stable branch instead of patching old versions. Maybe this is just not possible. -- Remy
signature.asc
Description: OpenPGP digital signature
