Re: python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED
Hi,
* Thorsten Glaser <t.glaser@tarent.de> [2017-05-24 14:06:31 CEST]:
> 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.
Thanks a lot for your insight and your time writing this up. This
sounds like the perfect solution somehow. I'm in love with that
suggestion. Thanks for sharing your point of view.
So long,
Rhonda
P.S.: Just in case, this is in no way meant sarcastic, I really love
this. :)
--
Fühlst du dich mutlos, fass endlich Mut, los |
Fühlst du dich hilflos, geh raus und hilf, los | Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los |
Reply to: