On Thu, Mar 19, 2015 at 12:05 PM, James Bennett <ubernost...@gmail.com> wrote:
> On Wed, Mar 11, 2015 at 3:54 PM, Tim Graham <timogra...@gmail.com> wrote: > >> Having managed the last few security releases for Django, I'll say it's >> one of my least favorite tasks and I'm quite looking forward to dropping >> support for 1.4 (which supports Python 2.5) and 1.6 (Python 2.6). But, if >> there's sufficient interest that we could raise funds to support this >> effort outside of my normal duties as Django fellow, there's a chance you >> could convince me to continue backporting patches and preparing releases >> for these versions. I'm not quite sure how the logistics of such an >> arrangement would work, but just thought I'd throw the idea out there and >> see if anyone is ready to back the effort financially. I'd want the >> endorsement of the core team before finalizing anything. >> > > Way, way, *way* back in the day, there was unofficial bugfix support for > pre-magic-removal versions of Django run on the basis of "some people who > need it step up and do all the work". It was solely done in SVN and never > involved issuing new releases, so anyone running off the maintenance branch > had to just update their checkout whenever a fix landed in it. > > I'm not opposed to allowing that again -- and in fact I was one of the > people who did extended maintenance for pre-m-r Django because my employer > at the time needed it -- but I think we should carefully consider how it's > going to work before trying it, since we no longer have the ability to give > partial commit bits > Agreed that this is an approach we could take - but I don't think the lack of a partial commit bit isn't a major issue IMHO. At a technical level, Git gives anyone the ability to fork Django's repository. There's no *technical* reason that someone couldn't maintain a 1.6 branch *right now* - the only restrictions are that they couldn't call that repository official (as per BSD licensing terms), and they wouldn't have access to security patches until everyone else did. However, both of these are solvable problems. The only thing that makes Django's Github repository "official" is because the core team says it is. If someone wants to take on the task of back porting all the security patches to 1.6, we (as a project) can point to that repository if we want. If we're interested in doing 1.6 support as an "unofficial" subproject, then it seems appropriate to me that the repository *isn't* Django's core repository; picking a third-party vendor's repo sounds like the right way to do it. As for getting the patches ahead of time - I'd be more than happy for an appropriately qualified and trustworthy individual/company to be added to the security pre-notification list. So - it really just comes down to someone having the enthusiasm to maintain the branch. Christian has been around the Django project for a long time (he was a contributor to Django Evolution from very early on, and took over maintenance of the project when I moved on). If he's got a commercial interest in continued 1.6 support, and he can spare a couple of hours to do a backport when a security issue is announced, I'd have no problem adding him to the pre-notification list, and adding some documentation pointing at his fork of Django as an "unofficial 1.6 repository". If Christian hasn't got the time to do this, but he (and/or anyone else) can throw some funds at Tim, Tim is already on the security notification list. Yours Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJxq84-iYS-ayMWnM9j%3DUbNGY3ROO6b_p%2BtBM3LmxhhX7c0mfA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
