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

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


Reply to: