Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Tue, 11 Nov 2014, Barry Warsaw wrote:
> One question: when this gets adopted, will individual maintainers or teams
> have to know which of the git packaging helpers a particular repository is
> using? IOW, what happens if I were to use gbp-pq on a package that someone
> else had used git-dpm on? Do we need some kind of convention to detect which
> helper is being used? I wouldn't want to restrict choice by defining a
> standard Debian-wide (but it's okay within the context of a team). I just
> want someone who walks up to a git repo to at least easily know which tools to
> use.
I don't know. My long term hope is that in this process we will get to a
situation where:
- either the tools are sufficiently interoperable that we don't have to
care about this
- or one of tools emerges as standard supporting all the important
workflows that people are using
> >Each "vendor" uses its own namespace for its packaging related
> >Git branches and tags: `debian/*` for Debian, `ubuntu/*` for Ubuntu, and
> >so on.
>
> My question is whether the vendor namespaces are overkill for the majority of
> packages, where there probably will be just one vendor (i.e. Debian). Should
> DEP 14 allow for a simplified layout such as master, pristine-tar, upstream
> when there is no other vendor involved? Allowing for master as an alternative
> to debian/sid or debian/master might simplify the common case.
I am rather opposed to this because it because it doesn't separate clearly
the namespaces for the upstream development and the namespace for the
Debian packaging.
Even when upstream doesn't use Git, you never know whether this won't
change at some point and while it's perfectly possible to rename branches
when needed, this operation is not something that is tracked in any way
in the git clones that all users might have (it's really a branch deletion
+ a new branch) so local configuration about which branch is tracked is
now broken and you have no safeguard against non-fast-forward change
at the time you rename the branches, and so on.
I really believe that always using the prefixed namespace is the correct
course of action.
> for the current Ubuntu development series. If I needed to support older
> releases in either distro, then debian/wheezy or ubuntu/utopic would be good
> branches to use. (Or IOW, what's the equivalent of debian/sid for Ubuntu?)
I was wondering that as well. For Ubuntu, it probably makes sense to use
ubuntu/master because the latest development release regularly changes and
it's not a good idea to alway update the branch.
So that is one reason more to allow usage of `<vendor>/master` as a packaging
branch.
> >If the Git workflow in use imports the upstream sources from released
> >tarballs, this should be done under the "upstream" namespace. By default,
> >the latest upstream version should be imported in the `upstream/latest`
> >branch and when packages for multiple upstream versions are maintained
> >concurrently, one should create as many upstream branches as required.
>
> Similarly, is 'upstream' okay for the upstream branch? It's a little simpler
> than upstream/latest, especially if you don't anticipate importing an other
> upstream branches.
And it's also compatible with the current gbp practice. I'm not set of
upstream/latest but given what I said above about renaming branches, I
still believe that it's best to have a default name that does not need to
be renamed when you want to add more upstream branches.
Or maybe we recommend "upstream/latest" by default but allow "upstream"
alone in the case when there are no other upstream branches tracked ?
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/
Reply to: