On 09/03/16 20:33, Kevin Fenzi wrote:
> -b- We re-review Django14 and put it in. However there are 4+
> security problems which can't be fixed without a major version move.
> Because of this , the package may not pass review.
Because it has been retired upstream, I'm not sure if anyone really
looked at that, if there are 2 or really 4 security issues. The most
recent two might have fixes to be even backportable.
For reference, the request for re-review
is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1316068
We actually don't need to review it... if it's been retired less than 2
weeks, we can just unretire it. We do need someone(s) to take over
point of contact though.
I guess I could do it, but is anyone else willing first? :)
Actually, I made the mistake and did not retire it in f22-f24; it
doesn't make sense there at all. Could we consider the package as not
being retired at all?
Once the EPEL6 situation is solved, I should retire it on the previously
named branches.
> -c- We skip re-review in this case and put the package back in. We do
> so with an explicite end of life of 180 days (or 7.3 if that is
> sooner) with either -a- happening or a python27 is packaged AND a
> django 1.8 AND the packages requiring 1.4 are updated to 1.8.
Yeah, a time limit might be nice, but not sure how long all the various
projects need + how long it will take to bring up a python27 + django1.8
Are any folks willing to work on this?
Bringing in python2.7 and Django-1.8 would be the safest bet (in terms
of future stability), but that requires a bit of work, and just bringing
in python2.7 and Django-1.8 is the smallest portion here.
Matthias