Discussion to be continued on django-developers: https://groups.google.com/d/topic/django-developers/69fOquu8v-U/discussion
On Thursday, March 19, 2015 at 12:18:46 PM UTC-4, Carl Meyer wrote: > > On 03/19/2015 01:01 AM, Russell Keith-Magee wrote: > > On Thu, Mar 19, 2015 at 12:05 PM, James Bennett <ubern...@gmail.com > <javascript:> > > <mailto:ubern...@gmail.com <javascript:>>> wrote: > > 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. > > I agree with all of this. I think that the Django core team will not > provide this extended support for 1.6 (because it gives the impression > that Python 2.6 is a supported and secure platform, which is only true > for the subset of our user base on certain extended-support distros), > and I don't think that extended-support releases of 1.6 should or will > ever appear on pypi.python.org/pypi/Django. > > But I think that anyone who feels the need for this extended support can > feel free to raise the resources to make it happen and do it in a github > fork. If someone planning to maintain such a fork applied for > pre-notification of security releases, and could demonstrate significant > support for their effort, I would be in favor of that application. > > And I think that if "that person" ends up being Tim Graham, as an > individual outside of his duties as Django Fellow, that's his choice and > I don't see any problem with it. We've already established a precedent, > several times over, for members of the core team to be paid for certain > tasks that parts of the community need or want that aren't getting done > otherwise. I would not support the DSF or Django core team sponsoring > the fundraising for this effort, but if a part of the community raises > the funds and Tim wants to accept said funds and do the work, more power > to him, as long as it doesn't detract from his other work as Django > Fellow. > > Carl > > -- 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/8690f24e-0318-40d4-ae8e-7089032332fe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
