Web lists-archives.com

Re: Preferred git branch structure when upstream moves from tarballs to git




Sam Hartman writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"):
> I'm aware I'm making a typing error, and speaking in generalities.  I
> agree that my statement is true for debrebase, but I meant the dgit
> ecosystem.

I don't think this "the dgit ecosystem" is a helpful framing.  It is
very misleading, not to say entirely false.  Ecosystems are about
interactions, notably synergies.  dgit synergises about as well with
git-dpm or gbp pq or indeed raw git as it does with git-debrebase.

So "git-debrebase" is not part of "the dgit ecosystem".  "The dgit
ecosystem" is primarily git, gbp pq, and git-dpm.  git-debrebase is a
minority interest for dgit (because many people use gbp pq and few
people use git-debrebase).

                 dgit                       git-debrebase

Direct           dput, dupload,             gbp pq, git-dpm
Competitors      apt-get source             git-merge

Works well       gbp pq, git-dpm,           git
with             git-merge, git

Who should       Everyone who can           Brave people
use it, for                                  who like it
which packages   Hopefully,                 Packages with
                  all packages               nontrivial delta

Adoption         FUD                        Maintainer needs
barriers         Bugs in .dsc tools          to completely
                 Maintainer selfishness       change workflow

Primary          Users and                  Maintainers
beneficiaries     downstreams                within Debian
of adoption       outside Debian

Opinionated      To the most minimal        Completely
                  extent possible

Maturity         Very mature                Quite new

Ethics of        Use of "dgit push"         Few ethical
adoption          is IMO an ethical          implications
                   imperative

Team adoption    Each individual            Whole team
 decision         uploader can adopt         must agree
                   dgit push, or not

Repository       No change needed,          Must convert branch
 conversion       use existing master        from previous tool

Future,          Obsolete when              Rather better
after source      source packages            if no source
packages          go away                    packages needed


Lumping these two things together with some kind of "ecosystem" label,
does more to obscure than it does to illuminate.

Basically the only things they have in common are:
  * They are to do with git and Debian source code
  * I wrote them
  * The tutorials for git-debrebase say to use dgit

The latter point is because using dgit push is an ethical imperative,
not because the two somehow have some deep technical linkage.  IMO
almost *any* tutorial being written now about how to do Debian
packaging, and which mentions git at all, ought to say to use dgit.


> Dgit and debrebase are not really separate in terms of teaching.
> If you look at the documentation for debrebase, you'll find that there
> are a lot of cross references from debrebase docs to dgit.

dgit and gbp pq are not separate in terms of teaching either!

There are just as many cross-references from dgit-maint-gbp(7) to dgit
documentation as there are from dgit-maint-debrebase(7).


> Dgit is harder overall even if you ignore debrebase because it has a lot
> of moving parts that in my experience sometimes fail and because dgit
> wants to get involved in your build process, wants to be aware of your
> patch management, etc.

When dgit fails it is, almost always, because the "source code" you
are uploading to the Debian archive is not the same as what you are
actually working with as the source code in your own workflow.

Other tools don't notice this (or even have special code to achieve
it!)  IMO this is a violation of our principles which you should be
concerned to fix and which you should applaud a tool for spotting.

The only reason dgit needs to get involved in your build process is
because of the .gitignore bug.  (#908747)

> git-dpm is harder than debrebase because it is less polished and
> involves more explicit branches in some ways.

I have little interest in advocating git-debrebase.  Obviously I think
it's great, and I may advocate its use in a team I'm in, but if other
people disagree then fine.

> Please understand I think dgit and debrebase are great technologies.
> I'm moving towards using them more and more, and when I'm acting as a
> downstream rather than a Debian developer, dgit clone is the best thing
> since sliced bread.

Thanks for the compliment.

But, you will have noticed that dgit clone sometimes doesn't give you
a good history.  That happens when the maintainer uses dput or dupload
instead of dgit push.

That is why I am engaging in this thread.  I want to see `dgit clone'
produce the best answer much more of the time.  That means maintainers
need to use `dgit push'.


>  Since I've mostly stopped eating bread perhaps I
> should come up with a new metaphor, but it's really neat regardless of
> what metaphor I use.

Heh.


> Still, this stuff is hard.

git-debrebase is perhaps hard.  It's certainly new.

dgit is no harder than it needs to be, and easier than dpkg-source.


I hope you find this mail less frustrating than my previous one.

Regards,
Ian.


-- 
Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx>   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.