Ubuntu Wiki

   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!