Bug#1007717: Updated draft resolution
Hello, On Fri 17 Jun 2022 at 02:45am +02, gregor herrmann wrote: > Well, yes, sure. > That would all be nice. > But issuing some advice about 1.0-with-or-without-dpatch or whatever > doesn't really change anything for them. Indeed, we have somewhat drifted off-topic :) > Oh, right, I totally agree that for all practical reasons the > practical source of most of the packages I upload are in a salsa > git repo. > > But that's completely irrelevant. > What's relevant for Debian are some *.orig.tar.gz *.debian.tar.xz > *.dsc an some web mirrors. I don't understand -- why would it be irrelevant? -- Sean Whitton
Bug#1007717: Updated draft resolution
> "Helmut" == Helmut Grohne writes: Helmut> Indeed, and I do agree that 4c is such a clear statement. I Helmut> would like to see a stronger statement here, but Sam et Helmut> al. tried to gain consensus on that and there wasn't. So the Helmut> CTTE advice probably shouldn't override that Helmut> non-consensus. That makes 4c a lot more of an attractive Helmut> option to me. Actually, I think the TC making a decision when the project is unable to come to consensus is often a great outcome. The TC is one of our decision making options. During my DPL term, the TC did not appear to have the credibility to be a popular option for me to go to when my consensus-making attempts got part of the way. However, if the project is functioning well, I think that the TC is a great option short of a GR. I think that has worked well with usrmerge recently. I DO NOT think this bug is the place for the TC to recommend something like the maintainer view of git source packages should be a patches-unapplied format. I think it would be great if the TC would take that on in a separate bug. If you would like me to pose such a question to the TC I'd be happy to do so. Driving a GR discussion on that issue is too much for me, but posing a question to the TC is within the energy I have available. --Sam signature.asc Description: PGP signature
Bug#1007717: Updated draft resolution
On Thu, 16 Jun 2022 16:56:24 -0700, Sean Whitton wrote: > On Fri 17 Jun 2022 at 01:03AM +02, gregor herrmann wrote: > > And that's what we are talking about: Debian experts building > > packages for Debian. At least that's what my priorities are. > I think Ian might really mean "Debian source package experts". That was not my impression, as he wrote (not quoted in my reply): | One of my friends - an expert programmer (and expert user of git) - | did precisely that, prompting my post. > It ought > to be our goal to make it so that you can be a Debian expert without > being a Debian source package expert. It also seems worth mentioning > that users wanting to apply patches to packages installed on their > systems are also one of priorities. Well, yes, sure. That would all be nice. But issuing some advice about 1.0-with-or-without-dpatch or whatever doesn't really change anything for them. (Again: No criticism of the TC, as there is some question and as there are some, hm, organizational boundaries.) > > And dgit also is just a nice workaround for the problem that the > > canonical source of Debian packages is not Git repo; it pretends that > > there is, and it stumbles across all kinds of corner cases caused by > > how source packages look like nowadays. > I would challenge this idea: at this point, the canonical source of very > many Debian packages is indeed their git repos on salsa. Not all of > them, but very many. Oh, right, I totally agree that for all practical reasons the practical source of most of the packages I upload are in a salsa git repo. But that's completely irrelevant. What's relevant for Debian are some *.orig.tar.gz *.debian.tar.xz *.dsc an some web mirrors. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe signature.asc Description: Digital Signature
Bug#1007717: Updated draft resolution
Hello, On Fri 17 Jun 2022 at 01:03AM +02, gregor herrmann wrote: > And that's what we are talking about: Debian experts building > packages for Debian. At least that's what my priorities are. I think Ian might really mean "Debian source package experts". It ought to be our goal to make it so that you can be a Debian expert without being a Debian source package expert. It also seems worth mentioning that users wanting to apply patches to packages installed on their systems are also one of priorities. > And dgit also is just a nice workaround for the problem that the > canonical source of Debian packages is not Git repo; it pretends that > there is, and it stumbles across all kinds of corner cases caused by > how source packages look like nowadays. I would challenge this idea: at this point, the canonical source of very many Debian packages is indeed their git repos on salsa. Not all of them, but very many. -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: Updated draft resolution
On Wed, 15 Jun 2022 11:08:59 +0100, Ian Jackson wrote:
> Helmut Grohne writes ("Re: Bug#1007717: Updated draft resolution"):
> > Simon looked at how other distributions approach patches and figured
> > that basically everyone else uses the patches-unapplied model.
> patches-unapplied is a good fit for distro experts in distros which
> are still using tarballs-and-patches.
And that's what we are talking about: Debian experts building
packages for Debian. At least that's what my priorities are.
> (IME most Debian insiders severly underestimate the scale of the
> problems faced by a random user who is already a programmer and just
> wants to make some change to a package.)
That's very well possible, but I think we shouldn't prioritize these
"random users who know git but not Debian packaging".
Taking a step back: I think all those idiosyncrasies and the need to
learn weird things to build packages and the impossibility to Just
Use Git are a sad thing and bad for anyone involved. But we won't fix
these problems by adding yet another layer of workarounds and
indirection; unless we can address the problem at its root this will
all be futile.
> Happily, it is possible to reconcile the disagreement about applied vs
> unapplied by automatically converting. dgit, and Sean and my
> tag2upload system, do precisely this, in the "forward" direction,
> which is the most important one.
tag2upload sounds great indeed.
Just that it needs to be accepted at the archive level, i.e. by the
FTPmasters. Until then it's unfortunately "a nice idea". So more
technical work or more advice by the TC won't help in any way.
And dgit also is just a nice workaround for the problem that the
canonical source of Debian packages is not Git repo; it pretends that
there is, and it stumbles across all kinds of corner cases caused by
how source packages look like nowadays.
This is not a criticism of tag2upload or dgit; quite to the contrary
I think that they identify real problems. But they just create
additional layers and try to create workarounds. And that's all they
can do without further (political) changes.
Back to the topic of this bug report: The TC was asked for advice
about source formats (and patch systems), and as their resolution
can't change how the archive works, I very much agree with Helmut
that more uniformity and less pathogenic packages are indeed very
helpful.
And if we want to change the source package basics themselves: Yay,
but that's a different question at a different level.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
signature.asc
Description: Digital Signature
Bug#1007717: Updated draft resolution
Hello, On Thu 16 Jun 2022 at 08:47am +02, Helmut Grohne wrote: > > 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. Cool, thanks for reviewing and confirming that. -- Sean Whitton
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
Bug#1007717: Updated draft resolution
Hello, On Wed 15 Jun 2022 at 04:06PM +02, Lucas Nussbaum wrote: > > 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. Thanks for this info. > 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. I agree that this would be a good outcome, as expressed by your option 4c. -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: Updated draft resolution
Hi, On 15/06/22 at 07:32 +0200, Helmut Grohne wrote: > The other model restricts itself to only adding files below > debian/ and then using debian/rules to actually apply patches during > build. This latter model is fairly annoying, because there are so many > different ways of doing it (i.e. we lack consistency there). 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). > So what I'd like to ensure is that any resolution we do here is clear > about discontinuing the use of 1.0-with-diff together with a patch > system to be applied during package build. We've explored that model in > depth and settled on 3.0 (quilt) as the superior solution. There is no > need to explore it any further (and as demonstrated by curl, gcc and > glibc, you can even turn 3.0 (quilt) ad absurdum). So in my view, the > only reasonable use of 1.0-with-diff is where you manage your diff > externally rather than during package build. 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. 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. Lucas
Bug#1007717: Updated draft resolution
Helmut Grohne writes ("Re: Bug#1007717: Updated draft resolution"):
> Simon looked at how other distributions approach patches and figured
> that basically everyone else uses the patches-unapplied model.
patches-unapplied is a good fit for distro experts in distros which
are still using tarballs-and-patches.
However, for anyone else - particularly, anyone not from a distro
background, it is a serious problem. I wrote about this on my blog:
Get source to Debian packages only via dgit; "official" git links
are beartraps
https://diziet.dreamwidth.org/9556.html
As I say in the blog post, the danger of a user using "official" git
from Salsa, and building a package without the Debian patches applied,
is not theoretical. One of my friends - an expert programmer (and
expert user of git) - did precisely that, prompting my post.
(IME most Debian insiders severly underestimate the scale of the
problems faced by a random user who is already a programmer and just
wants to make some change to a package.)
Happily, it is possible to reconcile the disagreement about applied vs
unapplied by automatically converting. dgit, and Sean and my
tag2upload system, do precisely this, in the "forward" direction,
which is the most important one.
I think it would also be possible to automatically do the reverse
conversion. This could allow a gitlab MR style workflow for a
contributor who started with a patches-applied "naive external
contributor" branch.
The reverse conversion of a user's contribution is of course already
easy to do manually: if your contributor sends you a branch based on
the dgit view[1], you can simply rebase their work onto your gbp pq
branch.
[1] This is difficult for the user right now since the dgit server is
not "forge" and doesn't invite the user to do this. Instead, the user
will probably email patches.
Ian.
Bug#1007717: Updated draft resolution
Re: Helmut Grohne > For the reasons above, I do think we need another variant of 4. Your view makes a lot of sense. Would you think you could draft a "4" variant that summarizes it? I admit I'm lost between all the details and would like a spot to go to, and then look at the alternatives from that viewpoint (or vote for that spot rightaway). Christoph
Bug#1007717: Updated draft resolution
Hi, On Tue, Jun 07, 2022 at 10:31:18PM -0700, Sean Whitton wrote: > Here's an updated ballot in light of our upcoming meeting. I've left > space to add a 4b, if, when our current discussion is concluded, someone > would like that in addition to 4c. After the meeting, Simon, Sean and myself further discussed aspect 4 without reaching conensus. I'll try to summarize the views expressed here. Simon looked at how other distributions approach patches and figured that basically everyone else uses the patches-unapplied model. Going patches-unapplied has the benefit of not imposing a particular workflow onto your git repository. It can be gbp-pq, saving the output of git format-patch or an email patch, or even writing diff syntax manually. We also observed that a significant portion of Debian uses the patches-unapplied model, including but not limited to Gnome, Haskell, Perl, Python, systemd, much of pkg-games and utopia/freedesktop. It is fair to say that dgit is an outlier here in choosing patches-applied as a model. The 3.0 (quilt) format was specifically designed for the patches-unapplied model (which is also why it is not that a good fit for dgit). And for that reason, people who prefer patches-unapplied see little reason to keep using 1.0 source formats. For 1.0-native, we already figured that 3.0 (native) would be better once lifting the revision restriction. For 1.0-with-diff, there are two basic models. In one model, you patch everything directly and most likely manage your diff in some VCS (e.g. git). In this model, there typically is no debian/patches or other kind of patch management system in the source package. The other model restricts itself to only adding files below debian/ and then using debian/rules to actually apply patches during build. This latter model is fairly annoying, because there are so many different ways of doing it (i.e. we lack consistency there). So what I'd like to ensure is that any resolution we do here is clear about discontinuing the use of 1.0-with-diff together with a patch system to be applied during package build. We've explored that model in depth and settled on 3.0 (quilt) as the superior solution. There is no need to explore it any further (and as demonstrated by curl, gcc and glibc, you can even turn 3.0 (quilt) ad absurdum). So in my view, the only reasonable use of 1.0-with-diff is where you manage your diff externally rather than during package build. > 4a. We believe that there are indeed circumstances in which > 1.0-with-diff is the best choice for a particular source package, > including, but not limited to, git-first packaging workflows. > > This is because there is currently no other source format which is > such that avoid both (i) uploading the whole source, including > upstream, for every upload; and (ii) having to maintain > debian/patches/ inside the package tree. > > 4c. We believe that there are indeed circumstances in which > 1.0-with-diff is the best choice for a particular source package, > including, but not limited to, git-first packaging workflows. > However, we recommend discontinuing use of 1.0-with-diff in other > circumstances, to simplify the contents of the archive. > > This is because ... [second paragraph as in 4a]. For the reasons above, I do think we need another variant of 4. Both of these leave room for using 1.0-with-diff in combination with a patch system. Beyond that, we're still giving advice and our advice is a non-binding recommendation. So going a bit less vague seems warranted to me. Sean cautioned that we should not deny future developments. I don't think any future developments should use 1.0-with-diff, so trimming the possible use cases for 1.0-with-diff to a minimum that explicitly excludes use with a build-time patch system is what I think we do. Some people have been asking me why I think consistency is important. I think the most useful explanation is practical experience here. I routinely do archive-wide work and I've basically reached a point where I do no longer send patches for 1.0 source packages, because it simply takes too much time to figure out their workflows unless fixing that particular issue is relatively important to me. So yes, 1.0 does present a practical barrier to contribution. Helmut
Bug#1007717: Updated draft resolution
Hello, On Tue 10 May 2022 at 05:29pm -07, Sean Whitton wrote: > At today's ctte meeting we considered whether we can start a vote on > this, but two committee members were missing, and someone else at the > meeting reported that they hadn't yet been able to spend enough time > thinking through the issue to be ready to vote. > > We came up with the following plan. Below I've drafted a ballot. Once > each of those three individuals has let me know that they've had a > chance to catch up, I'll start a vote. The hope is that this can happen > well in advance of our next meeting. So, ctte members, if I don't > already know that you're caught up, please write to me once you are. Unfortunately, people haven't yet indicated they're caught up. Here's an updated ballot in light of our upcoming meeting. I've left space to add a 4b, if, when our current discussion is concluded, someone would like that in addition to 4c. ~ DRAFT Using its powers under constitution 6.1.5, the Technical Committee issues the following advice: 1. It is not a bug of any severity for a package with a non-native version number to use a native source package format. 2. Thus, we think that dpkg shouldn't issue warnings, or otherwise complain, when a non-native version number is used w/ 3.0 (native). 3. We suggest that the wontfix tag on #737634 be reconsidered. 4a. We believe that there are indeed circumstances in which 1.0-with-diff is the best choice for a particular source package, including, but not limited to, git-first packaging workflows. This is because there is currently no other source format which is such that avoid both (i) uploading the whole source, including upstream, for every upload; and (ii) having to maintain debian/patches/ inside the package tree. 4c. We believe that there are indeed circumstances in which 1.0-with-diff is the best choice for a particular source package, including, but not limited to, git-first packaging workflows. However, we recommend discontinuing use of 1.0-with-diff in other circumstances, to simplify the contents of the archive. This is because ... [second paragraph as in 4a]. 5. We decline to comment on the recent source package format MBF. Option A -- issue items 1-3, 4a and 5 Option C -- issue items 1-3, 4c and 5 Option X -- issue only items 1, 2, 3 and 5 Option N -- none of the above. END DRAFT -- Sean Whitton
