Sam Hartman <hartm...@debian.org> writes: > Using native source formats (1.0 and 3.0 (native)) is attractive for > some git workflows. It means you can just export the git repository and > don't need to make sure that you use the same upstream tarball when > upstream versions are the same. You don't need to synthesize a separate > upstream tarball.
> It seems particularly attractive when upstream doesn't produce tarballs > and instead does their development in git. > I'd like to understand the downsides to doing this: While this is not an argument against *ever* using 3.0 (native) or some equivalent when packaging upstream software, I have found it to help relationships with upstream considerably in the past to represent the package as their software as released plus a set of Debian patches. For at least some upstreams, this is a very natural workflow; they can pull patches easily at their leisure without requiring the Debian package maintainer to keep updating a rebased patch submission. Even with upstreams that switch to a PR workflow, sometimes it takes a while to convince upstreams to even look at patches, and having a cleanly-separated patch in the packaging makes it very easy to submit a PR when upstream is ready. There are obviously ways to represent this with a pure Git repository, but apart from using a patch system on top of 3.0 (native), at which point I don't understand why one wouldn't just use 3.0 (quilt), they require multiple branches and thus aren't available directly in the archive. Extracting specific changes by comparing only two Git branches with a complex merge history is certainly possible to do with native Git tools, but I would classify it as an advanced Git skill. I think there are a lot of upstreams using Git for whom that operation would still be quite challenging. There's also a psychological value for some upstreams to representing all changes to upstream as patches. If they're worried Debian is doing some weird nonsense (from their perspective) to their package, they can look at debian/rules for build flags and then at debian/patches and see exactly what we've done, and feel assured that the rest of the package is exactly as they released it. That's easy for them to do; downloading the full package and then diffing against their tree is more awkward and can't be done with some casual web browsing. This is one of those cases where knowing your upstream is invaluable. A lot of upstreams won't care in the slightest, some upstreams are Git experts and know exactly how to get the data they care about, and others are still using Subversion or even CVS and will find anything related to Git opaque and frustrating. Some upstreams actively encourage downstream modifications and will seek them out and incorporate them, some upstreams are happily oblivious and only look at patches or PRs submitted to them, and some upstreams will get actively upset at what they view as unmotivated or incompatible changes and may require delicate handling (part of which, in my experience, is effortless transparency so that they don't feel like anything is being hidden from them). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
