Re: NMUs: Do we want to Require or Recommend DH
Hello, On Fri 24 May 2019 at 04:01PM +02, Lucas Nussbaum wrote: > Hi, > > On 14/05/19 at 14:30 -0400, Sam Hartman wrote: >> I think there's a fairly clear consensus emerging that it's worth having >> things to check when making a build system conversion. Looking at >> debdiff, ditherscope and reproducibility of the build all appear to be >> important things to consider in such a case. >> >> So, I think there is an emerging consensus against the idea of people >> NMUing a package simply to convert it to dh. >> >> First, I'd like to explicitly call for any last comments from people who >> would >> like to see us permit NMUs simply to move packages toward dh. Are there >> any cases in which such an NMU should be permitted? > > Our NMU policy (Sec 5.11.1 of developers-reference[1]) tries hard to Note that nothing in dev-ref is binding on developers, so I think it's a bit misleading to use the term 'policy'. All of dev-ref is guidelines. Otherwise, I think your summary of what dev-ref says about NMUs is correct. -- Sean Whitton signature.asc Description: PGP signature
Re: NMUs: Do we want to Require or Recommend DH
Hi, On 14/05/19 at 14:30 -0400, Sam Hartman wrote: > I think there's a fairly clear consensus emerging that it's worth having > things to check when making a build system conversion. Looking at > debdiff, ditherscope and reproducibility of the build all appear to be > important things to consider in such a case. > > So, I think there is an emerging consensus against the idea of people > NMUing a package simply to convert it to dh. > > First, I'd like to explicitly call for any last comments from people who would > like to see us permit NMUs simply to move packages toward dh. Are there > any cases in which such an NMU should be permitted? Our NMU policy (Sec 5.11.1 of developers-reference[1]) tries hard to give some standards of when and how it's acceptable to do an NMU. It is complex, but in the end, I think that it boils down to: NMUs are always permitted, but discouraged in some (many?) cases, and extensive use of the DELAYED queue is recommended. It also explicitely discourages NMUs for packaging style changes: > Fixing cosmetic issues or changing the packaging style (e.g. switching > from cdbs to dh) in NMUs is discouraged. Do you want to change this and explicitely forbid NMUs for converting to dh? I think that the current policy is quite balanced (but I'm biaised since I contributed to its adoption a long time ago :) ). I also think that we should trust the judgement of DDs, and that completely forbidding some changes via NMUs would be a regression compared to the current policy. - Lucas [1] https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu
Re: NMUs: Do we want to Require or Recommend DH
On Wed, May 15, 2019 at 03:22:16PM +0200, Andreas Tille wrote: On Wed, May 15, 2019 at 02:09:14PM +0200, Benjamin Drung wrote: Am Mittwoch, den 15.05.2019, 11:31 +0200 schrieb Enrico Zini: Or introduce a lintian check for not using dh. Then the maintainer could override lintian and document the reason for it in the override. ... but I think the documented lintian override is better since it is more connected to code than free text. I agree; also, the new lintian check/warning showing up in places like Tracker may help adoption of the documentation (as an override) to happen across the distribution more quickly. -- Jonathan Dowland
Re: NMUs: Do we want to Require or Recommend DH
On Wed, May 15, 2019 at 11:31:46AM +0200, Enrico Zini wrote: >... > - if a package has had an inactive and unresponsive maintainer for a >long time, it would indeed be a case for salvaging. > >I could however imagine someone having enough energy to dust off old >packages in the archive, while not having enough energy to pick up >maintenance of lots of old dusty packages. Does the person have the energy to properly test that the changes don't cause any regressions? Uploading invasive changes in packages you don't use is usually a bad idea, and if it ain't broken don't fix it. >I would consider the idea of salvaging+orphaning, like following the >salvaging procedure but setting the maintainer to qa instead. >... Such salvaging+orphaning instead of following the proper MIA process would be abusive behaviour. Even more if it is just for a packaging change that would be expected to result in the same binary packages. In the worst case you get a pissed off maintainer leaving the project, and an orphaned package with some RC regression caused by the change. Without any actual benefits of the whole change. > With a consensus of having dh as the default build system, and the > understanding that some packages have good reasons not to use dh, I'd > like a way to tell when a package is not using dh for a reason, from > when a package is not using dh because the maintainer has not gotten > around to it yet. > > I'd propose to recommend dh as the default build system, and document in > README.source if there are reasons to use something else. > > At that point, one could look at README.source to see if changing build > system would be an possible strategy for fixing bugs in an NMU. >... There's a much easier (and faster!) solution that has already been used in the past: For migrating away from dpatch someone made the changes to the packages, and then sent the debdiffs to the BTS. If the maintainer liked the change, it was applied. If the maintainer was MIA, the patch was applied whenever the package was orphaned later. For a standard conversion to 3-line dh not much is lost if some of the patches end up being rejected. For non-trivial conversions it also sets the right incentive that the person doing the change contacts the maintainer first, NMU plus revert of the NMU would be a solution inferior to asking the maintainer before doing plenty of work. > Enrico 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
Re: NMUs: Do we want to Require or Recommend DH
Hi, On Wed, May 15, 2019 at 02:09:14PM +0200, Benjamin Drung wrote: > Am Mittwoch, den 15.05.2019, 11:31 +0200 schrieb Enrico Zini: > > I'd propose to recommend dh as the default build system, and document > > in README.source if there are reasons to use something else. > > > > At that point, one could look at README.source to see if changing > > build system would be an possible strategy for fixing bugs in an NMU. The README.source idea is good ... > Or introduce a lintian check for not using dh. Then the maintainer > could override lintian and document the reason for it in the override. ... but I think the documented lintian override is better since it is more connected to code than free text. Kind regards Andreas. -- http://fam-tille.de
Re: NMUs: Do we want to Require or Recommend DH
Enrico Zini writes ("Re: NMUs: Do we want to Require or Recommend DH"):
> I'd propose to recommend dh as the default build system, and document in
> README.source if there are reasons to use something else.
>
> At that point, one could look at README.source to see if changing build
> system would be an possible strategy for fixing bugs in an NMU.
This is a great idea. Obviously such a policy/process change would
have to come with a significant lead time so that everyone would have
a chance to do an upload with an appropriate README.source.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: NMUs: Do we want to Require or Recommend DH
Am Mittwoch, den 15.05.2019, 11:31 +0200 schrieb Enrico Zini: > I'd propose to recommend dh as the default build system, and document > in README.source if there are reasons to use something else. > > At that point, one could look at README.source to see if changing > build system would be an possible strategy for fixing bugs in an NMU. Or introduce a lintian check for not using dh. Then the maintainer could override lintian and document the reason for it in the override. -- Benjamin Drung System Developer Debian & Ubuntu Developer 1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Head Office: Berlin, Germany District Court Berlin Charlottenburg, Registration number: HRB 125506 B Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss Member of United Internet
Re: NMUs: Do we want to Require or Recommend DH
Quoting Enrico Zini (2019-05-15 11:31:46) > On Tue, May 14, 2019 at 02:30:52PM -0400, Sam Hartman wrote: > > > How do we feel about people making build system conversions when > > those conversion make it easier to fix some other bug that they are > > fixing as part of an NMU? > > That is, imagine that a package is mishandling the combination of > > systemd units and an init script. As someone preparing an NMU, is > > it reasonable to move to dh compat 12 from some other build system > > if I believe doing so will make it easier for me to fix the bug and > > verify the fix? > > I see various scenarios: > > - if a package is generally actively maintained, except the >maintainer is currently unresponsive for some reason and there is a >RC bug to fix, I could understand frowning upon a build system >conversion in an NMU. > > - if a package has bugs that can all be fixed trivially with a build >system conversion, I would see no reason not to do such a >conversion, even in an NMU. > > - a change of build system in a complex package would be more >controversial than in a trivial package. > > - if a package has had an inactive and unresponsive maintainer for a >long time, it would indeed be a case for salvaging. > >I could however imagine someone having enough energy to dust off >old packages in the archive, while not having enough energy to pick >up maintenance of lots of old dusty packages. > >I would consider the idea of salvaging+orphaning, like following >the salvaging procedure but setting the maintainer to qa instead. > > - I'd say that orphaned packages can be uncontroversially be >converted to dh. Very well said. I agree ith all of it. > With a consensus of having dh as the default build system, and the > understanding that some packages have good reasons not to use dh, I'd > like a way to tell when a package is not using dh for a reason, from > when a package is not using dh because the maintainer has not gotten > around to it yet. > > I'd propose to recommend dh as the default build system, and document > in README.source if there are reasons to use something else. > > At that point, one could look at README.source to see if changing > build system would be an possible strategy for fixing bugs in an NMU. Great suggestion! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: NMUs: Do we want to Require or Recommend DH
On Tue, May 14, 2019 at 02:30:52PM -0400, Sam Hartman wrote: > How do we feel about people making build system conversions when those > conversion make it easier to fix some other bug that they are fixing as > part of an NMU? > That is, imagine that a package is mishandling the combination of > systemd units and an init script. As someone preparing an NMU, is it > reasonable to move to dh compat 12 from some other build system if I > believe doing so will make it easier for me to fix the bug and verify > the fix? I see various scenarios: - if a package is generally actively maintained, except the maintainer is currently unresponsive for some reason and there is a RC bug to fix, I could understand frowning upon a build system conversion in an NMU. - if a package has bugs that can all be fixed trivially with a build system conversion, I would see no reason not to do such a conversion, even in an NMU. - a change of build system in a complex package would be more controversial than in a trivial package. - if a package has had an inactive and unresponsive maintainer for a long time, it would indeed be a case for salvaging. I could however imagine someone having enough energy to dust off old packages in the archive, while not having enough energy to pick up maintenance of lots of old dusty packages. I would consider the idea of salvaging+orphaning, like following the salvaging procedure but setting the maintainer to qa instead. - I'd say that orphaned packages can be uncontroversially be converted to dh. With a consensus of having dh as the default build system, and the understanding that some packages have good reasons not to use dh, I'd like a way to tell when a package is not using dh for a reason, from when a package is not using dh because the maintainer has not gotten around to it yet. I'd propose to recommend dh as the default build system, and document in README.source if there are reasons to use something else. At that point, one could look at README.source to see if changing build system would be an possible strategy for fixing bugs in an NMU. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: NMUs: Do we want to Require or Recommend DH
Quoting Scott Kitterman (2019-05-15 04:47:48) > > > On May 15, 2019 1:13:52 AM UTC, Paul Wise wrote: > >On Wed, May 15, 2019 at 2:31 AM Sam Hartman wrote: > > > >> How do we feel about people making build system conversions when > >> those conversion make it easier to fix some other bug that they are > >> fixing as part of an NMU? > > > >If the maintainer is MIA enough to not express an opinion when asked > >if adding a dh conversion to the NMU is fine, probably the package > >should be orphaned/salvaged instead of NMUed, which would bring the > >dh conversion into scope. > > I'd think the timeline for that would be longer than the week or two > it takes to do an NMU. Yes the timeline of an NMU being short is the very issue as I see it: Switching build system may be easy to do but less easy to maintain for the maintainer - regardless of popularity in general. No, major package refactoring like change of build system is unacceptable in NMUs, because it strongly affects long-term maintenance. Real underlying question seems instead to be this: Do we tolerate maintainers using a "wrong" packaging style - i.e. an unpopular style fewer find easy to do NMUs for? Yes, let's recommend what is popular. But not this. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: NMUs: Do we want to Require or Recommend DH
On May 15, 2019 1:13:52 AM UTC, Paul Wise wrote: >On Wed, May 15, 2019 at 2:31 AM Sam Hartman wrote: > >> How do we feel about people making build system conversions when >those >> conversion make it easier to fix some other bug that they are fixing >as >> part of an NMU? > >If the maintainer is MIA enough to not express an opinion when asked >if adding a dh conversion to the NMU is fine, probably the package >should be orphaned/salvaged instead of NMUed, which would bring the dh >conversion into scope. I'd think the timeline for that would be longer than the week or two it takes to do an NMU. Scott K
Re: NMUs: Do we want to Require or Recommend DH
On Wed, May 15, 2019 at 2:31 AM Sam Hartman wrote: > How do we feel about people making build system conversions when those > conversion make it easier to fix some other bug that they are fixing as > part of an NMU? If the maintainer is MIA enough to not express an opinion when asked if adding a dh conversion to the NMU is fine, probably the package should be orphaned/salvaged instead of NMUed, which would bring the dh conversion into scope. -- bye, pabs https://wiki.debian.org/PaulWise
Re: NMUs: Do we want to Require or Recommend DH
On Tue, May 14, 2019 at 02:30:52PM -0400, Sam Hartman wrote: >... > How do we feel about people making build system conversions when those > conversion make it easier to fix some other bug that they are fixing as > part of an NMU? What happens if the maintainer dislikes the change? The maintainer clearly has the right to revert such an NMU, and the opinion about the NMU expressed in the changelog or elsewhere might not be friendly. There might be cases where it is appropriate, but I wouldn't issue a general recommendation to do build system conversions in NMUs. > That is, imagine that a package is mishandling the combination of > systemd units and an init script. As someone preparing an NMU, is it > reasonable to move to dh compat 12 from some other build system if I > believe doing so will make it easier for me to fix the bug and verify > the fix? Doing a build system conversion properly requires first understanding what the old build system did, and later verifying that the changes didn't break anything. It might bring long-term benefits, but if anyone claims that for an NMU this is easier than a minimal fix I strongly suspect it is only easy due to lack of diligence. > --Sam 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
Re: NMUs: Do we want to Require or Recommend DH
Hi Sam, On Tue, May 14, 2019 at 02:30:52PM -0400, Sam Hartman wrote: > So, I think there is an emerging consensus against the idea of people > NMUing a package simply to convert it to dh. > > First, I'd like to explicitly call for any last comments from people who would > like to see us permit NMUs simply to move packages toward dh. I admit despite I'm in big favour of having the majority of packages converted to dh I would not feel my time well spent to browse the archive for packages that might be "smelling" like candidates. > Are there > any cases in which such an NMU should be permitted? If a package has a RC bug or some important bug that annoys me for a certain reason and fixing it would be easier by just doing a dh conversion is a pretty good candidate for me. Or if I need to touch such a package and the conversion is obviously very simple I would like to do so. I will do so in case I'm a member of the team that maintains the package without question - otherwise I'd give the maintainer a warning and ask for permission (but will usually write something like "If I do not hear from you in X days I assume you agree with this.") > Finally, I'd like to focus discussion on an area where emerging > consensus is much less clear. > > How do we feel about people making build system conversions when those > conversion make it easier to fix some other bug that they are fixing as > part of an NMU? That's one of the cases I mentioned above. > That is, imagine that a package is mishandling the combination of > systemd units and an init script. As someone preparing an NMU, is it > reasonable to move to dh compat 12 from some other build system if I > believe doing so will make it easier for me to fix the bug and verify > the fix? Good example for a valid dh conversion. Kind regards Andreas. -- http://fam-tille.de
Re: NMUs: Do we want to Require or Recommend DH
I think there's a fairly clear consensus emerging that it's worth having things to check when making a build system conversion. Looking at debdiff, ditherscope and reproducibility of the build all appear to be important things to consider in such a case. So, I think there is an emerging consensus against the idea of people NMUing a package simply to convert it to dh. First, I'd like to explicitly call for any last comments from people who would like to see us permit NMUs simply to move packages toward dh. Are there any cases in which such an NMU should be permitted? Finally, I'd like to focus discussion on an area where emerging consensus is much less clear. How do we feel about people making build system conversions when those conversion make it easier to fix some other bug that they are fixing as part of an NMU? That is, imagine that a package is mishandling the combination of systemd units and an init script. As someone preparing an NMU, is it reasonable to move to dh compat 12 from some other build system if I believe doing so will make it easier for me to fix the bug and verify the fix? --Sam
