Re: Q to nominees: Rough plan on Debian/Ubuntu collaboration?

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Matthias Urlichs writes ("Re: Q to nominees: Rough plan on Debian/Ubuntu collaboration?"):
> On 16.03.25 22:51, Julian Andres Klode wrote:
> > Ubuntu has almost-universal git access to all source packages now, a
> > contributor can for most part just `git ubuntu clone` a repository,
> > make some changes and then submit a merge request. Done.

I think in the future it will be possible for elements of the
tag2upload and dgit ecosystem to provide a similar experience.

We already have "dgit clone" for every package.  It gives you
directly and immediately useable source code, buildable and editable
withouot knowing the maintainer workflow. [1] [2]

  Reservation [1]: You don't get proper git history this way unless
  the maintainer uploaded with dgit or t2u.  t2u adoption will
  hopefully fix that.

  Reservation [2]: dgit clone pisses about with tarballs.  The user
  doesn't really need to know about all that stuff, but it makes it
  slow and it causes it to leave droppings lying about.  In the
  future, when most packages are uploaded via dgit or t2u, we hope to
  start importing all non-git-based uploads to dgit-repos.  Then
  you'll just be able to `git clone`.

The information exists in principle, to convert a user's MR based on
patches-applied back to the maintainer's git format, for all supported
dgit quilt modes at least.  With dgit/tag2upload adoption, we will
have machine-readable data which should be sufficient to automate
that.

The remaining missing part is a forge-like service to which the
user/contributor can "git push", which gateways the results to
whatever the maintainer is doing.  In principle we could do this with
extra stuff on salsa and a bunch of robots, maybe.

I think this would make a good handwaving workshop, in Brest maybe.

> Does this mean that Ubuntu's typical packages's git repository is an 
> Upstream check-out with debian/ subdirectory on top, and debian/patches 
> applied?

I doubt this is true.  But maybe Ubuntu have some magic git-fu I don't
know about.  I'd be interested to hear.

> How did you get there from here? would Debian be able to copy that 
> approach? relevant to d-vote, would a DPL who promoted this idea run 
> into any technical problems, besides the obvious social ones? :-/

I think there might be only few *technical* difficulties to your
suggested proposal - but I don't think we want to try to persuade
everyone to adopt git-debrebase.  (I think git-debrebase is the least
bad available tooling for maintaining a Debian package with a patch
stack in a patches-applied view, giving a git-rebase-like dev
experience.)

When I and Joey Hess and others invented dgit in Vaumarcus in 2013 we
assumed it would be impossible to persuade everyone to adopt a uniform
git tree/branch format, and we thought that central services would be
very difficult, especially if they needed to interact with ftp.d.o.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.