Hi Ron, On Wed, 12 Nov 2014, Ron wrote: > I think you probably need to be careful of overspecifying this.
Definitely. That's precisely why I don't want to dwelve (too much) into details of the various workflows and why I try to restrict the DEP at simple naming conventions for branches and tags that the various tools might need. > The "normal workflow" is simply: work in git exactly how you normally > would, whether you're making upstream changes or debian patches. > Export a source package with `gitpkg $debtag $upstreamtag`. [...] > The good news from all that though, is that it would seem unlikely > that gitpkg itself would need any changes to be able to cope with > any repo design you could come up with that wasn't completely insane :) Great, then it might be that gitpkg doesn't need any code update and that only its documentation should be updated to recommend using the default names when creating $debtag (and $upstreamtag in some cases). > The bad news perhaps, is I'm less convinced about how keen people > already using gitpkg will be to arbitrarily restructure their entire > existing repos to follow this. At least not without some much clearer > rationale about what compelling benefits they'd get in return for all > that work and disruption and rewriting of history. I don't necessarily want everybody to update their current repositories (altought it would be nice). I want at least that when new contributors create a new git packaging repository, they have some good advice on how to structure their repository and the helper tools that they pick work nicely in that layout. > Maybe I missed something somewhere (I should have been sound asleep > a few hours ago, so that's quite possible), but I see lots of > explanation of *what* you want to do, but not the killer reasoning > about *why* you want to do it, or what concrete things you think > will be gained from it. I think I explained my goals in the introduction of the DEP. Making it easier for Debian and its derivatives to build upon their respective Git repositories (possibly on a semi-automated basis). And making it easier to switch between various git packaging helper tools because they would share (by default) the same basic conventions. And making it easier to have the upstream git branches in the packaging repository too. > More specifically, you have things like: > > "Helper tools should usually rely on the output of dpkg-vendor > --query vendor to find out the name of the current vendor. > The retrieved string must be converted to lower case. This > allows users to override the current vendor by setting > DEB_VENDOR in their environment" > > This seems like a git-bp specific hack to me, that has the assumption > and trained habits of using that tool so deeply embedded in it that > doesn't bother to explain why you would use this, when you would use > this, or even what you would expect it to do. Given that the DEP recommends to create tags like <vendor>/<version> it seems like a good idea to explain how to retrieve <vendor>, no? It's not really related to git-bp (except for the fact that git-bp started this convention of prefixing the tags with "debian/"). gitpkg might not take the job of creating that tag, in which case that particular advice is obviously irrelevant and it's up the package maintainer to follow that naming convention when he manually creates the said tag. > The section on "Patch queue tags" also seems to be written from the > perspective of only knowing one tool and one workflow to use it. > With the work that David Bremner did on git-debcherry, gitpkg can > fully automatically extract a quilt patch series for a source package > simply from completely normal commits to your repo, in a form that > makes them trivial for upstream to cherry pick, and makes them > automatically vanish when you merge the upstream release that includes > them. Yes, the pach queue section is heavily inspired by "gbp pq" but again it's nothing mandatory. It says something like "if the helper tools produces something that looks like a patch queue branch and if it wants to store it for later consumption, it should use that tag name". Fine if the other tools do not need anything like that. But who knows, maybe you will want to enhance git-debcherry to not only update debian/patches/ but also store the corresponding git branch for long-term storage. In which case, you will already have a recommended tag name for this purpose :-) > > I would be willing to participate to such a sprint and do my share > > of the work (although I'm primarily using git-buildpackage and would > > likely start with this helper tool). > > I am a bit curious about what patches you think you're going to need > to make to make things comply with this plan? For gitpkg? I don't know. See above, maybe it's just documentation update. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141112131455.gm27...@home.ouaza.com