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

Re: Bug#1007717: Updated draft resolution



Hi,

On Wed, Jun 15, 2022 at 04:06:55PM +0200, Lucas Nussbaum wrote:
> If you look at Debian 'testing' only, I think that the only remaining
> way to do that is 1.0 + quilt (packages that were using dpatch have all
> been converted or removed from testing).

That's good. I wasn't able to locate a counter example. Yet, the
situation is not quite what I'd like it to be.

Let me pull some example:
 * Manually stacking patches on top of 3.0 (quilt):
   https://sources.debian.org/src/libreoffice/1:7.3.4%7Erc2-1/debian/rules/?hl=2048#L2048
 * dpatch in unstable, but not testing:
   https://sources.debian.org/src/qmc/0.94-4/debian/rules/?hl=11#L3
 * cdbs patchsys in unstable, but not testing:
   https://sources.debian.org/src/sdic/2.1.3-22.1/debian/rules/?hl=5#L5
 * cdbs patchsys in testing:
   https://sources.debian.org/src/byacc-j/1.15-1.1/debian/rules/?hl=10#L10
   https://sources.debian.org/src/phnxdeco/0.33-3.1/debian/rules/?hl=7#L7
   https://sources.debian.org/src/aview/1.3.0rc1-9.1/debian/rules/?hl=20#L20
 * 3.0 (quilt) with custom patch system:
   https://sources.debian.org/src/golang-github-rogpeppe-go-internal/1.8.1-1/debian/rules/?hl=9#L9
   Also the known ones: curl, gcc, glibc

Yet, it shows that quite some progress has been made on improving
consistency. Thank you for that work.

> According to https://udd.debian.org/~lucas/format10.cgi (which is based
> on what lintian knows about the archive), there are 114 packages using
> 1.0 with quilt. However, 67 of those are maintained by the Debian X
> team. If you plan to discontinue 1.0+patch-system in the context of
> this bug, it would probably be a good idea to have a discussion with
> them to better understand their use case.

Those Debian X packages at least provide internal (to the team)
consistency. Their workflow is a bit unique in that upstream commits may
be cherry picked directly and all other changes should use quilt
patches. I'm inclined to agree that telling X people they must switch
their workflow is not a useful outcome here. On the other hand, we're
giving non-binding advice here and that advice is a recommendation.

In any case, your argument makes 4c a more attractive option to me. Keep
in mind though that the rationale given in 4c, does not really cover the
Debian X workflow. So it may still be read as a recommendation for
Debian X to change (or not).

> I personally think that it would be enough for this bug to issue a clear
> statement that we want to move away from 1.0 unless there's a good
> reason, on a per-package basis, not to. That would create a mandate to
> work on surveying the remaining packages and identifying the remaining
> use cases. That would also allow motivated volunteers to work on
> migrating the remaining packages when there's no reason to stay with
> 1.0, using the NMU procedure if needed.

Indeed, and I do agree that 4c is such a clear statement. I would like
to see a stronger statement here, but Sam et al. tried to gain consensus
on that and there wasn't. So the CTTE advice probably shouldn't override
that non-consensus. That makes 4c a lot more of an attractive option to
me. Finally, the main conflicting parties in this issue (oversimplified)
were Lucas and Ian, so if 4c is strong enough for Lucas, that's good as
well.

I hereby withdraw my intention to extend the ballot as sent by Sean on
June 7th.

Thanks for bearing with me and bringing those arguments forward.

Helmut


Reply to: