"git ubuntu build" doesn't use -v for merges

[Robie Basak]

Unverified. When uploading a merge, the changelog should be built with -v<old/ubuntu>. I don't believe it currently does this.

[Christian Ehrhardt  (paelzer)]

Setting to confirmed for one of my cases recently.
Nish Sponsored out of that and he could have taken -v manually, but the tool should do so on the local "--for-merge" as well as on the review/sponsore side actually (which uses the same build command I'd think so it is the same code)

Example that could include the Debian logs since old/ubuntu:
  https://launchpad.net/ubuntu/+source/irqbalance/1.1.0-2.3ubuntu1

[Nish Aravamudan (nacc)]

Is this strictly necessary in the Ubuntu process? I realize I have never used -v for it. I am happy to adjust --for-merge (and/or the code that will autodetect a merge), if we have a reference to the documentation specifying it.

[Christian Ehrhardt  (paelzer)]

Well, we are in the favorable position due to the importer and launchpadlib that "git ubuntu" can know what the latest version is.

There are several cases were a -v makes sense IMHO:
- on a merge (since old/ubuntu)
- on a SRU submission (vs pkg/ubuntu/xenial-updates if that includes security)
  The point of this is SRU uploads "over" something in proposed
  The follow on needs -v to the old in updates/security to trigger things correctly on migrating

The latter might be a special case, but we could at least report a "you might want to ..." message if we do not want to auto-enable a -v in those cases.

As doc I'd think of "-v" in [1], or do you mean the git ubuntu doc that needs a section about it?

[1]: http://manpages.ubuntu.com/manpages/trusty/man1/dpkg-genchanges.1.html

[Nish Aravamudan (nacc)]

On Mon, Aug 28, 2017 at 11:12 PM, ChristianEhrhardt
<email address hidden> wrote:
> Well, we are in the favorable position due to the importer and
> launchpadlib that "git ubuntu" can know what the latest version is.

Sure, but is the "latest version" the version that made it to the
corresponding pocket (which we don't necessarily know, since we're not
dput yet) or is it the "latest version" for a series?

> There are several cases were a -v makes sense IMHO:
> - on a merge (since old/ubuntu)
> - on a SRU submission (vs pkg/ubuntu/xenial-updates if that includes security)
> The point of this is SRU uploads "over" something in proposed
> The follow on needs -v to the old in updates/security to trigger things correctly on migrating

I'm not sure the second bullet and the the fist "point" follow to me?
A SRU does not by definition upload "over" something in proposed, it
depends.

What are the "things"?

> The latter might be a special case, but we could at least report a "you
> might want to ..." message if we do not want to auto-enable a -v in
> those cases.
>
> As doc I'd think of "-v" in [1], or do you mean the git ubuntu doc that
> needs a section about it?
>
> [1]: http://manpages.ubuntu.com/manpages/trusty/man1/dpkg-
> genchanges.1.html

Because this is a "should" case, if we are going to be changing
default behavior, I want a prescriptive sentence from a developer
manual saying that it is necessary in the general case. And what is
expected.

[Christian Ehrhardt  (paelzer)]

On Tue, Aug 29, 2017 at 5:11 PM, Nish Aravamudan <
<email address hidden>> wrote:

> On Mon, Aug 28, 2017 at 11:12 PM, ChristianEhrhardt
> <email address hidden> wrote:
> > Well, we are in the favorable position due to the importer and
> > launchpadlib that "git ubuntu" can know what the latest version is.
>
> Sure, but is the "latest version" the version that made it to the
> corresponding pocket (which we don't necessarily know, since we're not
> dput yet) or is it the "latest version" for a series?

I thought the latest version that "counts" is the latest version available
on update/upgrade without enabling proposed.
So the latest in updates/security pocket is what should be the base of the
-v.
Yet I see that there is a race that can make correct detection less than
100% working - as you say "we are not dput yet".

In the merge case that should always be old/ubuntu

> > There are several cases were a -v makes sense IMHO:
> > - on a merge (since old/ubuntu)
> > - on a SRU submission (vs pkg/ubuntu/xenial-updates if that includes
> security)
> > The point of this is SRU uploads "over" something in proposed
> > The follow on needs -v to the old in updates/security to trigger
> things correctly on migrating
>
> I'm not sure the second bullet and the the fist "point" follow to me?
> A SRU does not by definition upload "over" something in proposed, it
> depends.
>

I created an example for the SRU case, but I think for the
failed-in-proposed uploading again you are right.
Here it should always be a developer who decides, example below:

- A-1ubuntu1 is in updates, nothing newer in security or proposed
- upload package A-1ubuntu2 to proposed
  CL:
    - fix issue A1 (LP: #12)
    - fix issue A2 (LP: #13)
- there is an issue in proposed
- upload package A-1ubuntu3 to proposed
  CL:
    - revert fix for A2 as it fails on Arch Y (LP 13)

Now this has multiple issues:
1. #13 should not automatically be marked by the tools but it would be
picked up if -vA-1ubuntu1 is set
2. OTOH #12 should be marked by the tools when A-1ubuntu3 migrates

There are too many special cases for this that we might come up, so yeah
for now I think outside of merges this might be too much of an heuristic.
But for the merge case I'd still like it.

I didn't find a doc clearly stating that as a recommended way to do it, the
trigger to open the bug was being asked by the DMB to do so (-v on merges)
in future uploads.