16:08:49 <tumbleweed> #startmeeting Weekly MOTU Meeting
16:08:49 <meetingology> Meeting started Thu Sep 20 16:08:49 2012 UTC.  The chair is tumbleweed. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
16:08:49 <meetingology> 
16:08:49 <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
16:09:18 <tumbleweed> Agenda: https://wiki.ubuntu.com/MOTU/Meetings
16:09:26 <tumbleweed> (nothing new, that I see)
16:09:32 * micahg has somethin
16:09:52 <tumbleweed> \o/
16:09:56 <tumbleweed> #topic Review of previous action items
16:10:03 <tumbleweed> #link https://wiki.ubuntu.com/MOTU/Meetings/2012-09-06
16:10:24 <tumbleweed> #subtopic Killing off sqlite 2 (src:sqlite)
16:10:32 <tumbleweed> xnox: you had an action item
16:10:38 <tumbleweed> micahg: is this your something?
16:10:59 <micahg> tumbleweed: no, although that one is looking more like a pipe dream ATM...
16:11:06 <tumbleweed> yeah
16:11:20 * micahg thinks he'd be tarred and feathered if he dropped asterisk...
16:11:29 <tumbleweed> hehe
16:12:14 <tumbleweed> well, that's it for the previous action items
16:12:21 <tumbleweed> micahg: what's your topic?
16:12:28 <micahg> RC bugs in Ubuntu
16:12:38 <tumbleweed> #topic RC bugs in Ubuntu
16:12:41 <tumbleweed> micahg: all yours
16:12:54 <tumbleweed> (the bugs too, if you want)
16:13:25 <micahg> we have a new wiki page explaining RC bug targeting
16:13:27 <micahg> #link https://wiki.ubuntu.com/RCBugTargetting
16:13:32 <xnox> tumbleweed: yes. I have updates =)
16:14:01 <micahg> so, while in the past we've tried to keep up with RC bugs in Debian, we have our own as well that should be addressed
16:14:03 <xnox> tumbleweed: poke me, when we can come back to that topic.
16:14:27 <micahg> once the RC bugs are triaged by the release team, if they're targeted, they end up on this report
16:14:34 <micahg> #link http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-tracking-bug-tasks.html
16:14:45 <micahg> there's a universe section there that we should keep an eye on
16:15:20 <tumbleweed> indeed, we should
16:15:38 <micahg> also, I've heard that some bugs have ended up on the wrong list and been marked rls-q-notfixing, we should probably review the bugs with that tag for any relevant universe bugs and make sure they're triaged appropriately
16:16:07 <micahg> we should also think about if we want to drop packages with outstanding RC bugs before release (or try to SRU them shortly thereafter)
16:16:34 <micahg> with a more active backports team now, dropped packages seem like less of an issue
16:16:50 <tumbleweed> I don't think there's much point in dropping packages until we start using that a lot more actively
16:17:09 <tumbleweed> otherwise it penalizes packages that have people paying attention to them
16:17:38 <micahg> well, ideally, we'd try to fix the issues
16:17:58 <tumbleweed> so we should add reviewing that list as a standing agenda item
16:18:22 <tumbleweed> (and with my release team hat on, I should pay slightly more attention to bug targetting)
16:18:41 <micahg> I had a WI to write criteria for dropping packages from multiverse/universe, I think it should be similar to Debian, RC bug open for 6 mo w/no attention (and I would think a dead/inactive upstream)
16:19:16 <tumbleweed> I can add something looking for these rc tagged bugs to http://people.ubuntuwire.org/~stefanor/ubuntu-neglected-packages/
16:19:31 <micahg> that's the testing drop criteria AIUI, but since we have no equivalent of unstable where packages can hide and not be released, I think we're forced to drop
16:20:05 <micahg> well, RC is targeted + High/Critical importance
16:20:08 <jtaylor> dropping will not really help for upgrades
16:20:43 <jtaylor> so we still are likely to get complaints about the removed packages
16:20:46 <micahg> jtaylor: true, people are stuck with the old version of the package, but if it gets fixed later and backported, they could get an upgrade
16:20:47 <tumbleweed> I thought the upgrader removed removed packages?
16:20:55 <micahg> it offers to
16:23:10 <tumbleweed> done with this topic?
16:23:29 <micahg> yeah, I think so
16:23:53 <tumbleweed> #topic Killing off sqlite 2 (src:sqlite)
16:23:56 <tumbleweed> xnox:
16:24:24 <xnox> yeah. About GPE - it's a GTK based desktop envrionment target at small-screen device, e.g. phones.
16:24:31 <xnox> it's quite dated and on life support.
16:24:47 <tumbleweed> but on enough life support that people want it in Debian?
16:24:58 <xnox> after talking to upstream, they ported it from GTK+ 2 -> 3 and Sqlite 2 -> 3
16:25:11 <tumbleweed> oh, that sounds fairly alive
16:25:11 <xnox> very rapidly. After like years on inactivity....
16:25:28 <xnox> maybe just waiting for a kick =)
16:25:33 <xnox> it has popcon 0
16:25:44 <tumbleweed> still, we might have to wait a while for a new upstream release with these ports?
16:25:50 <xnox> gtk3/sqlite3 is not release nor fully working yet.
16:25:53 <micahg> awesome, can we get Debian to update?
16:25:56 <micahg> oh :*
16:26:29 <jtaylor> we could drop just drop it, it can come back later
16:26:48 <tumbleweed> but there's still more to drop before sqlite can go, right?
16:26:52 <jtaylor> assumings its the only sqlite2 blocker
16:26:59 <xnox> Debian maintainer said in private mail that killing sqlite2 is a bit pointless, ubuntu is not embedding friendly anyway and generally doesn't mind if ubuntu drops GPE and will not recommend upstream to port to newer API/ABI
16:27:01 <tumbleweed> so, we can just not block on gpe
16:27:20 <xnox> i would like to recommend dropping those 14 package (gpe related)
16:28:16 <micahg> yeah, I'd be for that if they're the last bastions of sqlite2 in the archive
16:28:24 <xnox> https://docs.google.com/spreadsheet/ccc?key=0Ak2xRmRUt6S4dHZfZWdhbVdiMl9HbWRHazNfOFM1aWc
16:28:35 <xnox> I started marking stuff.
16:28:56 <xnox> gambas2/3 is a programming language with sqlite2&3 binding -> drop sqlite2 bindings
16:29:00 <xnox> (packages)
16:29:20 <xnox> the new asterisk has all modules ported to sqlite3, so we'd just drop sqlite2 modules.
16:30:04 <micahg> xnox: are there concerns with upgrades losing data or are the plugins smart enough to handle that?
16:30:05 <xnox> that leaves chasing up csync2, kannel, qof, qsf, sqliteodbs and teleport (6)
16:30:36 <xnox> micahg: plugins are not smart enough. Ideally people should not have been using sqlite2 plugins, but obviously if it's an old install they just carry on.
16:30:57 <xnox> it's a shame that sqlite3 cannot read/convert sqlite2 databases, so my "upgrade plan" is
16:31:16 <xnox> to keep sqlite2 for an extra release after we drop dependencies.
16:31:31 <xnox> that will make LTS -> LTS upgrade 'interesting'
16:32:38 <xnox> we probably should start dropping agressivly. then people will get the hint that they need to migrate using tools in precise
16:34:12 <xnox> anybody knows how the rest of the world migrated from sqlite2 -> 3?
16:34:44 <tumbleweed> no idea :/
16:35:11 <micahg> probably happened years ago :-/
16:35:26 <tumbleweed> before sqlite was really popular
16:35:46 <micahg> Last sqlite2 release was Dec 2005
16:38:09 <tumbleweed> so, I can't see us dropping everything any time soon
16:38:20 <tumbleweed> but we could start disabling sqlite2 modules
16:38:32 <debfx> micahg: even fedora still ships sqlite2
16:40:13 <micahg> hrm, I guess we could wait one more release at this point, but I think asterisk would be a prime place to start dropping support for sqlite2 since it's already got its own security issues
16:41:44 <tumbleweed> no objection from me
16:41:49 <tumbleweed> shall we move on?
16:44:05 <micahg> sure
16:44:32 <tumbleweed> #topic Update from DeveloperAdvisoryTeam
16:44:34 <tumbleweed> anyone here?
16:45:57 <tumbleweed> #topic Review UbuntuDevelopment/BugFixingInitiative
16:46:08 <tumbleweed> #link https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative
16:46:33 <tumbleweed> I'm seeing quite a bit of activity on the missing homepages
16:46:45 <tumbleweed> don't know if we are hooking anyone, though
16:47:41 <jtaylor> I recently proposed on -devel to add syncs/merges from wheezy to the list of easy fixes
16:47:56 <micahg> they're not all necessarily easy
16:48:20 <jtaylor> most of the syncs are
16:49:35 <tumbleweed> it's certainly something that new developers should learn
16:49:42 <tumbleweed> but it's going to be fairly far down the line
16:50:05 <tumbleweed> reviewing merges can be really hard (when nobody has cared about them for years)
16:51:11 <jtaylor> we can do some prefiltering for new contributers
16:51:22 <jtaylor> list merges where the versions are not far appart
16:51:31 <jtaylor> or no mom conflicts
16:51:35 <tumbleweed> and that have a linked bug, fixed in debian?
16:51:55 <jtaylor> an unblock already implies a fixed bug in most cases
16:52:05 <tumbleweed> that's a temporary thing until wheezy releases
16:52:17 <jtaylor> yes but why not use this good oportunity?
16:52:34 <tumbleweed> oh, sure
16:52:50 <tumbleweed> want to prepare a list?
16:53:26 <jtaylor> I can try, if my sql lacking skills don't get in the way
16:54:00 <tumbleweed> #action jtaylor to look at producing a list of easy syncs
16:54:00 * meetingology jtaylor to look at producing a list of easy syncs
16:54:14 <tumbleweed> #topic any other business?
16:55:00 <tumbleweed> chair for next week?
16:56:04 <tumbleweed> (ok, not next week, the week after)
16:57:01 <tumbleweed> come come
16:58:02 * micahg will be around, but quite busy
16:59:13 * tumbleweed presumably will be around too, but I tend to be at the pub
16:59:27 <tumbleweed> ok, let's call this
16:59:30 <tumbleweed> #endmeeting