[14:43] <mdeslaur> What's the process of syncing or pocket-copying stuff from oneiric-updates into precise?
[14:43] <mdeslaur> does it happen automatically at some point? if not, don't we risk losing ubuntu-specific changes from oneiric-updates and oneiric-proposed?
[14:48] <seb128> mdeslaur, usually they are copied to -updates and $newserie at the same time
[14:48] <seb128> mdeslaur, when $newserie still has the same version
[14:48] <mdeslaur> seb128: that's not currently happening
[14:48] <seb128> mdeslaur, example?
[14:48] <mdeslaur> https://launchpad.net/ubuntu/+source/xorg-server
[14:49] <seb128> mdeslaur, it's not in -updates yet?
[14:49] <mdeslaur> seb128: 2:1.10.4-1ubuntu4.1  is in oneiric -updates, but only 2:1.10.4-1ubuntu4 is in P
[14:50] <seb128> mdeslaur, seems like this one was not copied, but it comes from security, not proposed
[14:50] <mdeslaur> seb128: so the automatic copy is done by the SRU process, but it's not being done by the security update process?
[14:50] <seb128> mdeslaur, I was speaking about proposed->updates, I would assume security updates should be handled the same way
[14:51] <seb128> mdeslaur, it's not automatic I think
[14:51] <seb128> it's an archive admin best practice
[14:51] <seb128> mdeslaur, this one was maybe an oversight
[14:51] <mdeslaur> hmm...our stuff gets copied to -updates with an automatic script IIRC
[14:51] <mdeslaur> no AA to blame
[14:51] <seb128> ok, so maybe that script needs fixing
[14:52] <seb128> for proposed->updates it's done manually and the archive admin runs the command to copy to $nextversion as well usually
[14:53] <jdstrand> I don't think we can do it automatically
[14:53] <mdeslaur> jdstrand: why not?
[14:53] <jdstrand> at least not simply-- it is really only at the beginning of the dev release where we want to do this. we really want to build on the new toolchain later on
[14:54] <mdeslaur> well, what's the AA best practice? do you stop copying at some point?
[14:54] <jdstrand> I only do it when I am asked to
[14:55] <jdstrand> I wasn't asked, so it didn't happen
[14:55] <jdstrand> I also didn't think about it with the USNs
[14:55] <seb128> mdeslaur, seems it depends of the people
[14:55] <seb128> I like better to upload things once that to upload twice with 2 revision to 2 series
[14:55] <mdeslaur> so we've got an issue here, where we may be losing ubuntu-specific fixes once people start merging from debian
[14:55] <jdstrand> mdeslaur: I've made a note to discuss this as part of our dev release update process at UDS
[14:55] <seb128> i.e for desktop we usually upload the sru and pocket copy
[14:56] <jdstrand> seb128: but only early on, no?
[14:56] <seb128> jdstrand, it doesn't last long before $nextversion > $stable yes
[14:56] <seb128> like once we start on merges that time is over
[14:56] <jdstrand> mdeslaur: that was the 'not simply' part I was thinking about. we need to be smart about the versions
[14:56] <seb128> we usually do 1 or 2 weeks for SRU, then the merges
[14:56]  * jdstrand nods
[14:56] <seb128> jdstrand, so yes, it's usually between release and UDS
[14:56] <seb128> then after than we reduce the number of SRU and uploads to unstable then backport
[14:57] <seb128> mdeslaur, right, we might be losing fixes and we do loose some (i.e it's already happened in the past)
[14:57] <seb128> but pocket copies will not fix that
[14:57] <seb128> one way to "fix" it, is to not move things to -updates until the fix is in $unstable
[14:58] <seb128> which I guess is fine for SRUs but less for security
[14:58] <mdeslaur> any way we do it is fine, as long as we have a process that works and is consistent for everyone
[14:59] <seb128> right
[14:59] <seb128> let's discuss it at UDS, thanks for pointing it
[14:59] <mdeslaur> I was under the mistaken impression that O stuff gets copied automatically to P, which was a wrong assumption
[14:59] <seb128> right
[15:00] <mdeslaur> ok, thanks seb128, jdstrand
[15:03] <jdstrand> np
[20:35] <sbeattie> Hi, can I get a pocket copy of wireshark 1.2.11-6+squeeze4build0.10.10.1 from maverick-security to maverick-updates?
[20:44] <jdstrand> I can do that
[20:45] <jdstrand> sbeattie: done
[20:54] <sbeattie> jdstrand: thanks.