[14:36] <Odd_Bloke> powersj: Ack, thank you!  I'll drop robjo a direct line to make sure he sees it.
[14:42] <Odd_Bloke> smoser: So we have been trying to keep our packaging branches "pristine" so they match exactly what's in the archive (this makes hotfixing/security fixes easier to manage); we haven't actually had many packaging changes since we started doing that, though, so we haven't really had to deal with what to do with "pending" changes like this.
[14:42] <Odd_Bloke> I guess we could just queue an upload to impish.
[14:44] <smoser> ?
[14:44] <smoser> i dont follow.
[14:44] <smoser> packaging branches 'pristine' compared to what ?
[14:44] <Odd_Bloke> Compared to the archive.
[14:45] <Odd_Bloke> So if we have to cut a fix containing only $commit today to $series, we can cherry-pick $commit to ubuntu/$series and upload.
[14:45] <smoser> but where do you keep revision control of the packaging branches ?
[14:46] <smoser> are you saying "we don't" ?
[14:49] <smoser> Odd_Bloke: ?
[14:49] <Odd_Bloke> I don't follow, the ubuntu/* branches are our revision control?
[14:50] <smoser> then what is wrong with committing to them
[14:50] <smoser> other wise what is the point ?
[14:50] <smoser> if you're saying they always match exactly what is in the release, then they have no value.
[14:51] <smoser> unless you can "queue" things.
[14:53] <Odd_Bloke> They absolutely do have value, that's nonsense: being able to establish what changed when and why is still useful even if you can't queue stuff.
[14:53] <Odd_Bloke> But I agree not being able to queue stuff is a problem.
[14:53] <smoser> "being able to establish what changed when"... but the ubuntu packaging git would show you that.
[14:53] <smoser> and is maintenance free.
[14:54] <smoser> and authorative
[14:54] <smoser> authoritative ?
[14:54] <Odd_Bloke> git-ubuntu doesn't give us more information than Launchpad always did: it just attaches the whole changelog to a commit.
[14:54] <smoser> but anyway... if what is in your branch differs from ubuntu packaging branch, then yours is wrong. thats what i was saying.
[14:55] <smoser> um... maybe ?
[14:55] <smoser> launchpad had that iformation... that you could see between exactly version 'a' and 'a+1'
[14:55] <Odd_Bloke> So we do get a higher fidelity of information (i.e. separate commits for the different things done during release).
[14:55] <smoser> git-ubuntu has it for all things.
[14:56] <smoser> and between series, and ... so yes. launchpad knew it all. but was way difficult.
[14:56] <Odd_Bloke> Oh yeah, git-ubuntu is way better than just LP, don't mistake me.
[14:57] <smoser> ok. well... i just think you basically do need to allow "que'ing" things. and if you wanted to *just* cherry-pick for a hot-fix, then you just have to revert.
[14:57] <Odd_Bloke> Yeah, I agree.
[14:57] <smoser> that is a uncommon thing on a release branch and very uncommon in devel
[14:57] <Odd_Bloke> Haha, I wish it were uncommon in release branches.
[14:58] <Odd_Bloke> But we've done as many hotfixes/cherry-pick releases this year as we have proper upstream releases, I think.
[14:58] <smoser> well... its uncommon that you would not also be able to take the queued' commit.
[14:59] <falcojr> is there a reason we can't do a hotfix branch off last release commit?