Le jeudi, 6 décembre 2018, 19.03:57 h CET Paul Elliott a écrit :
> You guys must be developing under sid, and never checking that your
> releases will actually build under the various stable releases.

Exactly.  And it allows removing _a lot_ of unneeded complexity.  As hplip 
packager, I provide new upstream releases tailored towards the _next_ stable 
release.  The "staging" area for this is `unstable`.  It will then migrate to 
`testing` (aka `buster`).

Backporting these new upstream releases is a _different_ and _additional_ 
work.  There's absolutely zero requirement for packages uploaded to `unstable` 
to build without modifications on other releases.

> But your branches are still named for the various stable versions,
> that is, debian/stretch-backports, debian/stretch, debian/jessie-backports,
> debian/jessie.

Yes. These build on the corresponding target suites.  They don't necessarily 
integrate the latest upstream releases (nor should they).

> But you never check that these commits will actually build for these
> versions.

No, we don't.  Doing so would be _a lot_ of unneeded work.

But upon request, packages can be adapted to target specific suites; that's 
precisely what *-backports suites are.  That's why I uploaded a _modified_ 
hplip 3.18.10+dfsg0-3 to the `stretch-backports` suite.  That upload was 
accepted today and is in the process of being built for all architectures.


Stretch users will be able to get the latest hplip by using the `stretch-
backports` suite additionally to their standard APT setup.


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to