=== nhandler changed the topic of #ubuntu-classroom to: Ubuntu Classroom || Support in #ubuntu || https://wiki.ubuntu.com/Classroom || https://wiki.ubuntu.com/Packaging/Training || Now: Feature Freeze and Freeze Exceptions || Upcoming: Fri 28 Aug @ 22:00 UTC: Triaging Sound Bugs; Mon 31 Aug - Fri 4 Sept 2009: Ubuntu Developer Week; Fri Sep 4 @ 21:00 UTC: How to run a successful Jam || Run 'date -u' in a terminal to find out the UTC time
[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.
[01:00] <nhandler> slangasek: The floor is yours
[01:00]  * slangasek waves
[01:00] <slangasek> who all is here for the session?
[01:00] <slangasek> (as opposed to just idling :)
[01:00] <nhandler> o/
[01:01] <slangasek> er, heh
[01:01] <slangasek> nobody else? :-)
[01:01] <Daviey> no :)
[01:02] <warner> I'm listening
[01:02] <slangasek> oh yay, people!
[01:02] <slangasek> so the thing that makes this topical is this: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-August/000606.html
[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 :)
[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
[01:04] <slangasek> so having a broad rule, that past a certain date we only do bugfixes, helps with that
[01:05] <slangasek> bugfixes including everything from fixing segfaults, to typos, to documentation corrections, to translations...
[01:05] <slangasek> but of course, every rule has exceptions, and ours are detailed here: https://wiki.ubuntu.com/FreezeExceptionProcess
[01:05] <slangasek> warner: have you had occasion to request a feature freeze exception before?
[01:06] <warner> nope, but there's a decent probability that I will need to in the next week :)
[01:06] <warner> tell me how it works!
[01:06] <slangasek> :)
[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
[01:07]  * Daviey must go to bed, but looks forward to reading scrollback. nn o/
[01:07] <slangasek> but the basics are described right in the first section - file a bug report, and include:
[01:07] <slangasek> # A description of the proposed changes, with sufficient detail to estimate their potential impact on the distribution
[01:07] <slangasek> # A rationale for the exception, explaining the benefit of the change
[01:07] <slangasek> # Any additional information which would be helpful in considering the decision
[01:08]  * slangasek waves to Daviey 
[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.
[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
[01:09]  * warner nods
[01:10] <slangasek> I don't really have much to add, beyond that... I'll take questions, though :)
[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
[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
=== zooko` is now known as zooko
[01:11] <slangasek> so instead of subscribing motu-release, you can subscribe the delegate instead, which is faster
[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
[01:11] <slangasek> warner: ok
[01:11] <warner> or I may FFE pycryptopp to get the newer version in (which tahoe depends upon)
[01:12] <warner> but I believe both will fall under the "FeatureFreeze for bug-fix-only updates" clause
[01:12] <slangasek> tahoe-lafs is currently not in the archive, so I think that needs an FFe regardless
[01:12] <slangasek> new packages are almost always considered "features"
[01:13] <slangasek> the wiki page talks about new packages specifically: https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze%20for%20new%20packages
[01:13] <nhandler> What are ubuntu/motu -release looking for when deciding whether to accept a Freeze Exception request?
[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
[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)
[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
[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 :)
[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
[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
[01:17] <slangasek> well, the people who have to be convinced are the motu-release team
[01:17] <slangasek> who are MOTUs, but a specific subset of MOTUs
[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
[01:18] <zooko> So, I might have missed some of the lesson.  The deadline for Feature Freeze for Karmic passed 18 minutes ago, right?
[01:18] <slangasek> though they may ask for you to get the FFe approved first before they upload
[01:18] <slangasek> zooko: yes - which means new packages uploaded from here have to get feature freeze exceptions (FFe)
[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.
[01:20] <zooko> In fact, in addition to being advocated on REVU, Dustin Kirkland also uploaded it.
[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
[01:20] <zooko> Okay, so it was uploaded but then, um, unuploaded.  :-)
[01:20] <slangasek> rejected from the queue, yes. :)
[01:21] <zooko> Okay.
[01:21] <zooko> So Tahoe-LAFS is in the state of "advocated on REVU but not uploaded in the queue".  Is that right?
[01:21] <zooko> And zfec is in the same state.
[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
[01:22]  * zooko looks
[01:22] <zooko> https://bugs.launchpad.net/foolscap/+bug/419510
[01:22] <james_w> zooko: note that new packages from REVU generally need two advocates
[01:23]  * zooko looks at REVU
[01:24] <james_w> zfec appears to have been uploaded to NEW
[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
[01:24] <zooko> So, what state is foolscap in? It is in the "request upgrade" state.
[01:25] <slangasek> zfec: https://launchpad.net/ubuntu/karmic/+queue
[01:25] <slangasek> er, except it's on the second page; I'll have to fix that by accepting some binaries, I guess. :)
[01:25] <zooko> slangasek: so zfec is in the "queued" state?  Which is after the "REVU" state and before the "really into Karmic" state?
[01:26]  * Laney wonders what these states are
[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
[01:26] <zooko> Hey, there's a pycryptopp on that page.
[01:28] <slangasek> for new packages after feature freeze, the pipeline is: REVU -> motu-release freeze exception -> upload -> archive admin processing -> into karmic
[01:29] <slangasek> those packages that were uploaded before the FF started can reasonably be accepted by the archive admin without freeze exception paperwork
[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.
[01:30]  * slangasek nods
[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)
[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
[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
[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
[01:33] <zooko> Thanks for the explanations, slangasek.
[01:33] <slangasek> (but be sure to fill in the information about why it should get an exception!)
[01:33] <slangasek> no problem :)
[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)
[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
[01:34] <slangasek> when it opens the bug, it subscribes the -release team for you
[01:35] <zooko> I still kind of think we shouldn't bother FFE'ing pycryptopp-0.5.15.
[01:35] <zooko> We have to FFE foolscap-0.4.2
[01:35] <zooko> https://bugs.launchpad.net/ubuntu/+source/foolscap/+bug/419510
[01:35] <zooko> And we have to FFE Tahoe-LAFS
[01:35] <zooko> But we don't have to FFE pycryptopp-0.5.15 in order to get Tahoe-LAFS in.
[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
[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!  :-)
[01:37] <zooko> Well, I really should attend to my family and maybe have a quick nap.
[01:37] <slangasek> ok :-)
[01:38] <warner> OTOH, accepting tahoe is a much larger decision than accepting a pycryptopp upgrade
[01:38] <slangasek> zooko: thanks for coming!
[01:38] <warner> i mean, if they accept tahoe, then they're highly likely to accept a new pycryptopp, or something
[01:39]  * zooko lurks
[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
[01:40] <warner> yeah, that sounds like a good plan
[01:42] <slangasek> if there are no other questions, then, I'm going to wander away from the keyboard now :-)
[01:42] <warner> slangasek: thanks for all the help!
[01:42] <slangasek> feel free to follow up in #ubuntu-motu
[01:42] <slangasek> warner: my pleasure!
=== warner is now known as warner_away
=== nhandler changed the topic of #ubuntu-classroom to: Ubuntu Classroom || Support in #ubuntu || https://wiki.ubuntu.com/Classroom || https://wiki.ubuntu.com/Packaging/Training || Upcoming: Fri 28 Aug @ 22:00 UTC: Triaging Sound Bugs; Mon 31 Aug - Fri 4 Sept 2009: Ubuntu Developer Week; Fri Sep 4 @ 21:00 UTC: How to run a successful Jam || Run 'date -u' in a terminal to find out the UTC time
=== Traveler is now known as Guest7144
=== warner_away is now known as warner
=== porthose is now known as porthose|AFK
=== Quintasan_ is now known as Quintasan
=== warner is now known as warner_sleep
=== Traveler is now known as Guest98445
=== goshawk_ is now known as goshawk
[19:48] <Bazoul> hi !
[19:48] <Bazoul> anydody home ?
[19:52] <mimor> yup
[19:56] <eurythmia> no ... I'm at work.
=== warner_sleep is now known as warner
[21:13]  * limcore leaves his weed in locker room and sits in chair near blackboard
[21:23] <limcore> there should be some ringbell bot that would ping everyone at 21 UTC ;)
[22:34] <mhall119|work> ring