[PKG-Openstack-devel] Please don't remove gbp.conf from openstack packaging repos

[Thomas Goirand]

On 11/06/2017 07:10 AM, Allison Randal wrote:
> 
> 
> On 6 November 2017 06:23:12 GMT+11:00, Thomas Goirand <zigo at debian.org> wrote:
>>
>> Don't get me wrong, I appreciate contribution, and it's great if you
>> want to contribute. But indeed, to me, insisting about gbp.conf,
>> pristine-tar, *AND* this timing, it only feels like it's helping
>> Ubuntu,
>> not Debian. Hoping this may change in the (near) future: maybe
>> Canonical's team will confirm they want to release Queens with us?
> 
> Thomas, this attitude is seriously unhelpful. Ubuntu has offered that you could use their work, multiple times, even before you started packaging OpenStack. You decided to do it in your own weirdly unmaintainable way, that no one wants to touch. Stop pretending that Ubuntu contributors are the problem. *You* are the problem.
> 
> Allison

Allison,

What I'm going to write below are only statements. It's pure facts, so
there's nothing to take personally.

During the OpenStack sprint in Montreal, we took a number of decisions,
which influenced the way I did the packaging. Here's a few of them,
related to the discussion. Each decision had thoughts behind, and they
were not taken lightly.

* We decided that we would continue to use a git tag workflow, because
it helps packaging faster, removes the artifacts which we don't want in
the packaging (egg-info, upstream changelog, AUTHORS file), and is very
helpful to cherry-pick patches or package a specific git tag.

It was mentioned that pristine-tar is broken anyway, not producing
always the same tarball. The recent REJECTED upload of Alembic, for
which I forwarded dak's message to the list, is yet another example of
that brokenness. The creator of pristine-tar and its current maintainers
also agree: pristine-tar is broken by design, and its biggest benefit
(ie: skipping the boring task of downloading existing orig tarball from
the Debian archive before building) sometimes fail. So pristine-tar,
unfortunately, doesn't bring any improvement to the build workflow.

* To improve the workflow, and also reduce the workload, we decided to
completely remove the debian/gbp.conf file. This file is not needed,
because the gbp.conf file is only mandatory when using pristine-tar. By
default, pristine-tar is set to false by default. Reducing the amount of
work on such a large set of packages really is hepful, and removing
gbp.conf goes that direction. Also, not everyone uses gbp (Daniel,
for example, prefers to use sbuild directly).

The proposed gbp.conf from Canonical, even if we wanted to add it,
wouldn't work for us because:
- It sets using master branch and we use debian/pike (explained above)
- It sets pristine-tar = true, but we don't use pristine-tar

In both cases, it would break us. Everything else can be set either in
/etc in gbp.conf, or in ~/.gbp.conf in a global way, once and for all.

Note that I was against removing the gbp.conf file, as I thought it was
best to not force someone to configure git-buildpackage locally.
Considering I was the only one having this opinion, I accepted, and over
time, I came to the conclusion that it was the right thing to do.

* During Debconf, we discussed where to upload Pike, and we decided that
we would do it in Experimental. Here again, I didn't agree, and wanted
to upload to Unstable. One of the reason was that it would help
Canonical, as sync from Unstable is automatic. I was given the counter
argument that Canonical could manually import from Experimental. Now we
see the consequences: I'm being told what's happening is my fault
because the packages arrive late in sid...

As a conclusion, the only thing I've been doing here is defending the
decision *of the team* (not my "own weirdly unmaintainable way" as you
stated harshly). Decisions which we made collectively during the Debcamp
sprint in Montreal, and for most of which I didn't agree to begin with.

Another fact: I uploaded 318 times since August (I checked how many
ftp-master.upload files are on my filesystem for my Pike folder). The
2nd contributor would be Ondrej, with maybe a few dozen uploads (I
didn't count). The only upload you did was git-review, taking the
package away from the team. Are you planning to contribute more ?

That's all for the facts. Now a bit more thinking about collaboration
with Canonical on the OpenStack packaging.

You may have noticed: I'm being frustrated because there's *not
enough* contribution from Canonical, not the opposite way. Here, the
only thing I've seen from Canonical for this Pike release is 5 diffs, 3
of them only pushing gbp.conf and watch file, or retaining
Breaks+Replaces which are nowadays useless even for Ubuntu. The only
very good one is the one for oslo.concurrency (thanks a lot for that
one!). That's a bit light, don't you think? It's even more a surprise to
see Corey asking for an EPOCH bump in oslo.context, affecting 27
(build-)dependency, when he has direct write access to the Git, when
that EPOCH was bumped last January in Ubuntu, and after we've uploaded
all of Pike already (said with other words: a quite wrong timing). I'm
truly sorry for this makes me a little bit grumpy, though I believe it's
easy to understand why.

So I'm saying it again: I'm very much welcoming a reboot of the
collaboration with Canonical the way it was done in Mitaka, when Corey
and others were simply pushing to the Git on Alioth. James Page also
told me face to face he felt happy of both the workflow and the result.
I don't see why it couldn't happen again. Of course, the decision to do
it isn't on me though...

Altogether, I don't think it's fair to say that *I* am the problem. I
found your wording not only uncomfortable, but above all, simply wrong.
Hopefully you understand why now.

Cheers,

Thomas Goirand (zigo)