Bug#1007717: Native source package format with non-native version

[Lucas Nussbaum <lucas@debian.org>]

Hi Sean,

On 28/03/22 at 16:21 -0700, Sean Whitton wrote:
> Hello Lucas,
> 
> Many thanks for providing this summary of your position.  Let me just
> note a point of disagreement:
> 
> On Tue 15 Mar 2022 at 10:06PM +01, Lucas Nussbaum wrote:
> 
> > A point that I find important is the following: as a project, I think
> > that we care about facilitating the review of changes we make to
> > upstream source.
> 
> Certainly we do.
> 
> > I think that the preferred method (and widely accepted method) for
> > that is currently to use the 3.0 (quilt) format with DEP-3-documented
> > patches, on top of a tarball that contains the pristine upstream
> > source.
> >
> > The git packaging workflows that generate source packages using either
> > 1.0 native packages, or 1.0 non-native packages without patches, make it
> > harder to identify and review those changes, as they require browsing
> > the git repository, which sometimes is not properly documented using
> > Vcs-*.
> 
> I don't think it's the preferred method.  I believe most of the project
> sees git histories are the preferred tool for achieving the goal you
> state.
> 
> If we had only source packages for this purpose, then yes, 3.0 (quilt)
> plus DEP-3 would be preferred.  But we have git, too, and indeed dgit.
> Repositories for packages contain both upstream history and Debian
> packaging history, and we have powerful git subcommands for extracting
> information.  In many cases there is a good argument to be made that the
> git history is part of the preferred form of modification.

I think there are three different use cases to consider:

  A. preferred form for regular contributions to the package (typically
  by the package maintainer)

  B. preferred form for occasional contributions to the package (typically
  by an NMUer, or by the security team)

  C. preferred form for reviewing the packaging and Debian-specific
  changes.


I fully agree that the git repository is the preferred form for A.
However, for B and C, I think that our lingua franca is the source
package, and thus a source package that doesn't make it hard to
understand things such as Debian-specific patches. Of course that
could change if we were able to standardize on a git workflow (or
a small set of git workflows), but I don't see this happenning anytime
soon.

Lucas