1 [01:00] <nhandler> It is time for another Packaging Training Session! slangasek has kindling volunteered to lead a session about Feature Freeze and Freeze Exceptions. 2 [01:00] <nhandler> slangasek: The floor is yours 3 [01:00] * slangasek waves 4 [01:00] <slangasek> who all is here for the session? 5 [01:00] <slangasek> (as opposed to just idling :) 6 [01:00] <nhandler> o/ 7 [01:01] <slangasek> er, heh 8 [01:01] <slangasek> nobody else? :-) 9 [01:01] <Daviey> no :) 10 [01:02] <warner> I'm listening 11 [01:02] <slangasek> oh yay, people! 12 [01:02] <slangasek> so the thing that makes this topical is this: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-August/000606.html 13 [01:03] <slangasek> according to my UTC clock, Thursday is here, which means we're now in Feature Freeze, which means the rules on how we do uploads for the remainder of the karmic cycle have changed :) 14 [01:04] <slangasek> the reason we have a feature freeze is to make sure everybody's on the same page as far as preparing a release - so that people use the early part of the cycle for developing / uploading great new things, and the latter part of the cycle is focused on stabilization 15 [01:04] <slangasek> so having a broad rule, that past a certain date we only do bugfixes, helps with that 16 [01:05] <slangasek> bugfixes including everything from fixing segfaults, to typos, to documentation corrections, to translations... 17 [01:05] <slangasek> but of course, every rule has exceptions, and ours are detailed here: https://wiki.ubuntu.com/FreezeExceptionProcess 18 [01:05] <slangasek> warner: have you had occasion to request a feature freeze exception before? 19 [01:06] <warner> nope, but there's a decent probability that I will need to in the next week :) 20 [01:06] <warner> tell me how it works! 21 [01:06] <slangasek> :) 22 [01:07] <slangasek> that wiki url is a very useful reference - I suggest keeping it to hand when it comes time to file the exception request 23 [01:07] * Daviey must go to bed, but looks forward to reading scrollback. nn o/ 24 [01:07] <slangasek> but the basics are described right in the first section - file a bug report, and include: 25 [01:07] <slangasek> # A description of the proposed changes, with sufficient detail to estimate their potential impact on the distribution 26 [01:07] <slangasek> # A rationale for the exception, explaining the benefit of the change 27 [01:07] <slangasek> # Any additional information which would be helpful in considering the decision 28 [01:08] * slangasek waves to Daviey 29 [01:08] <slangasek> and then once you have the bug filed against the package that needs an exception, you subscribe ubuntu-release if the package is in main/restricted, and motu-release if i's in universe/multiverse. 30 [01:09] <slangasek> that's the gist of it - section 2 on that page gives some more specifics, but if you follow section 1, you're already well on your way 31 [01:09] * warner nods 32 [01:10] <slangasek> I don't really have much to add, beyond that... I'll take questions, though :) 33 [01:10] <warner> so, the most likely FFE that I may have to file depends upon two packages that are on their way into karmic, tahoe-lafs and python-pycryptopp 34 [01:11] <slangasek> I should also link to https://lists.ubuntu.com/archives/ubuntu-devel/2009-August/028794.html - there are some cases where motu-release has delegated responsibility to a "domain expert" for certain packaging areas 35 === zooko` is now known as zooko 36 [01:11] <slangasek> so instead of subscribing motu-release, you can subscribe the delegate instead, which is faster 37 [01:11] <warner> I may have to FFE tahoe (to change the packaging to relax a version requirement) if only the older version of pycryptopp gets in 38 [01:11] <slangasek> warner: ok 39 [01:11] <warner> or I may FFE pycryptopp to get the newer version in (which tahoe depends upon) 40 [01:12] <warner> but I believe both will fall under the "FeatureFreeze for bug-fix-only updates" clause 41 [01:12] <slangasek> tahoe-lafs is currently not in the archive, so I think that needs an FFe regardless 42 [01:12] <slangasek> new packages are almost always considered "features" 43 [01:13] <slangasek> the wiki page talks about new packages specifically: https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze%20for%20new%20packages 44 [01:13] <nhandler> What are ubuntu/motu -release looking for when deciding whether to accept a Freeze Exception request? 45 [01:13] <warner> yeah, I thought that an MOTUer added it to NEW, but I may be wrong, and we've been scrambling to get the dependencies in place 46 [01:13] <slangasek> (fwiw, I can't speak in detail to that policy since I'm not a member of motu-release, I'm just quoting the wiki page) 47 [01:14] <slangasek> nhandler: it really is as simple as the list from before: why is it important to break the rule, what's in the change that carries a risk of regression 48 [01:15] <slangasek> if the bug is something that's a small annoyance, but the diff is 5000 lines, that's probably not going to get an excepton :) 49 [01:15] <slangasek> warner: well, the MOTU can upload it to NEW, but it won't be accepted unless it gets a freeze exception from motu-release 50 [01:15] <warner> so in general, it sounds like I (as an end-user/upstream-developer/non-ubuntu/non-DD) must convince an MOTU member of the need-for/safety-of the update or new package, and they must enforce the FFE policy 51 [01:17] <slangasek> well, the people who have to be convinced are the motu-release team 52 [01:17] <slangasek> who are MOTUs, but a specific subset of MOTUs 53 [01:18] <slangasek> you need to have a MOTU upload the package, but the uploader doesn't have to have any opinion at all about whether it warrants a FFe 54 [01:18] <zooko> So, I might have missed some of the lesson. The deadline for Feature Freeze for Karmic passed 18 minutes ago, right? 55 [01:18] <slangasek> though they may ask for you to get the FFe approved first before they upload 56 [01:18] <slangasek> zooko: yes - which means new packages uploaded from here have to get feature freeze exceptions (FFe) 57 [01:19] <zooko> Okay, and while Tahoe-LAFS *was* already advocated one REVU, it was *not* actually included in the archive by an AA, I think. 58 [01:20] <zooko> In fact, in addition to being advocated on REVU, Dustin Kirkland also uploaded it. 59 [01:20] <slangasek> hmm, in the specific case of tahoe-lafs, I know kirkland mentioned it was rescinded because it still had other dependencies that need to be in first 60 [01:20] <zooko> Okay, so it was uploaded but then, um, unuploaded. :-) 61 [01:20] <slangasek> rejected from the queue, yes. :) 62 [01:21] <zooko> Okay. 63 [01:21] <zooko> So Tahoe-LAFS is in the state of "advocated on REVU but not uploaded in the queue". Is that right? 64 [01:21] <zooko> And zfec is in the same state. 65 [01:22] <zooko> And foolscap 0.4.2 is in a different state -- it doesn't need advocacy on REVU because it is already in Ubuntu, it just needs an upgrade, so its state is 66 [01:22] * zooko looks 67 [01:22] <zooko> https://bugs.launchpad.net/foolscap/+bug/419510 68 [01:22] <james_w> zooko: note that new packages from REVU generally need two advocates 69 [01:23] * zooko looks at REVU 70 [01:24] <james_w> zfec appears to have been uploaded to NEW 71 [01:24] <zooko> How can I tell? I think that each of these packages have two advocates already: http://revu.ubuntuwire.com/p/tahoe-lafs http://revu.ubuntuwire.com/p/zfec 72 [01:24] <zooko> So, what state is foolscap in? It is in the "request upgrade" state. 73 [01:25] <slangasek> zfec: https://launchpad.net/ubuntu/karmic/+queue 74 [01:25] <slangasek> er, except it's on the second page; I'll have to fix that by accepting some binaries, I guess. :) 75 [01:25] <zooko> slangasek: so zfec is in the "queued" state? Which is after the "REVU" state and before the "really into Karmic" state? 76 [01:26] * Laney wonders what these states are 77 [01:26] <slangasek> zooko: it's in the NEW queue, which is when an archive admin confirms that it's legal for us to distribute and puts it in the right section of the archive 78 [01:26] <zooko> Hey, there's a pycryptopp on that page. 79 [01:28] <slangasek> for new packages after feature freeze, the pipeline is: REVU -> motu-release freeze exception -> upload -> archive admin processing -> into karmic 80 [01:29] <slangasek> those packages that were uploaded before the FF started can reasonably be accepted by the archive admin without freeze exception paperwork 81 [01:29] <zooko> slangasek: okay, which seems to include Tahoe-LAFS (except that it was rejected from the queue), and zfec, and pycryptopp-0.5.14. 82 [01:30] * slangasek nods 83 [01:31] <warner> which means we need to start with getting foolscap and pycryptopp updated (with an FFE for that), and then we can apple for a new-package FFE for tahoe (and mention the two advocates as supporting material) 84 [01:31] <slangasek> and foolscap needs to have a feature freeze requested, by following the procedure at https://wiki.ubuntu.com/FreezeExceptionProcess and subscribing motu-release 85 [01:32] <warner> so, I'll start that process once foolscap-0.4.2 (which is now in debian) makes it past the next dinstall run, by using requestsync 86 [01:33] <slangasek> you shouldn't need to use requestsync to open a new bug, you can just subscribe motu-release to the existing bug report 87 [01:33] <zooko> Thanks for the explanations, slangasek. 88 [01:33] <slangasek> (but be sure to fill in the information about why it should get an exception!) 89 [01:33] <slangasek> no problem :) 90 [01:34] <warner> I'll do the same for pycryptopp-0.5.15. Both will need an FFE, which will be easier to argue for pycryptopp (the 0.5.14-0.5.15 delta was a minor bugfix that doesn't affect debian), than for foolscap (which is a larger upgrade, since both debian and ubuntu had fallen a year behind upstream) 91 [01:34] <slangasek> in cases where there's no bug report open, though, requestsync is a very nice way to request freeze exceptions using the '-e' option 92 [01:34] <slangasek> when it opens the bug, it subscribes the -release team for you 93 [01:35] <zooko> I still kind of think we shouldn't bother FFE'ing pycryptopp-0.5.15. 94 [01:35] <zooko> We have to FFE foolscap-0.4.2 95 [01:35] <zooko> https://bugs.launchpad.net/ubuntu/+source/foolscap/+bug/419510 96 [01:35] <zooko> And we have to FFE Tahoe-LAFS 97 [01:35] <zooko> But we don't have to FFE pycryptopp-0.5.15 in order to get Tahoe-LAFS in. 98 [01:36] <warner> yeah, if the tahoe package had actually made it in, then we'd need the pycryptopp-0.5.15, but if we can change tahoe a bit before resubmitting it, we can go with 0.5.14 99 [01:37] <zooko> It doesn't *hurt* to also FFE pycryptopp-0.5.15, but I guess I can't honestly claim in the FFE request that it is important to make an exception for it! :-) 100 [01:37] <zooko> Well, I really should attend to my family and maybe have a quick nap. 101 [01:37] <slangasek> ok :-) 102 [01:38] <warner> OTOH, accepting tahoe is a much larger decision than accepting a pycryptopp upgrade 103 [01:38] <slangasek> zooko: thanks for coming! 104 [01:38] <warner> i mean, if they accept tahoe, then they're highly likely to accept a new pycryptopp, or something 105 [01:39] * zooko lurks 106 [01:39] <slangasek> warner: I think I would recommend filing a single bug report requesting the freeze exception for both packages, and laying out the options for motu-release to consider 107 [01:40] <warner> yeah, that sounds like a good plan 108 [01:42] <slangasek> if there are no other questions, then, I'm going to wander away from the keyboard now :-) 109 [01:42] <warner> slangasek: thanks for all the help! 110 [01:42] <slangasek> feel free to follow up in #ubuntu-motu 111 [01:42] <slangasek> warner: my pleasure!