Re: python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED
On Wed, 24 May 2017, Alexander Wirt wrote:
> The policy is pretty clear. Backporting 1.10 and backport the other packages
> too.
>
> It is maybe a problem and maybe we should get the policy changed - I
> personally don't think too. I don't wan't software that isn't in testing in
> backports - but doing it behinds our back is not an option.
This really sounds like we want to have two separate repositories.
The backports repository *is* intended to only backport what’s in
the next stable (plus one for -sloppy). This is also the position
of the backports ftpmasters.
However, there’s a use case of supporting packages where upstream
has a long-term support plan for the version in stable, or some
intermediate version. These are often not suitable for stable as
they add non-security bugfixes as well, which the users of such
branches likely will want to have though. So this calls for a
separate repository (naming it will be a lot of bikeshed) in which
such packages can be tracked.
Most maintainers will still just want to do regular backports,
but for the specific use cases of Django, RT and roundcube,
this new repository would be fine.
One thing is left open by this first look at the problem: the
issue of dependencies of such packages. Again, this proposal
should leave backports alone and also not introduce, say, a
limitation on the upload of dependencies to backports. I’ve not
thought about this much yet, but it seems to me like maintainers
of packages in the new repo ought to use dependencies from stable
and, if necessary, backports, only (using versioned package
relationships to constrain them when necessary) because, if they
add more dependency packages (like python3-typing) there *is* a
*real* problem when upgrading to the next stable (or having the
backports repository active).
This also *directly* calls for a policy that uploading to that
new repository should be limited to the maintainers of the
packages in question because they will *have* to ensure that
the upgrade path to the next stable (including regular backports,
when existent) work correctly. (This, in turn, again prevents
uploads of dependencies to the new repo by maintainers of the
depending packages, without coordination with the maintainers
of the depended-on packages.)
In the python3-typing case, this could be solved by coordinating
with the python3 maintainer instead (to add a Conflicts/Breaks),
in which case python3-typing could be allowed into the new repo
(but still not in backports), if the Release Team allows this in
stretch at this point.
I’m not calling for creating such a new repository at this point
in time (and it’d likely take too long), I just had an idea how
to come out of this misery given both the backports ftpmasters’
position (conservative but not without reason) and the apparent
need for a different solution for a select few packages.
bye,
//mirabilos
--
[17:15:07] Lukas Degener: Kleines Asterix-Latinum für Softwaretechniker:
veni, vidi, fixi(t) ;-)
Reply to: