On Wed, Nov 12, 2014 at 02:14:55PM +0100, Raphael Hertzog wrote:
> 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.
Well, that's part of what I'm wary of overspecifying :)
We can't control how upstream names their branches and tags, and to
me (who as often as not either also is upstream or working closely
with them, sometimes with direct commit access to their repo too)
it's more important that the names of things reflect on their purpose
and their association with the upstream treeish they are related to
than that they follow some arbitrary one-size-fits-all naming
convention.
Obviously that doesn't mean "naming them completely random things",
there are some rough patterns I follow, but that's shaped to fit
with the "When in Rome" principle of fitting what I do around the
upstream conventions, not forcing mine on them if they chose some
different thing for their own reasons.
Part of the rationale I was asking you for are things like:
Exactly what tools break and how that would make these conventions
necessary?
Because maybe that's a bug we ought to fix in the tools that break.
> > 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).
gitpkg fairly deliberately stayed away from making recommendations
like this, partly for the reasons above, partly because it is designed
to be able to be used with already existing repos (where you should
follow the existing conventions unless you have really good reasons
to make some discontinuous change), and partly because it simply isn't
limited by this in any way at all so you're free to do whatever you
are most comfortable with.
For me personally, I dislike tags of the form: <unecessaryverbiage/x.y.z>
in much the same way as I dislike debian changelogs that say nothing
more than '* New upstream version'.
It adds nothing of value beyond wasted time typing it and visual clutter
when reading it.
I already know you uploaded a new upstream version, the version number
in the changelog tells me that.
If I was going to recommend a tagging convention, it would probably be
the vX.Y.Z one that is in widespread use in the majority of repos, and
which seems to have clearly won the race for "common convention", rather
than pushing something oddball just because "gbp did it that way".
If I see a repo with tags:
v1.2.3
v1.2.3-1
v1.2.3-2
v1.2.4
v1.2.4-1
I'm not likely to have much trouble figuring out which tag debian
releases and which tag upstream releases.
As more general advice I'd probably recommend using:
${upstream_tag_name}-${debian_version}
Since I definitely have some upstreams that use $packagename-$version
or similar for their own tags (and When in Rome).
I don't think I've ever seen a repo with <namespace/blah> tags in
it outside one that was gbp influenced.
> > 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.
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.
It's already quite possible for derivatives to use any of my git
repos as an "upstream base" for their own packaging work, and is
something that already happens, despite the fact that I'm not
following any of the new conventions you are proposing here.
So what tools break if you don't follow them, and how?
Every repo I have that is in git upstream has my work based directly
on their repository. Even the ones where I had the packaging in git
long before they switched to it. This has been working just fine for
many years now. What tools are broken with doing that?
These things sound like bugs in those tools. Not something a new
naming convention can fix.
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.
Can you see what I'm trying to explain here? So far this seems
like an "XY problem" (http://xyproblem.info/). You're proposing
a set of solutions - but you're not telling me the actual problem
that you're having which you want to solve by doing this work.
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.
> > 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 :-)
Why would you want to do that? The patches are *already* in the repo,
and the tool can extract them in the form you want when exporting the
debian source package (which I explained in more detail in the reply to
Simon, so I won't repeat it here again). They are already stored there
for all eternity unless you rewrite the history in a way that destroys it.
This lets you export either a "single diff" or "patch series" package
from *exactly the same source in the repo*, whichever style you prefer.
Why would you want a solution that's less flexible and more bloated, but
adds nothing you don't already have?
That seems kind of like the suggestion of "why use p-t when you can
just store the tarball directly in the repo". Sure, you *could* do
that, but it's a really suboptimal thing to do when you have better
tools available to you.
> > 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.
I was hoping that might give me some more clues into the detail of what I
asked for above (ie. what it is that is *actually* broken here that you're
trying to fix).
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.
Cheers,
Ron
--
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/20141112232953.gb10...@hex.shelbyville.oz
