Re: RFC: DEP-14: Recommended layout for Git packaging repositories
[ I skip the more detailed discussions on naming conventions to
concentrate on your higher level questions for now ]
On Thu, 13 Nov 2014, Ron wrote:
> Sure, I understood those were your goals.
>
> What I haven't seen, and what I'm asking for, is an actual detailed
> rationale describing the actual detailed problem(s) that you think
> these goals will be a remedy for.
Problem 1: the derivatives
--------------------------
So I am a Kali Linux contributor. We use git repos to maintain all our
packages and we use git-buildpackage. Most of the Kali contributors
are not long-term Debian contributors, I write documentation so that
they can contribute to Kali (while basing our work on Debian).
To make this manageable I opted to always use a workflow based on
"git-import-orig". Even when Debian has its own git repo, we start
from the released source packages because that's the only level of
uniformity that we can rely on. And it's a pity because if we could
build on Debian's git repo, it also means that our work would be easier
to merge for the Debian maintainer. They could add the Kali repo as a
remote (without fearing any conflict in terms of tags, branch names)
and just merge or cherry-pick as appropriate.
And we could also build on work in progress that has not yet been
released as a source package. Right now, the only packages where we
build on top of the Debian git repositories are some native packages
(like debian-installer).
I can't afford to document all the possible ways Debian is maintaining
their package but if I can write a documentation that covers the common
case and if I can tell them "when you see those branches, you can follow
the instructions below", then we have made some real progress.
Problem 2: interoperability between the tools
---------------------------------------------
I am part of the Python Modules team who wants to switch to git but not
all contributors are using the same git helper tools and yet we would like
to all work together on the same repositories without forcing everybody
to use the same helper tool (habits are hard to change).
We can't just let each maintainer use the default layout suggested
by his preferred helper tool and the defaul tagging scheme, we have to
define some common layout for the whole team. Then it matters less if
people are using git-buildpackage or git-dpm or gitpkg.
It might be awkward at times but at least there is some consistency among
the team, and the few problems that will arise will be occasions to
improve the tools.
But we have to define the common layout to use and this discussion should
hopefully solve this too.
Problem 3: making it easier for new contributors
-------------------------------------------------
While I can appreciate the versatility of gitpkg, new contributors
are looking for guidance and clear instructions. It's difficult to give
those when we have zero common ground on how we manage our git
repositories within our project.
While I don't see us converging on any single helper tool right now,
it's important to start taking steps that brings them closer so that
we can give more useful explanations to newcomers.
and so that they
can get started
> Likewise, it's not clear to me that tools other than gitpkg are
> actually interchangeable, because they weren't designed to be from
> the outset and rely on magic being committed into the repo to work.
>
> I don't really see how some naming conventions can fix that either.
Naming conventions won't fix that but it's still a pre-requisite
to be able to fix the tools that (unlike gitpkg) voluntarily set (by
default) more constraints on the expected layout of the repository.
> Maybe if you start by detailing the problems, we will be able to
> see some better solutions that actually achieve your real goals
> and result in real improvements to the tools that created them.
Let's see!
> > 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 :-)
>
> Why would you want to do that?
To share them with upstream in a form ready for merge (or more practical
for review/analysis, etc.).
> > > 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.
>
> I meant for the other tools. You said you thought they were going to
> need patching for this and were planning to help with that.
Well git-buildpackage obviously needs quite some update:
- it complains when you're trying to build as soon as you're not in a
branch named master (that can be overridden with --git-ignore-branch
or setting --git-debian-branch)
- it hardcodes the "debian/" prefix for tags instead of retrieving it dynamically
- it uses the "upstream" branch by default in git-import-orig while it should use
"upstream/latest" if we follow the current version of the DEP
For git-dpm, it's a bit similar, it has some naming conventions
of its own where "upstream-foo" is the upstream of the branch "foo"
except for "upstream" where it's the upstream of "master". I don't know
git-dpm very well, there's probably more to be improved for DEP-14
compatibility.
> A lot of the problems you seem to be worried about here are things that
> gitpkg designed around ever having from the outset and simply doesn't
> have. I think if we can raise awareness about those things and fix them
> in the tools that have them, that would be an awesome thing. I'm less
> excited at the idea of codifying those limitations as if they were an
> inevitably necessary thing, as a way to avoid fixing problems in the
> tools that might have them though. That would just paint us all into
> a corner that will be even harder to get out of again later.
I understand, though we can certainly set a default naming convention
without codifying it as limitations to be imposed. My goal is not to
restrict the workflows, my goal is to standardize the bacic (common)
concepts and associated branch/tag names and build on that to improve all
our tools.
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: