Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Uwe Kleine-König]

Hello Raphael,

On 05/24/2017 09:46 PM, Raphael Hertzog wrote:
> On Wed, 24 May 2017, Uwe Kleine-König wrote:
>> With my model that would be:
>>
>>  - sid/testing has both, latest version and latest LTS (including
>>security)
>>  - jessie-backports strictly follows django-lts and so shouldn't be
>>much of a headache.
>- $stable has both
>- $oldstable has both
> 
> So for every new security issues affecting all versions, we have 7 to 8 
> uploads
> to make instead of 4.

ok, so the charm to have the current release not in the archive but
somewhere separate (be it experimental or something else) is that you
don't need to handle security updates. If that is the case, this version
isn't really usable (from my POV). Maybe only to test if my application
works with it. Otherwise I either want my application to work with
Django LTS and so stick to that during development, or I use virtualenv
in which case I don't even need the lts package.

My 2 cents
Uwe



signature.asc
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Debian FTP Masters]

Signature for changes file was already seen at 2017-05-20 15:05:48.551935.
Please refresh the signature of the changes file if you want to upload it again.



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Ian Campbell]

On Thu, 2017-05-25 at 17:41 +1000, Brian May wrote:
> Ian Campbell  writes:
> 
> > Yet 1.10.x is going to be in Stretch, according to [0]? If users
> > want
> > LTS then why aren't we shipping that in our upcoming stable release
> > (whether its instead of or in addition to the latest release)?
> 
> In general the Django LTS releases occur after on a cycle, several
> months after the Debian Freeze.
> 
> Django 1.11 LTS was released in April 2017 for example. Even if we
> could
> get Django 1.11 in the freeze, as Raphael Hertzog was suggesting in
> another email, not sure how the release team would feel about this -
> and
> it would be up to them I think. There may be ways to ease the pain,
> however it would still be up to the release team.
> 
> I seem to recall the same thing happened when Django 1.8 LTS was
> released, Jessie was already in freeze.
> 
> The alternative option is that we use the previous LTS Django
> release. However, that would mean Jessie would still be on Django 1.4,
> which lost upstream support in 2015.

Jessie actually shipped with (non LTS) 1.7 which left support extended
support on December 1 2015, which is not all that different from the
end of extended support for 1.4 which was October 1, 2015.

> Similarly, if Stretch was released with 1.8 LTS (yes I know, this is not
> really an option anymore), Django 1.8 will loose support April next year
> - when Stretch is still supported.

Stretch is actually shipping 1.10 which ends December 2017, compared
with 1.8 which is "at least April 2018", so 1.8 is at least a bit
longer.

> We would basically be releasing Debian with a old LTS version of Django
> that is obsolete before Debian is even released.

The reality is we are shipping non-LTS versions which expire around the
same sort of times as the LTS version du-jour at the time of release.

Ian.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Adrian Bunk]

On Thu, May 25, 2017 at 05:41:39PM +1000, Brian May wrote:
> Ian Campbell  writes:
> 
> > Yet 1.10.x is going to be in Stretch, according to [0]? If users want
> > LTS then why aren't we shipping that in our upcoming stable release
> > (whether its instead of or in addition to the latest release)?
> 
> In general the Django LTS releases occur after on a cycle, several
> months after the Debian Freeze.
> 
> Django 1.11 LTS was released in April 2017 for example. Even if we could
> get Django 1.11 in the freeze, as Raphael Hertzog was suggesting in
> another email, not sure how the release team would feel about this - and
> it would be up to them I think. There may be ways to ease the pain,
> however it would still be up to the release team.
> 
> I seem to recall the same thing happened when Django 1.8 LTS was
> released, Jessie was already in freeze.
> 
> The alternative option is that we use the previous LTS Django
> release. However, that would mean Jessie would still be on Django 1.4,
> which lost upstream support in 2015.
> 
> Similarly, if Stretch was released with 1.8 LTS (yes I know, this is not
> really an option anymore), Django 1.8 will loose support April next year
> - when Stretch is still supported.
> 
> We would basically be releasing Debian with a old LTS version of Django
> that is obsolete before Debian is even released.

So what are you planning for buster?

The options seem to be:
- 1.11 LTS (already released, supported until April 2020), or
- 2.1 non-LTS (released in August 2018, supported until December 2019)

The full freeze of buster is expected to start in December 2018,
so when 2.2 LTS gets released in April 2019 buster is expected
to be just a few weeks away from being released.

It is pretty obvious that this makes 2.2 LTS a non-option for buster.

I fully agree that neither option is nice, but you have to make that 
decision for buster.

stable is supposed to be stable and backports a workaround when a user
has a good reason for cherry-picking packages from the next stable.

If stable contains the non-LTS version that is less popular in your 
ecosystem and backports contains the more popular LTS, then that's
not how it is supposed to be.

One positive aspect of "old LTS version":

Django 1.11 will be eligible for stretch-backports one or few weeks 
after the release of stretch.

With the "1.11 LTS in buster" option, a user upgrading to 1.11 from 
stretch-backports will get up to 7 years security support for 1.11
from Debian.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Brian May]

Ian Campbell  writes:

> Yet 1.10.x is going to be in Stretch, according to [0]? If users want
> LTS then why aren't we shipping that in our upcoming stable release
> (whether its instead of or in addition to the latest release)?

In general the Django LTS releases occur after on a cycle, several
months after the Debian Freeze.

Django 1.11 LTS was released in April 2017 for example. Even if we could
get Django 1.11 in the freeze, as Raphael Hertzog was suggesting in
another email, not sure how the release team would feel about this - and
it would be up to them I think. There may be ways to ease the pain,
however it would still be up to the release team.

I seem to recall the same thing happened when Django 1.8 LTS was
released, Jessie was already in freeze.

The alternative option is that we use the previous LTS Django
release. However, that would mean Jessie would still be on Django 1.4,
which lost upstream support in 2015.

Similarly, if Stretch was released with 1.8 LTS (yes I know, this is not
really an option anymore), Django 1.8 will loose support April next year
- when Stretch is still supported.

We would basically be releasing Debian with a old LTS version of Django
that is obsolete before Debian is even released.

Reference: https://www.djangoproject.com/download/
-- 
Brian May 

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Rhonda D'Vine]

   Hi,

* Raphael Hertzog  [2017-05-24 21:01:39 CEST]:
> On Wed, 24 May 2017, Rhonda D'Vine wrote:
> >  He actively chose to ignore the guidelines, and actively chose to not
> > communicate about that.  That's very disappointing, for everyone.
> 
> I apologize for doing (what I believe to be) the right thing behind your
> back. But the way you treated me today is precisely the reason why I did
> not ask in the first place. *shrug*

 Erm, whut?  So you acknowledge that you did intentionally did that
behind our back?  Knowingly?  Seriously?  And you believe that we should
trust you in any way still?

 Sorry, I just ... can't.  I can't.
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|

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Russ Allbery]

Jan Ingvoldstad  writes:

> As a Debian user, I have learned not to use backports for anything
> important because, let's face it, I'm *toast* if I do so.

> I have griped about the backports security policy years ago, and others
> have, too, but you and Alexander shoot any constructive criticism down
> with frankly very off-putting, negative, unconstructive responses.

This is completely absurd.  I have used backports for production packages
for years, including packages for which I need security updates.  You are
being far too absolutist and, by doing so, insulting to the hard work that
people put into maintaining backports.

It is true that the security support in backports is *not as good* and
*not as reliable* as the (best-in-class) security support offered for the
main Debian distribution.  This is fine, or at least entirely expected.
Fewer resources go into backports, and the person maintaining the backport
has primary responsibility for security, without the support of a regular
security team.  You need to go into this with your eyes open.  However, it
is absolutely not the case that you're "toast" if there's a security
issue; you can ask that it be fixed, or you can even fix it yourself!

My experience is that the security support for Debian backports is still
better than the security support for, say, Ubuntu universe in an LTS
release, which people use in production without a second thought despite
the fact that the security guarantees are nearly non-existent and the
support is often dire.  The standard you're applying here is much too
high.

-- 
Russ Allbery (r...@debian.org)   

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Raphael Hertzog]

On Wed, 24 May 2017, Uwe Kleine-König wrote:
> With my model that would be:
> 
>  - sid/testing has both, latest version and latest LTS (including
>security)
>  - jessie-backports strictly follows django-lts and so shouldn't be
>much of a headache.
   - $stable has both
   - $oldstable has both

So for every new security issues affecting all versions, we have 7 to 8 uploads
to make instead of 4.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Uwe Kleine-König]

Hello Raphael,

On 05/24/2017 09:15 PM, Raphael Hertzog wrote:
> On Wed, 24 May 2017, Uwe Kleine-König wrote:
>> An alternative idea would be to have two separate (source) packages in
>> sid: django and django-lts. Then django-lts could be put into backports
>> and so maintained according to the backport policy.
> 
> I don't really like the idea of a separate source package, it means more
> security work, a lot of headaches for dependencies, upgrades, etc.

I cannot follow here. Current state is:

 - sid/testing has latest version (including security work)
 - jessie-backports has latest LTS (including security work)

With my model that would be:

 - sid/testing has both, latest version and latest LTS (including
   security)
 - jessie-backports strictly follows django-lts and so shouldn't be
   much of a headache.

So the only downside I see is that there might be differences between
django-lts in sid/testing and django-lts in backports. For some packages
it is possible to not have any differences, not sure how the situation
is in this case.

Do I miss something?

> In my opinion, the only good solution is the following:
> - maintain only LTS versions in unstable/testing
> - keep non-LTS versions in experimental
> 
> Most of the (bigger) reverse dependencies of Django are interested in LTS
> versions (or are at least expected to work with the latest LTS version).

So packages are free to depend on django (i.e. latest version) or
django-lts or django | django-lts. Sounds flexible and great. (Ok, on
the other hand more chances to make something wrong.)

Best regards
Uwe



signature.asc
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Raphael Hertzog]

Hello,

On Wed, 24 May 2017, Uwe Kleine-König wrote:
> An alternative idea would be to have two separate (source) packages in
> sid: django and django-lts. Then django-lts could be put into backports
> and so maintained according to the backport policy.

I don't really like the idea of a separate source package, it means more
security work, a lot of headaches for dependencies, upgrades, etc.

In my opinion, the only good solution is the following:
- maintain only LTS versions in unstable/testing
- keep non-LTS versions in experimental

Most of the (bigger) reverse dependencies of Django are interested in LTS
versions (or are at least expected to work with the latest LTS version).

Ideally we would make efforts to have a recent LTS version in new stable
releases of Debian. The upstream schedule is a bit off with Debian's
current schedule but they make a promise that if your application runs
without any warning in LTS, then it will also run in LTS+1. So we should
run plenty of checks on all applications available in Debian unstable with
the current LTS.

https://docs.djangoproject.com/en/1.11/internals/release-process/#internal-release-deprecation-policy

With that in place, we could "safely" upload an LTS+1 pre-release in testing
just before the freeze and negotiate with the release team to upload
future point releases to stable.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Raphael Hertzog]

On Wed, 24 May 2017, Rhonda D'Vine wrote:
> > Then we have similar issues as the ones raised by Raphael, where the life
> > of the package maintainer is made difficult.
> 
>  He actively chose to ignore the guidelines, and actively chose to not
> communicate about that.  That's very disappointing, for everyone.

I apologize for doing (what I believe to be) the right thing behind your
back. But the way you treated me today is precisely the reason why I did
not ask in the first place. *shrug*

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Uwe Kleine-König]

Hello,

On 05/24/2017 02:06 PM, Thorsten Glaser wrote:
> 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.

An alternative idea would be to have two separate (source) packages in
sid: django and django-lts. Then django-lts could be put into backports
and so maintained according to the backport policy.
Maybe it should be named django-lts1.8 just in case a new upstream LTS
should be packaged but the former should stay in testing and backports.

Best regards
Uwe





signature.asc
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Ian Campbell]

On Wed, 2017-05-24 at 13:19 +0200, Raphael Hertzog wrote:
> On Wed, 24 May 2017, Ian Campbell wrote:
> > Yet 1.10.x is going to be in Stretch, according to [0]? If users
> > want
> > LTS then why aren't we shipping that in our upcoming stable release
> > (whether its instead of or in addition to the latest release)?
> 
> Because of miscommunication between the Django maintainers and also
> because we hoped to get 1.11 (LTS too) in stretch with some preparation
> work (but that preparation work never happened).

That's unfortunate (the more so from what Neil seems to be saying about
upgrades), but water under the bridge now I guess.

Ian.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Thorsten Glaser]

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) ;-)

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Jan Ingvoldstad]

On Wed, May 24, 2017 at 1:04 PM, Ian Campbell  wrote:
>
> Yet 1.10.x is going to be in Stretch, according to [0]? If users want
> LTS then why aren't we shipping that in our upcoming stable release
> (whether its instead of or in addition to the latest release)?
>
>
This happens with a lot of Debian packages, and the answer lies somewhere
in the decision process that happens during testing leading up to a freeze.

For instance, even though PHP 7.1 was released and recognized as
(reasonably) stable a long time before the Stretch freeze, the PHP
maintainers opted to stay with PHP 7.0, even though this means backporting
security updates for 3.5 years after PHP 7.0 security support ends upstream
(a schedule that was known at the time the decision was made). Okay, PHP
7.1 isn't an upstream LTS, either, and it's not clear whether PHP will have
another LTS after PHP 5.6, but that's not really uncommon for upstreams.

PHP is also a fairly complex package set to maintain, with all its modules,
and I gather from hints dropped here that Django is, too, so lagging behind
the latest release even if it was released before testing freeze, is just
the way it goes.

-- 
Jan
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Jan Ingvoldstad]

On Wed, May 24, 2017 at 1:12 PM, Rhonda D'Vine  wrote:

> * Jan Ingvoldstad  [2017-05-24 12:02:18 CEST]:
> > On Wed, May 24, 2017 at 11:54 AM, Rhonda D'Vine  wrote:
> > > * Jan Ingvoldstad  [2017-05-24 11:37:49 CEST]:
> > > > Basically: if you need security updates, don't rely on backports,
> don't
> > > put
> > > > things in backports. The backport policy is incompatible with keeping
> > > > systems up-to-date and secure.
> > >
> > >  That's a highly unfair statement.  The backport policy is the reason
> > > that maintainers are unwilling to update their backports?  Come on,
> > > that's a very very low blow and not a constructive comment.
> >
> >
> > Well, let's look at what the Debian Security FAQ says:
> >
> > *Q: How is security handled for testing?*
> >
> [...]
> > So, as a general principle, security updates are delayed, sometimes by
> two
> > days, sometimes more.
>
>  Right.  And backports could (and should) have the security updates in
> the same timeframe (or earlier) as testing.  That possibility is
> actively hindered if the version in backports does differ from that.
> With the upload exception for fast-tracking of security issues backports
> should have it even faster than testing, that's the idea behind it.
>
>
> > Then we have similar issues as the ones raised by Raphael, where the life
> > of the package maintainer is made difficult.
>
>  He actively chose to ignore the guidelines, and actively chose to not
> communicate about that.  That's very disappointing, for everyone.
>

Is this point really necessary to spend more time on? Should I have avoided
mentioning Raphael by name in order to get the basic point across?



>
> > As a Debian user, I have learned not to use backports for anything
> > important because, let's face it, I'm *toast* if I do so.
>
>  The same goes for testing.
>

Quite so.

Yet you seem to think this is an "unfair" and "low blow" assessment. Why
was it unfair and low blow?


>
> > I have griped about the backports security policy years ago, and others
> > have, too, but you and Alexander shoot any constructive criticism down
> with
> > frankly very off-putting, negative, unconstructive responses.
>
>  I have actively worked with the security team to get backports
> integrated into the security tracker, to be able to ease the job of
> tracking issues.  I've also actively poked people to update their
> backports, and in case they didn't have the time I offered to do the
> upload.  That was before I got into the team.  And that was *only*
> possible because packages were kept in sync on a more or less regular
> basis.
>
>  Unfortunately it looks like many decided to move away from there,
> without communication, which is highly depressing, and yes, I can see
> that it is perceived as negative unconstructive response to a
> non-communication approach by those maintainers.


I think you misunderstand. In my experience, it's the negative and
unconstructive responses to constructive criticism of both the policy and
implementation of the policy that's the problem.

This is the principal reason why I never became a Debian package maintainer
- the responses here are poisonous to those of us who might have a little
bit of time to contribute something.

So instead, we contribute (a little) outside of the community.


>   That very approach
> which stirred these discussions was very unconstructive and negative to
> start off with.  If you consider it only constructive to accept that
> people ignore the rules then I'm very sorry, I'm not available for that.
> What I am very much available is to have a discussion on equal grounds
> and *not* on a forcing-my-view-by-ignoring-the-rules level.
>

I don't see that discussion happening. I don't see any willingness to look
beyond that initial slight made by Raphael, instead this is a repeated
hangup in this discussion, and it's very obviously not leading anywhere
useful to you, to the maintainers, or to us, the users.


>
> > This is why users tend to go to dotdeb and other external package
> > repositories for updated packages. We do it for PHP, we do it for Puppet,
> > we do it for MariaDB, MySQL, etc. The backports policy and/or the way
> > backports are practically handled are in the way.
>
>  Again, it's not the backports policy that hinders the security updates.
>

Huh, you seemed to agree that it was, earlier in your response.


> It's the opinion of backporters that actively ignore that policy and see
> their own approach which actively works against the policy to be the
> only way to get this resolved, and refuse to communicate or coordinate
> beforehand to see how to move forward.  The rules are there for a reason
> - to actually *ease* the possibility to get security fixes in, not to
> make it harder.
>

Well, they *do* make it harder. Added complexity and constraints to what
may be uploaded means that you have a pretty long window of opportunity for
attacks between upstream updates and implementation of these fixes. The
"fa

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Ian Campbell]

On Wed, 2017-05-24 at 12:53 +0200, Raphael Hertzog wrote:
> On Wed, 24 May 2017, Holger Levsen wrote:
> > On Wed, May 24, 2017 at 12:32:13PM +0200, Raphael Hertzog wrote:
> > > Right now, I'm maintaining 1.8.x in jessie-backports, we have
> > > 1.10.x in
> > > stretch. If I disappear and nobody else is willing to maintain
> > > 1.8.x, you
> > > can just backport 1.10.x from stretch into jessie-backports and
> > > you will
> > > be fine.
> > 
> >  
> > why don't you upload 1.10 to jessie-backports?
> 
> It's not an LTS version and most users just want the LTS version. Most
> applications are going to be tested against LTS versions and not against
> non-LTS versions.

Yet 1.10.x is going to be in Stretch, according to [0]? If users want
LTS then why aren't we shipping that in our upcoming stable release
(whether its instead of or in addition to the latest release)?

Ian.

[0] https://tracker.debian.org/pkg/python-django

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Jan Ingvoldstad]

On Wed, May 24, 2017 at 1:34 PM, Adrian Bunk  wrote:

> On Wed, May 24, 2017 at 01:00:41PM +0200, Raphael Hertzog wrote:
> > On Wed, 24 May 2017, Adrian Bunk wrote:
> >...
> > > Imagine someone else would have done the python-django backport,
> > > and would upload 1.10 to jessie-backports today.
> > > What would you as user do?
> >
> > You are again diverting the discussion to another problem. This is
> > not my situation... in the general case, the user can't rely on
> > the version in jessie-backports to not change in backwards incompatible
> > way.
>
> This is not a diversion, this is actually the core of the problem.
>
> Should backports follow a general and predictable policy,
> or should they follow whatever suits best the personal
> usecase of the developer doing the backport?
>
>
Backports should follow a policy that makes it attractive to use for users,
and attractive to contribute to for maintainers.

A general and predictable policy is a means towards that end, to be sure.

However, "the personal usecase of the developer doing the backport" is a
strawman in this discussion.

-- 
Jan
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Adrian Bunk]

On Wed, May 24, 2017 at 01:00:41PM +0200, Raphael Hertzog wrote:
> On Wed, 24 May 2017, Adrian Bunk wrote:
>...
> > Imagine someone else would have done the python-django backport,
> > and would upload 1.10 to jessie-backports today.
> > What would you as user do?
> 
> You are again diverting the discussion to another problem. This is
> not my situation... in the general case, the user can't rely on
> the version in jessie-backports to not change in backwards incompatible
> way.

This is not a diversion, this is actually the core of the problem.

Should backports follow a general and predictable policy,
or should they follow whatever suits best the personal
usecase of the developer doing the backport?

> Cheers,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Rhonda D'Vine]

* Raphael Hertzog  [2017-05-24 13:00:41 CEST]:
> On Wed, 24 May 2017, Adrian Bunk wrote:
> > If the person who did two years ago the jessie backport of a package 
> > used by DSA retired from Debian a year ago or is one of the many MIA 
> > developers, how are the machines maintained by DSA kept secure today?
> 
> Adrian, you keep diverting the discussion to something entirely else.
> I'm stopping here. You are bringing into light known problems
> that have currently no good answers. But those problems exist with
> the current policy already. So they are irrelevant in the discussion
> of my requested change. My request is not making that worse
> or better.

 No, Adrian doesn't do that, that's a very core point.  The way you
handle it noone is able to pick up the package in the way you do it
without serious effort.  You are the user of the package and thus have
the very internal motivation to keep it there.  If you are gone noone is
able to pick it up because it doesn't follow the rules.  It is very much
not irrelevant, as much as you like to claim that.

> > Imagine someone else would have done the python-django backport,
> > and would upload 1.10 to jessie-backports today.
> > What would you as user do?
> 
> You are again diverting the discussion to another problem. This is
> not my situation... in the general case, the user can't rely on
> the version in jessie-backports to not change in backwards incompatible
> way.

 But that's what you like to accomplish with your backport.  It's again
no divergating.

> But I'm the maintainer and I can promise more than the baseline. I can
> tell my users "I will keep maintaining the current LTS version as long as
> it's support upstream" in $stable-backports.

 You are still a single person, and goddess forbids anything bad happens
to you but you might move away from that area at some point.  This is
not hypothetical, this has happened in the past.  People had to pick up
backports because the former people didn't care for it.  And you are
putting the maintenance overhead for maintaing a package that is nowhere
else in the archive but only in backports over the possibility to keep
it in low maintenance state.

 Just because you don't like the arguments of others doesn't mean that
they aren't there, so please try to not ridiculate them.

 Enjoy,
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|

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Raphael Hertzog]

On Wed, 24 May 2017, Ian Campbell wrote:
> Yet 1.10.x is going to be in Stretch, according to [0]? If users want
> LTS then why aren't we shipping that in our upcoming stable release
> (whether its instead of or in addition to the latest release)?

Because of miscommunication between the Django maintainers and also
because we hoped to get 1.11 (LTS too) in stretch with some preparation
work (but that preparation work never happened).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Rhonda D'Vine]

* Jan Ingvoldstad  [2017-05-24 12:02:18 CEST]:
> On Wed, May 24, 2017 at 11:54 AM, Rhonda D'Vine  wrote:
> > * Jan Ingvoldstad  [2017-05-24 11:37:49 CEST]:
> > > Basically: if you need security updates, don't rely on backports, don't
> > put
> > > things in backports. The backport policy is incompatible with keeping
> > > systems up-to-date and secure.
> >
> >  That's a highly unfair statement.  The backport policy is the reason
> > that maintainers are unwilling to update their backports?  Come on,
> > that's a very very low blow and not a constructive comment.
> 
> 
> Well, let's look at what the Debian Security FAQ says:
> 
> *Q: How is security handled for testing?*
> 
[...]
> So, as a general principle, security updates are delayed, sometimes by two
> days, sometimes more.

 Right.  And backports could (and should) have the security updates in
the same timeframe (or earlier) as testing.  That possibility is
actively hindered if the version in backports does differ from that.
With the upload exception for fast-tracking of security issues backports
should have it even faster than testing, that's the idea behind it.


> Then we have similar issues as the ones raised by Raphael, where the life
> of the package maintainer is made difficult.

 He actively chose to ignore the guidelines, and actively chose to not
communicate about that.  That's very disappointing, for everyone.

> As a Debian user, I have learned not to use backports for anything
> important because, let's face it, I'm *toast* if I do so.

 The same goes for testing.

> I have griped about the backports security policy years ago, and others
> have, too, but you and Alexander shoot any constructive criticism down with
> frankly very off-putting, negative, unconstructive responses.

 I have actively worked with the security team to get backports
integrated into the security tracker, to be able to ease the job of
tracking issues.  I've also actively poked people to update their
backports, and in case they didn't have the time I offered to do the
upload.  That was before I got into the team.  And that was *only*
possible because packages were kept in sync on a more or less regular
basis.

 Unfortunately it looks like many decided to move away from there,
without communication, which is highly depressing, and yes, I can see
that it is perceived as negative unconstructive response to a
non-communication approach by those maintainers.  That very approach
which stirred these discussions was very unconstructive and negative to
start off with.  If you consider it only constructive to accept that
people ignore the rules then I'm very sorry, I'm not available for that.
What I am very much available is to have a discussion on equal grounds
and *not* on a forcing-my-view-by-ignoring-the-rules level.

> This is why users tend to go to dotdeb and other external package
> repositories for updated packages. We do it for PHP, we do it for Puppet,
> we do it for MariaDB, MySQL, etc. The backports policy and/or the way
> backports are practically handled are in the way.

 Again, it's not the backports policy that hinders the security updates.
It's the opinion of backporters that actively ignore that policy and see
their own approach which actively works against the policy to be the
only way to get this resolved, and refuse to communicate or coordinate
beforehand to see how to move forward.  The rules are there for a reason
- to actually *ease* the possibility to get security fixes in, not to
make it harder.

> Until this changes, it's security 101 to stay away from backports, sorry.

 There is no security team for backports indeed, as there is none for
testing neither.  The approach for testing is just easier because it has
this very strict rule as that it ultimately can only have packages from
unstable moving over.  The more relaxed possibility for backports (and
human mistakes in accepting such uploads) is the cause of this issue,
not the solution.

 Enjoy,
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|

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Raphael Hertzog]

On Wed, 24 May 2017, Adrian Bunk wrote:
> > This is because backports maintainers are expected to keep the packages
> > they upload there as secure.
> 
> "are expected" != "are actually doing"
> 
> > If the rules are not allowing us to do that, then the rules are bad.
> 
> The biggest general problems are not the rules.
> 
> If the person who did two years ago the jessie backport of a package 
> used by DSA retired from Debian a year ago or is one of the many MIA 
> developers, how are the machines maintained by DSA kept secure today?

Adrian, you keep diverting the discussion to something entirely else.
I'm stopping here. You are bringing into light known problems
that have currently no good answers. But those problems exist with
the current policy already. So they are irrelevant in the discussion
of my requested change. My request is not making that worse
or better.

> Imagine someone else would have done the python-django backport,
> and would upload 1.10 to jessie-backports today.
> What would you as user do?

You are again diverting the discussion to another problem. This is
not my situation... in the general case, the user can't rely on
the version in jessie-backports to not change in backwards incompatible
way.

But I'm the maintainer and I can promise more than the baseline. I can
tell my users "I will keep maintaining the current LTS version as long as
it's support upstream" in $stable-backports.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Raphael Hertzog]

On Wed, 24 May 2017, Holger Levsen wrote:
> On Wed, May 24, 2017 at 12:32:13PM +0200, Raphael Hertzog wrote:
> > Right now, I'm maintaining 1.8.x in jessie-backports, we have 1.10.x in
> > stretch. If I disappear and nobody else is willing to maintain 1.8.x, you
> > can just backport 1.10.x from stretch into jessie-backports and you will
> > be fine.
>  
> why don't you upload 1.10 to jessie-backports?

It's not an LTS version and most users just want the LTS version. Most
applications are going to be tested against LTS versions and not against
non-LTS versions.

(Besides, tracker.debian.org is not ready for 1.10.x while it has been
tested with 1.8.x.)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Adrian Bunk]

On Wed, May 24, 2017 at 11:55:45AM +0200, Raphael Hertzog wrote:
> On Wed, 24 May 2017, Jan Ingvoldstad wrote:
> > Basically: if you need security updates, don't rely on backports, don't put
> > things in backports. The backport policy is incompatible with keeping
> > systems up-to-date and secure.
> [...] 
> > I strongly recommend not using backports for anything else, and certainly
> > not in production.
> 
> This is not in line with DSA's policy. If we need anything newer than
> stable for a service hosted by DSA, then we have to use packages in
> stable-backports.
> 
> This is because backports maintainers are expected to keep the packages
> they upload there as secure.

"are expected" != "are actually doing"

> If the rules are not allowing us to do that, then the rules are bad.

The biggest general problems are not the rules.

If the person who did two years ago the jessie backport of a package 
used by DSA retired from Debian a year ago or is one of the many MIA 
developers, how are the machines maintained by DSA kept secure today?

> That said, just because we need something newer and secure, does not mean
> that we always want to track every major update from testing during the
> whole lifetime of stable-backports.

Let's go away from the special case where you are both the backport 
maintainer and the user, and look at the general problem.

The policy change you want would permit maintaining 1.8 in 
jessie-backports, but it would still allow the normal way
of uploading 1.10 from stretch to jessie-backports.

Imagine someone else would have done the python-django backport,
and would upload 1.10 to jessie-backports today.
What would you as user do?

Using a package from backports is supposed to allow tracking that
specific package from testing in stable without upgrading everything
else to testing.

It cannot guarantee the stability of not changing in incompatible 
ways you can expect from a package in stable.

> Cheers,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Holger Levsen]

On Wed, May 24, 2017 at 12:32:13PM +0200, Raphael Hertzog wrote:
> Right now, I'm maintaining 1.8.x in jessie-backports, we have 1.10.x in
> stretch. If I disappear and nobody else is willing to maintain 1.8.x, you
> can just backport 1.10.x from stretch into jessie-backports and you will
> be fine.
 
why don't you upload 1.10 to jessie-backports?


-- 
cheers,
Holger


signature.asc
Description: Digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Holger Levsen]

Dear Raphael,

what I miss in your reactions here is an apology for not discussing this with
the backports admins before uploading those backports. (And the point is *not*
to apologize but rather to acknowledge that this was the wrong cause of
action.)

Of course rules might have flaws and should be improved, but just not caring
about them and violating them (even for good reasons) doesn't send a good
message.


-- 
cheers,
Holger


signature.asc
Description: Digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Raphael Hertzog]

On Wed, 24 May 2017, Adrian Bunk wrote:
> This part of the policy continues with:
> 
>   If your package had a security update you can upload a new backport 
>   even if its not yet in testing. If you have good reasons to update a 
>   package which is already is in backports with a newer version from 
>   unstable (which is intended for testing),
> 
> The "should" and "exceptions" you quote only permit to backport
> a package from unstable that is not yet in testing.

That's not so clear. When you give a rationale, it has a meaning. It means
that's what you really care about. And the should is then a
recommendation aka "the best way to ensure  is by doing X".

> There are plenty of examples of packages currently in backports proving 
> that "it's up to the backport maintainer" is not working - like versions
> more recent than in jessie in wheezy-backports, or backports that cannot
> be installed because the backport maintainer built them against stretch
> packages.

What's your point? Of course maintainers are humans, they do mistakes in
unstable and they do mistakes in *-backports. How is this related with my
request and this discussion?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Raphael Hertzog]

Hi,

I'm ignoring the personal attack and threats of ACL removal because that
does not bring the discussion further, but I want to highlight that you
could have avoided this, I have not said anything bad about your work, I'm
just discussing the policy.

On Wed, 24 May 2017, Rhonda D'Vine wrote:
>  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.

When upstream is still maintaining the branch that is currently in
$oldstable-backports, the effort is not immensively higher, no.

And furthermore since we have an upgrade path from $oldstable-backports
to $stable, we can always decide to stop maintaining the LTS branch
in $oldstable-backports and bump straight to a backport of $stable.

Right now, I'm maintaining 1.8.x in jessie-backports, we have 1.10.x in
stretch. If I disappear and nobody else is willing to maintain 1.8.x, you
can just backport 1.10.x from stretch into jessie-backports and you will
be fine.

>  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.

This is not true, cf above.

>  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.

The fact that they are not in sync is not highly alarming as long as the
package is not affected by open CVE.

You take this as a sign of "low commitment". Now you have a committed
maintainer in front of you. You should be happy. Why are you not trying to
support his work instead of blindly refusing his security updates because
they do not come from testing?

Since I need Django 1.8.x in jessie-backports (for installation by DSA on
tracker.debian.org), I could have uploaded 1.8.5 and stopped there. But
I'm actually trying to follow the backport policy of keeping the package
secure. And you are punishing me for this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Jan Ingvoldstad]

On Wed, May 24, 2017 at 11:54 AM, Rhonda D'Vine  wrote:

> * Jan Ingvoldstad  [2017-05-24 11:37:49 CEST]:
> > Basically: if you need security updates, don't rely on backports, don't
> put
> > things in backports. The backport policy is incompatible with keeping
> > systems up-to-date and secure.
>
>  That's a highly unfair statement.  The backport policy is the reason
> that maintainers are unwilling to update their backports?  Come on,
> that's a very very low blow and not a constructive comment.


Well, let's look at what the Debian Security FAQ says:

"*Q: How is security handled for unstable?*
A: Security for unstable is primarily handled by package maintainers, not
by the Debian Security Team. Although the security team may upload
high-urgency security-only fixes when maintainers are noticed to be
inactive, support for stable will always have priority. If you want to have
a secure (and stable) server you are strongly encouraged to stay with
stable.

*Q: How is security handled for testing?*

A: Security for testing benefits from the security efforts of the entire
project for unstable. However, there is a minimum two-day migration delay,
and sometimes security fixes can be held up by transitions. The Security
Team helps to move along those transitions holding back important security
uploads, but this is not always possible and delays may occur. Especially
in the months after a new stable release, when many new versions are
uploaded to unstable, security fixes for testing may lag behind. If you
want to have a secure (and stable) server you are strongly encouraged to
stay with stable."
So, as a general principle, security updates are delayed, sometimes by two
days, sometimes more.

Then we have similar issues as the ones raised by Raphael, where the life
of the package maintainer is made difficult.

As a Debian user, I have learned not to use backports for anything
important because, let's face it, I'm *toast* if I do so.

I have griped about the backports security policy years ago, and others
have, too, but you and Alexander shoot any constructive criticism down with
frankly very off-putting, negative, unconstructive responses.

This is why users tend to go to dotdeb and other external package
repositories for updated packages. We do it for PHP, we do it for Puppet,
we do it for MariaDB, MySQL, etc. The backports policy and/or the way
backports are practically handled are in the way.

Until this changes, it's security 101 to stay away from backports, sorry.
-- 
Jan
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Adrian Bunk]

On Wed, May 24, 2017 at 11:40:54AM +0200, Raphael Hertzog wrote:
> On Wed, 24 May 2017, Adrian Bunk wrote:
> > The maintainer of the python-django backport not acting according to
> > policy is what started this discussion.
> 
> Let's speak of the policy. It says this:
> > To guarantee an upgrade path from stable+backports to the next stable, the
> > package should be in testing..
> 
> https://backports.debian.org/Contribute/
> 
> It does not say "the package MUST be in testing", it says SHOULD and gives
> a rationale. All my python-django packages have a working upgrade path
> from stable+backports to testing.
> 
> So in fact, I'm not breaking the policy. Even better, the next line says
> this:
> > Of course there are some exceptions: Security updates.
> 
> I initially uploaded a version that was in testing and all the subsequent
> uploads I made were security updates (in the form of upstream point
> releases).
> 
> Honestly, I really think that I'm fully in the spirit of the backport
> policy and that this rejection is unwarranted.

This part of the policy continues with:

  If your package had a security update you can upload a new backport 
  even if its not yet in testing. If you have good reasons to update a 
  package which is already is in backports with a newer version from 
  unstable (which is intended for testing),

The "should" and "exceptions" you quote only permit to backport
a package from unstable that is not yet in testing.

> > > If someone reports that it does not work, the maintainer must fix his
> > > package.
> > 
> > This cannot fix the version in a Replaces or a postinst version check
> > in the package in the next stable.
> 
> Most of the time, the next stable is not yet released, so obviously we can
> fix things. And if it's already released (as for wheezy-backports
> currently), then it's up to the backport maintainer to check that the
> upgrade path works.

There are plenty of examples of packages currently in backports proving 
that "it's up to the backport maintainer" is not working - like versions
more recent than in jessie in wheezy-backports, or backports that cannot
be installed because the backport maintainer built them against stretch
packages.

> Cheers,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Raphael Hertzog]

On Wed, 24 May 2017, Jan Ingvoldstad wrote:
> Basically: if you need security updates, don't rely on backports, don't put
> things in backports. The backport policy is incompatible with keeping
> systems up-to-date and secure.
[...] 
> I strongly recommend not using backports for anything else, and certainly
> not in production.

This is not in line with DSA's policy. If we need anything newer than
stable for a service hosted by DSA, then we have to use packages in
stable-backports.

This is because backports maintainers are expected to keep the packages
they upload there as secure.

If the rules are not allowing us to do that, then the rules are bad.

That said, just because we need something newer and secure, does not mean
that we always want to track every major update from testing during the
whole lifetime of stable-backports.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Rhonda D'Vine]

* Jan Ingvoldstad  [2017-05-24 11:37:49 CEST]:
> Basically: if you need security updates, don't rely on backports, don't put
> things in backports. The backport policy is incompatible with keeping
> systems up-to-date and secure.

 That's a highly unfair statement.  The backport policy is the reason
that maintainers are unwilling to update their backports?  Come on,
that's a very very low blow and not a constructive comment.

 Enjoy,
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|

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Rhonda D'Vine]

Hi,

* Raphael Hertzog  [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|

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Raphael Hertzog]

On Wed, 24 May 2017, Adrian Bunk wrote:
> The maintainer of the python-django backport not acting according to
> policy is what started this discussion.

Let's speak of the policy. It says this:
> To guarantee an upgrade path from stable+backports to the next stable, the
> package should be in testing..

https://backports.debian.org/Contribute/

It does not say "the package MUST be in testing", it says SHOULD and gives
a rationale. All my python-django packages have a working upgrade path
from stable+backports to testing.

So in fact, I'm not breaking the policy. Even better, the next line says
this:
> Of course there are some exceptions: Security updates.

I initially uploaded a version that was in testing and all the subsequent
uploads I made were security updates (in the form of upstream point
releases).

Honestly, I really think that I'm fully in the spirit of the backport
policy and that this rejection is unwarranted.

> > If someone reports that it does not work, the maintainer must fix his
> > package.
> 
> This cannot fix the version in a Replaces or a postinst version check
> in the package in the next stable.

Most of the time, the next stable is not yet released, so obviously we can
fix things. And if it's already released (as for wheezy-backports
currently), then it's up to the backport maintainer to check that the
upgrade path works.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Jan Ingvoldstad]

On Wed, May 24, 2017 at 11:17 AM, Adrian Bunk  wrote:

> On Wed, May 24, 2017 at 11:01:41AM +0200, Raphael Hertzog wrote:
> > On Wed, 24 May 2017, Adrian Bunk wrote:
> > > What is the minimum amount of technical checking that has to be in
> place
> > > before something like this could be done?
> >
> > For the backports team, none. For the maintainer, he must know this
> policy
> > and act accordingly.
>
> The maintainer of the python-django backport not acting according to
> policy is what started this discussion.
>

s/started/reignited/

This is a discussion that crops up every once in a while, and usually
quickly gets killed off.


Basically: if you need security updates, don't rely on backports, don't put
things in backports. The backport policy is incompatible with keeping
systems up-to-date and secure.

Backports are somewhat useful for testing packages from testing in stable.

I strongly recommend not using backports for anything else, and certainly
not in production.

-- 
Jan
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Adrian Bunk]

On Wed, May 24, 2017 at 11:01:41AM +0200, Raphael Hertzog wrote:
> On Wed, 24 May 2017, Adrian Bunk wrote:
> > What is the minimum amount of technical checking that has to be in place 
> > before something like this could be done?
> 
> For the backports team, none. For the maintainer, he must know this policy
> and act accordingly.

The maintainer of the python-django backport not acting according to
policy is what started this discussion.

> If someone reports that it does not work, the maintainer must fix his
> package.
>...

This cannot fix the version in a Replaces or a postinst version check
in the package in the next stable.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Raphael Hertzog]

On Wed, 24 May 2017, Adrian Bunk wrote:
> What is the minimum amount of technical checking that has to be in place 
> before something like this could be done?

For the backports team, none. For the maintainer, he must know this policy
and act accordingly.

If someone reports that it does not work, the maintainer must fix his
package.

> There might be problems if the package in the next stable makes in its 
> dependencies or pre/postinst any assumptions about which versions ever 
> existed.

So add a new criteria:
- maintaining intermediary versions in *-backports must be made
  with the main maintainer's consent

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Adrian Bunk]

On Wed, May 24, 2017 at 10:25:19AM +0200, Raphael Hertzog wrote:
> 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.
> 
> Criteria:
> - must not break upgrade to next stable or testing
>...

What is the minimum amount of technical checking that has to be in place 
before something like this could be done?

piuparts checking of every package before it gets accepted into backports?

There might be problems if the package in the next stable makes in its 
dependencies or pre/postinst any assumptions about which versions ever 
existed.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Alexander Wirt]

On Wed, 24 May 2017, Raphael Hertzog wrote:

> 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?
It it your oppinion that its broken. 

Alex


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Raphael Hertzog]

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.

Criteria:
- must not break upgrade to next stable or testing
- version must be supported (either by Debian maintainer or upstream)

And as I said, you are causing me unnecessary troubles to keep
tracker.debian.org secure. Can you allow me to continue doing
this at least until this discussion on updating the policy is
settled?

Thank you.
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Alexander Wirt]

On Tue, 23 May 2017, Scott Kitterman wrote:

> 
> 
> On May 23, 2017 5:28:04 PM EDT, Alexander Wirt  wrote:
> >On Tue, 23 May 2017, Raphael Hertzog wrote:
> >
> >> (please cc me on answers)
> >> 
> >> On Tue, 23 May 2017, Debian FTP Masters wrote:
> >> > please take the version from testing, not a version that never was
> >in the archive
> >> 
> >> I have been maintaining the 1.8.x LTS version of Django in
> >jessie-backports since
> >> December 2015.
> >> 
> >> Except the very first, none of the 1.8.x versions that I uploaded in
> >> jessie-backports have been in testing.
> >> 
> >> Please let me continue providing this service to our users.
> >> 
> >> Why are you suddenly acting on this upload and not the formers?
> >You didn't followed the often stated policy. Full stop. We just never
> >noticed. 
> >
> >We stated that several times and you just decided that policy does not
> >count
> >for you. I think that is pretty unfair. 
> 
> There are security fixes in this upload.  What's the way to get those fixed?  
> Backporting 1.10 isn't an option because it is incompatible with many other 
> packages.
> 
> Would cherry-picked security fixes be okay?
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. 

Alex


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Scott Kitterman]

On May 23, 2017 5:28:04 PM EDT, Alexander Wirt  wrote:
>On Tue, 23 May 2017, Raphael Hertzog wrote:
>
>> (please cc me on answers)
>> 
>> On Tue, 23 May 2017, Debian FTP Masters wrote:
>> > please take the version from testing, not a version that never was
>in the archive
>> 
>> I have been maintaining the 1.8.x LTS version of Django in
>jessie-backports since
>> December 2015.
>> 
>> Except the very first, none of the 1.8.x versions that I uploaded in
>> jessie-backports have been in testing.
>> 
>> Please let me continue providing this service to our users.
>> 
>> Why are you suddenly acting on this upload and not the formers?
>You didn't followed the often stated policy. Full stop. We just never
>noticed. 
>
>We stated that several times and you just decided that policy does not
>count
>for you. I think that is pretty unfair. 

There are security fixes in this upload.  What's the way to get those fixed?  
Backporting 1.10 isn't an option because it is incompatible with many other 
packages.

Would cherry-picked security fixes be okay?

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Alexander Wirt]

On Tue, 23 May 2017, Raphael Hertzog wrote:

> (please cc me on answers)
> 
> On Tue, 23 May 2017, Debian FTP Masters wrote:
> > please take the version from testing, not a version that never was in the 
> > archive
> 
> I have been maintaining the 1.8.x LTS version of Django in jessie-backports 
> since
> December 2015.
> 
> Except the very first, none of the 1.8.x versions that I uploaded in
> jessie-backports have been in testing.
> 
> Please let me continue providing this service to our users.
> 
> Why are you suddenly acting on this upload and not the formers?
You didn't followed the often stated policy. Full stop. We just never
noticed. 

We stated that several times and you just decided that policy does not count
for you. I think that is pretty unfair. 

Alex
 

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Raphael Hertzog]

(please cc me on answers)

On Tue, 23 May 2017, Debian FTP Masters wrote:
> please take the version from testing, not a version that never was in the 
> archive

I have been maintaining the 1.8.x LTS version of Django in jessie-backports 
since
December 2015.

Except the very first, none of the 1.8.x versions that I uploaded in
jessie-backports have been in testing.

Please let me continue providing this service to our users.

Why are you suddenly acting on this upload and not the formers?

The Debian package tracker runs currently on this Django version and I
would like to be able to provide security updates for DSA and for users
who rely on this version (Scott Kitterman pinged me because he needed
that update).

In the same way, I would like to maintain the 1.11.x LTS branch in
stretch-backports in the future.

Thank you.

PS: I know this this is not 100% conformant to your rules. But there
are zero drawbacks in me using jessie-backports in that way. Most Django
users want a LTS release and unfortunately, our schedule does not match
Django's schedule very well so we never have the desired version in
stable.
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Debian FTP Masters]

please take the version from testing, not a version that never was in the 
archive




===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team