[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED



    Hi,

* Raphael Hertzog <hertzog@debian.org> [2017-05-24 10:25:19 CEST]:
> On Wed, 24 May 2017, Alexander Wirt wrote:
> > 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. 
> 
> How do we fix the policy then?
> 
> Maintaining a version that is older than the current version in testing
> and that is newer than the current version in stable ought to be allowed.

 How so, "ought to be allowed".  It was always clearly communicated that
that's not the way backports is working, or should.  And yet you chose
to ignore that and try to use that as a leverage to have it your way.
I'm very sorry but that's not the way proper communication happens.

 I'm very sorry to the users of python-django, but I see an ignorance to
the rules for which you requested your upload rights and a clear failure
to communicate that.

 Thing that Scott raised: LTS support for backports for such packaging
approaches can under no circumstances be carried by the LTS team.  What
could be possible for them is following when some update happens in
$stable to add it to $oldstable-backports because the diff is expected
to be minimal.  If we have versions in $oldstable-backports that have no
connection whatsoever to the version we have in $stable then that can't
simply be taken over by others.  The effort to maintain that further is
immensly higher.

 I can see that you might be willing to carry that extra burden for your
own sake, but it leaves the burden to be able to maintain it in cases
you lose interest very high, if not very impractical.  This is the
reason we speak very vocally against having that changed.

 Also given that we have well over 25% of the packages that currently
sit in jessie-backports not in sync with the upstream version from
stretch is something that I consider highly alarming.  A fair amount of
those packages got uploaded to be (build-)dependencies of other packages
in backports.  I see a very low commitment to maintain packages properly
in backports, and adding another layer of maintenance hell onto it won't
fix that in any sense.

 As long as we can't even get the packages maintained in a useful state
as they are now in the archive already I am very unwilling to discuss
any further exceptions that would make the maintainability of packages
within backports even less likely, not improve it.  If you are unwilling
to maintain your packages according to the rules, please let me know
right ahead and we can discuss on how to reduce the damage done through
removals from the archive and the ACL file.

 So long,
Rhonda
-- 
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: