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
