Re: git workflows for general Ubuntu development
Dear Robie, On Tue, Nov 15, 2016 at 05:41:56PM +, Robie Basak wrote: > On Tue, Nov 15, 2016 at 10:24:32AM -0700, Sean Whitton wrote: > > The most important part of the tutorial for realising this is putting > > "single-debian-patch" and "auto-commit" in debian/source/options, but I > > would also encourage you to read the section "Sample text for > > README.source". > > If this is necessary, then it breaks our use case unless you can also > require all Debian packages to switch to dgit first. > > In Debian, a package maintainer can decide to switch VCS system and > write things in README.source to explain how things should be done. > > In Ubuntu, switching a package's VCS, debian/source/options, and so > forth would make it increasingly difficult to maintain a delta against > Debian. In general we never add such a (VCS of debian/source/options) > delta. Whatever solution we employ, it must be able to work with > unmodified Debian source packages. Okay, I see what you mean. I support my suggestion was actually quite radical: adding those two lines to d/source/options for every package you maintain a delta for. In that case, the merges would be easy (a simple helper script that ensured the lines were present post-merge) and you wouldn't need README.source because everyone would know that was how things worked. But that would be a massive social change! -- Sean Whitton signature.asc Description: PGP signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: git workflows for general Ubuntu development
Hi Sean, Since our UOS session will start very soon, I'll reply just to the things that I think I can address immediately for now. On Tue, Nov 15, 2016 at 10:24:32AM -0700, Sean Whitton wrote: > The most important part of the tutorial for realising this is putting > "single-debian-patch" and "auto-commit" in debian/source/options, but I > would also encourage you to read the section "Sample text for > README.source". If this is necessary, then it breaks our use case unless you can also require all Debian packages to switch to dgit first. In Debian, a package maintainer can decide to switch VCS system and write things in README.source to explain how things should be done. In Ubuntu, switching a package's VCS, debian/source/options, and so forth would make it increasingly difficult to maintain a delta against Debian. In general we never add such a (VCS of debian/source/options) delta. Whatever solution we employ, it must be able to work with unmodified Debian source packages. > Like Ian, I beg you to reconsider this in the strongest possible terms! This will only be possible if dgit actually helps us with our use cases. If it cannot, then we either need to figure out how to add functionality to dgit to make this possible, or we cannot use dgit. I think a path forward might be for our system to be able to take dgit as input, and also provide dgit as output. But this remains to be seen. Robie signature.asc Description: PGP signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: git workflows for general Ubuntu development
Dear Robie, Thank you for your detailed explanation of your project. I'd like to make just a few remarks in response to your criticisms of dgit. Firstly, *everything* that you discuss under "Differences from Debian" was in fact a target when dgit was designed. I'm not going to respond point-by-point, but in particular, dgit is designed to deal with the fact that DDs make uploads not using dgit. `dgit pull` handles this very well. On Tue, Nov 15, 2016 at 04:25:23PM +, Robie Basak wrote: > 1. Removing .pc breaks quilt. Going with my incremental theme again, our > import format does not break this; users do not have to learn any > additional tools. dgit punts on this with "If you want to manipulate the > patch stack you probably want to be looking at tools like git-dpm". Secondly, with regard to the patches-unapplied/patches-applied debate, I would encourage you to read dgit-maint-merge(7), a workflow tutorial I wrote that is shipped with recent versions of dgit (or online[1]). While this tutorial is targeted at Debian package maintainers, I think that it could easily be adapted for use by a downstream distro. What this tutorial encourages you to do is *stop* manipulating the patch stack. Users do not have to learn any additional tools basides git best practices, which they should know anyway. And new users do not have to learn quilt. IMO this is really important. The most important part of the tutorial for realising this is putting "single-debian-patch" and "auto-commit" in debian/source/options, but I would also encourage you to read the section "Sample text for README.source". Like Ian, I beg you to reconsider this in the strongest possible terms! [1] http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git-manpage/dgit.git/dgit-maint-merge.7 -- Sean Whitton signature.asc Description: PGP signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: git workflows for general Ubuntu development
Cutting out the debian-devel and ubuntu-devel-discuss lists. I think this subthread has quite a risk of fragmenting, so I'm moving it to the one list (vcs-pkg-discuss) that seems most appropriate for this thread. I have seen a few comments about "why not dgit?" and I realise that I have yet to reply to these. Over the years I have internalised the reasons, so have found it difficult to write down my arguments in a cogent way. I'll attempt that here now, and I welcome replies that try to convince me that I'm wrong. I have may some other ideas in my head I have failed to remember right now. I've tried hard to get this written and posted in advance of our Ubuntu Online Summit session on this topic[4]. It took me a while though, and I realise there is not much time left for participants to read and absorb this. So sorry for the short notice. For clarity, I'll call our system "usdi" as we don't have a better name for it yet. And one fundamental point of difference appears to be whether the git tree is "quilt popped" (usdi) or "quilt pushed with .pc removed" (dgit). Note that an "Ubuntu merge" (our primary use case) isn't the same as a git merge. It's more like a git rebase, but formerly without the benefit of a VCS. If you're not familiar with this, see [1] for details. Please understand that we did not set off trying to solve all use cases at once. Our goal in the design of this was not "one git to rule them all". It was more "how can we use git to solve our immediate problem?" My first effort[1] did not even have an automatically imported git tree. I did it manually from source packages. # A technical summary of what our importer does Our imports appear in regular git repositories (not special remotes); one per source package. The importer (and only the importer) maintains one branch pointer per distribution and series. These branch pointers fast forward, so users can follow them easily. When the importer runs for a given source package, it checks for any newer source uploads, imports their trees and updates the distribution+series branch pointers. These commits are equivalent to the source packages with quilt patches popped and with no .pc directory. This isn't enforced on other commits pushed by uploaders (see below) but it wouldn't make sense do so anyway. An uploader can choose to push to the git repository before the importer runs against a corresponding upload. The uploader should push just a tag in the form "upload/" to indicate to the importer that this is a set of logical commits that can represent the upload (instead of having to fall back on a wholesale import in one commit). The uploader should not update any branch pointers. When the importer sees a new published source version, it will find and use this tag if it passes sanity checks. The updated distribution+series branch pointers will then have the "upload/" commit in their histories as appropriate. You can run the importer locally. If you run it against some current remote tree (perhaps in future the "official" tree), then you will end up with the same new imports as some other importer run (perhaps in the future the "official" importer) with identical commit hashes. This is quite convenient during development, since you can propose a branch against a future official branch that doesn't necessarily exist yet. # Other parts of our workflow We have a bunch of documention-in-progress[2] and tooling[3] to help us manipulate the tree in common ways to help us with our use cases. I argue below why I think our model works for our use cases, so in that sense I guess that they're relevant. But you don't need to understand what we do in order to understand what we've done. # Differences from Debian Some unique challenges I think Ubuntu has over Debian: 1. Like Debian, we have NMUs (effectively). Unlike Debian, these happen all the time. Unlike Debian, we can't choose to switch a package maintainership over to a particular git model. In addition to non-git uploads from other Ubuntu developers, we also have to deal with non-git uploads from Debian, which is the primary source of commits and uploads for the package. Whatever model we choose, we have to be able to deal with the fact that the primary input from the system will not contain nicely separated logical commits. 2. Being derived from Debian, we get far more benefit from git if git understands our inheritence model. 1.0-1ubuntu1 in Ubuntu should have 1.0-1 from Debian as a parent in our git model. We may be able to get away without this, since "Ubuntu merges" are primarily a rebase-based workflow for us. However, getting the inheritance graph correct allows us to automate more and more of this. Right now, we have the rebase graft points identified for us automatically. In the future, we might even be able to create a git-based "merge-o-matic" which could do "Ubuntu merges" automatically where there are no conflicts. 3. As an Ubuntu development team, we need a system that presents a
