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@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.
Reply to: