Re: Why keep upstream sources in Git at salsa.d.o? (was: how to handle upstream orig tarball with git-lfs reference files?)
On Sun, 11 Aug 2019 at 15:03:51 +0200, Daniel Leidert wrote:
> What I really don't understand is, why we duplicate upstream files (now even
> really large files) on salsa.d.o.
I can't tell you every maintainer's reasons to do this, but here's why
*I* prefer having upstream source code in our packaging git repository:
* When I'm investigating a bug, I don't need a separate repository and a
separate checkout to look back through the history of the code that is
under suspicion and find out why it is the way it is.
* When I'm rebasing our patch series on updated upstream source code,
I don't need a separate repository and a separate checkout to do so.
(I use gbp-pq for this; other workflows are available.)
* When I'm trying to fix a bug, I can switch to the patches-applied view
(in my case this means gbp pq import) and try repeated rebuilds until
it works. I don't need to have a separate repository and a separate
checkout of the upstream source code, apply the Debian patch series,
work out how to build that in a way that is compatible with the
expectations of the Debian package, iterate on the new patch, and finally
export it (git format-patch) in a form that I can add to the Debian
packaging.
* If upstream's VCS repository disappears or goes offline, either
temporarily or forever, we still have the history up to this point
(and if necessary we can fork).
When GNOME's Debian packaging was still in svn, all of those except the
last were practical problems. I find it much easier to work with GNOME
packaging now that we're using git with full upstream source.
The one family of packages for which I still don't use a
full-upstream-source git repository is openarena-data, because game
data/assets have limited history (they get added and occasionally
deleted, but rarely modified) and limited scope for patching, and are
inconveniently large.
smcv
Reply to: