Merge ~rafaeldtinoco/ubuntu/+source/cloud-utils:lp1835124 into ubuntu/+source/cloud-utils:ubuntu/disco-devel

Scott,

I thought these 3 fixes, being straightforward, could be in Disco, at least, as well.

@Rafael,

Summary: This is fine, and I have some comments inline below.

Details.
The process you've used here is perfectly acceptable ('B' below). Please forgive my long winded response.

There are basically two paths that ubuntu server team has taken for packaging source management, and I think each are valid.
 A. upstream maintained packaging branches (lp:cloud-utils branches)
  )
 B. git-ubuntu: Ubuntu maintained packaging branches (lp:ubuntu/cloud-utils).

For cloud-init and curtin, the server team has been using 'A' and has tools to
ease that management documented at
https://github.com/CanonicalLtd/uss-tableflip/blob/master/doc/ubuntu_release_process.md
. Please read that doc. 'A' has to allow for uploads that are
done via 'B', so there is a way to "import" uploads to upstream packaging
branches that were done via 'B'. For 'B', an process like 'A' is just unknown
and results in a new imported version by the importer, just as if you'd done an
upload "by hand" to the archive.

Within 'A' there There are basically two options listed there for doing SRU patches. I generally prefer "new upstream snapshot" path as it makes maintenance much simpler. I think that doing a "new upstream snapshot" back into ubuntu/disco should be acceptable to SRU team, changes should be reviewed on merit of change rather than arbitrary numbers or whether or not something was released as a source tarball.

The snapshot backport works *really* well as it has all the metadata from
upstream git to make it "just work" and the tool 'new-upstream-snapshot' knows
enough about Ubuntu packaging to get version numbers and such right.

I think this process works well for packages who consider Ubuntu a "first class citizen". The difference is basically that in this case, upstream (lp:cloud-utils) maintains its *own* packaging branches and does package development on those branches. The ubuntu source (lp:ubuntu/cloud-utils) is just treated as artifacts.

What I suggest is this:
 * cloud-utils use 'A' for ubuntu/devel. The process is just really straight
   forward and the kinks worked out in cloud-init and curtin. If there are uploads outside of cloud-utils then we need to import them into cloud-utils
ubuntu/devel branch.
 * cloud-utils use 'B' for SRUs (as you've done here). At this point that means cloud-utils upstream
   will just be unaware entirely of anything ubuntu line of development other
   than the ubuntu/devel.

For your 'debian/patches' files, I think I'd prefer to just use 'git format patch -1 HASH' of the commit you're cherry-picking.

In my understanding, that is a valid dep-3 format.

It also makes it easier, and then you don't have to worry about people nit picking your choice to use bit.ly ;)

Scott,

Tks a lot for this clarification, really useful. I'll read uss-tableflip. I confess that's new to me and it makes total sense everything you said.

About DEP-3 format, sure. First time I use bit.ly, the http patch pointer was huge =). Let me re-push this to you then.

this looks good.

The only comment I have is on the names of your patches/ files.
I think i might have just left them as git wrote them. Again... doing that means you don't have to defend "why did you do that", as you can just blame the author of the patch when they wrote the subject line.

You can fix that, or not.

Do you need me to sponsor upload this?

Well, since the Subject: inside patches are intact, so you can always find upstream patch if needed, and you don't mind that much, I'd rather point the LP being fixed in the patch name. Of course, like always, those type of things are peculiar to each pkg maintainer and/or sponsor and we usually comply on their request.

If you're good, yes, please, could you sponsor it for me ?

Thanks a lot!

Rafael

@Rafael,

I just uploaded b26a5aa7736d4e64c19f66fa563a12808b1c4ebd as upload/0.31-0ubuntu1.1.

Email says:
 [ubuntu/disco-proposed] cloud-utils 0.31-0ubuntu1.1 (Waiting for approval)

I do not know what is the process or if there is one
for me to request a push of a tag for to usd-import-team.

I verified that what was uploaded matches b26a5aa7736d4e64c19f66fa563a12808b1c4ebd, and am pushing an upload tag for it:

$ git push pkg upload/0.31-0ubuntu1.1
Enumerating objects: 26, done.
Counting objects: 100% (26/26), done.
Delta compression using up to 2 threads
Compressing objects: 100% (23/23), done.
Writing objects: 100% (23/23), 4.57 KiB | 1.14 MiB/s, done.
Total 23 (delta 13), reused 0 (delta 0)
To ssh://git.launchpad.net/~usd-import-team/ubuntu/+source/cloud-utils
 * [new tag] upload/0.31-0ubuntu1.1 -> upload/0.31-0ubuntu1.1

Alright, I changed public bug to contain proper SRU template. This only needs sponsoring and the upload for me to verify the SRU before the migration. Thx for the review!