Philipp Kern writes ("Re: Preferred git branch structure when upstream moves
from tarballs to git"):
> On 5/2/2019 7:11 AM, Ben Finney wrote:
> > Conversely, I think it does a disservice to downstream users to mix in
> > Debian packaging changes with upstream changes. The separation is useful
> > and much easier to maintain when the repositories are separate.
>
> To be honest the greatest disservice is that we cannot standardize on a
> single way so that a downstream can just pull all of them and build from
> them. Instead you need humans analyzing how every single one of them works.
A downstream can get this with dgit already. dgit provides a
downstream, or a user, with *every* package in a *standardised* git
tree format.
The shape of the history depends on what the maintainer did. If the
maintainer used dgit, as they should, then the dgit git tree seen by
the user or downstream is the maintainer's history (possibly with some
additional git commits for format conversion). If the last person to
upload the package just did `dput' then the downstream gets a .dsc
import.
This is a principal reason why every maintainer should be using dgit
to do their uploads.
Also, and I am going to repeat myself because this is constantly
misunderstood, for most maintainers [1],
YOU DO NOT NEED TO CHANGE YOUR GIT WORKFLOW to upload with dgit
That is, EVERYTHING TO SOLVE THIS PROBLEM [2] ALREADY EXISTS.
Including the tooling to convert the various kinds of maintainer git
branch into something standard and suitable for users and downstreams.
The problem is not to design it, the problem is to get people to use
it.
Sorry for shouting, but, really. It is kind of frustrating to have
designed and implemented and deployed a complex piece of software
which solves a lot of problems, and constantly hear people
- proposing solutions which do not address the primary difficulties
- merely lamenting that our current practices are so bad
- stating that the problems are intractable and cannot be solved
- saying that for this we need to agree a uniform git workflow
We had the design conference in Vaumarcus in 2013. Joey Hess and I
came up with the basic design principles on a big piece of cardboard
with a bunch of us crowded round a table. I went and implemented it
right away and uploaded 0.1 while still at Debconf.
dgit has been useable for use by gbp pq users (and people with
equivalent patch management workflows, including people using
git+quilt) since 2.0 in October 2016. You can upload with dgit to
buster using dgit 3.11 from stretch (although you probably prefer the
8.3 from stretch-backports). This stuff is stable, mature, documented
software.
Ian.
[1] Support for bare-packaging git trees is a wishlist item with some
experimental patches, which I would complete if someone told me that
this was the one thing stopping them using dgit.
[2] I mean the problem of providing every Debian downstream and user
with a useable and correct and standardised git branch which can be
used for building the package, developing patches, and sharing the
results. The problem of streamlining the Debian maintainer's upload
process to be more like "git push" remains.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These 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.
