20110601
DistributedDevelopment steering meeting held in #ubuntu-meeting on 2011-06-01 at 1100 UTC.
Chair: barry
Apologies
Agenda
- Attendance/apologies
- Action items
jelmer to study the feasibility of merge helper (bug 608675) as an intermediate step for quilt support
- poolie to send condensed summary of uds sessions
Riddell to give summary of current import failures with rough HARD/NOTHARD classification, and failure numbers (rejected)
jelmer to look into bug 609187 (warn when package import is out of date)
- Package importer progress
- Bugs of interest:
- Alternate meeting times?
- Any other business?
Summary
- maxb says it's not worth doing the HARD/NOTHARD classification since all the work to do that is most of the work to just fix the problem
- we'll keep 1100utc as meeting time. it's the least bad of all the options.
<maxb> I have added "UDD failure ratchet: 487" to the topic of #bzr, to 1) make the descending count more visible, and 2) ensure it stays descending
New Actions
Log
<barry> #startmeeting
<MootBot> Meeting started at 06:09. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK],
[VOTE]
<barry> hello and welcome to this week's ubuntu distributed development
steering meeting. who's here today? [07:10]
* jelmer waves
<barry> [LINK] https://wiki.ubuntu.com/DistributedDevelopment/20110601
<MootBot> LINK received:
https://wiki.ubuntu.com/DistributedDevelopment/20110601
<barry> no poolie? [07:11]
<jelmer> I just pinged in #bzr
<barry> thanks!
<barry> hi jam [07:12]
<james_w> yo
<jam> hi barry. Why did I think this was the "not-a-meeting" week?
<barry> ;)
<jam> I guess because I'm crazy
<jam> I see it on the calendar
<barry> let's give poolie another minute or so [07:13]
<jam> I don't think he realized, he didn't mention it in our standup this
morning
<jam> I wouldn't wait too long
<barry> okay then
<barry> [TOPIC] [07:14]
<MootBot> New Topic:
<barry> * Action items
<barry>
<barry> * jelmer to study the feasibility of merge helper
([[https://bugs.launchpad.net/bzr-builddeb/+bug/608675|bug 608675]])
as an intermediate step for quilt support
<barry>
<ubottu> Ubuntu bug 608675 in bzr-builddeb "merge-package should have support
for manipulating quilt v3 patch stacks" [High,In progress]
<jelmer> I've been sprinting and holiday'ing since our last meeting so I
haven't had much time to look at that yet [07:15]
<barry> okay, no worries, we'll just leave it on for next time
<barry> * poolie to send condensed summary of uds sessions
<barry>
<barry> does anybody know, was this done?
<jam> barry: I assume he would send it to the udd list, and I haven't seen
anything from him since April [07:16]
<jam> so I'm guessing not
<barry> yep, i just looked at gmane and didn't see anything. okay, continuing
[07:17]
<barry> * Riddell to give summary of current import failures with rough
HARD/NOTHARD classification, and failure numbers
<barry>
<barry> p-i.u.c looks flat. i guess this is still todo. [07:18]
<barry> * jelmer to look into
[[https://bugs.launchpad.net/udd/+bug/609187|bug 609187]] (warn when
package import is out of date) [07:19]
<barry>
<ubottu> Ubuntu bug 609187 in Ubuntu Distributed Development "users are not
warned when branching ubuntu:foo (or lp:ubuntu/foo) and the package
import of foo is out of date" [High,Triaged]
<barry> jelmer: continue for next time?
<jelmer> barry: yeah
<barry> k
<barry> [TOPIC] * Package importer progress [07:20]
<barry>
<MootBot> New Topic: * Package importer progress
<jam> jelmer: if you're interested, I'd be happy to pair with you on some of
those
<jelmer> jam: me too, perhaps next week some time ?
<barry> jam, jelmer awesome
<Riddell> hi [07:21]
<barry> any status on the package importer? did i see some traffic on that
the last couple of days?
<barry> Riddell: hi
<Riddell> on the classification I discussed it with maxb who said that any one
error would have several reasons for failure
<Riddell> and by the time you diagnose the failure enough to classify it
you're most of the way to fixing it any way
<jam> jelmer: sure [07:22]
<jam> I'm off the rest of this one :)
<maxb> Indeed - I propose that attempting an overall classification of all
current failures is less valuable that iterating a "pick one; fix"
approach
<maxb> s/that/than/ [07:23]
<barry> Riddell: question: once you've done that for one bug in a class, does
that help with the other similar failures?
<maxb> When I say "pick one", I mean one distinct failure cause, rather than
one single package
<barry> maxb: hi.
<jam> maxb: one of my concerns is this failure:
http://package-import.ubuntu.com/status/5cabf40249181425fdb66e301d75f02b.html
[07:24]
<Riddell> barry: depending on the bug you can do a mass retry for all the ones
with that error, then you just have to see which ones it fixes and
which are caused by something else
<jam> it feels like you have to check each package manually
<jam> with 100 failures, that's a lot of overhead.
<jam> any ideas on it?
<maxb> We looked a little at that one at the sprint, and established that
there are at least two sub-classes to that traceback
<maxb> One involves the revision ids having identical timestamps, one not.
[07:25]
<barry> maxb, Riddell okay. it sounds like the effort is better spent on just
fixing the problems. i can take this one off the todo list. [07:26]
<maxb> I got as far as rerunning the importer for a subset of those packages
locally, but did not return to analyze the results yet
<barry> jam, jelmer if i can put in a plug for increasing the priority of
609187 then :). having that warning will i think at least give people
a better feeling that they won't be wasting their time, and will
simplify the docs. [07:28]
<jelmer> barry: ok
<barry> any other thoughts on the package importer?
<jam> barry: was "run 'bzr is-package-current'" a sufficient first pass at
that?
<jam> I think there is already code for that, just waiting on making it
faster. [07:29]
<barry> jam: is that a real command?
<maxb> I have added "UDD failure ratchet: 487" to the topic of #bzr, to 1)
make the descending count more visible, and 2) ensure it stays
descending
<jam> barry: I don't know the command name. I do know someone wrote a plugin
that interfaces with launchpadlib
<barry> jam: i must have missed it [07:30]
<maxb> In doing so, I have realized that it would be useful for the
package-import status page to separately count permanent and
will-be-retried failures
<maxb> For example, it's up to 522 right now, but many of those appear to be
transient errors [07:31]
<barry> maxb: that would be nice to know
<barry> maxb: what's the interval for auto-retries? [07:32]
<jam> barry: maybe it was just discussed in the bzr sprint?
<jam> I remember discussing it
<maxb> barry: Looks to be 3 hours currently - presumably to bridge a typical
Launchpad downtime
<barry> jam: on the face of it, some easy to spell check command would be a
decent first shot
<barry> maxb: ack, thanks
<barry> okay, moving on... [07:33]
<barry> [TOPIC] Bugs of interest:
<MootBot> New Topic: Bugs of interest:
<barry> http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html
<maxb> <barry> p-i.u.c looks flat. <--- but remember the scale is logarithmic
<MootBot> LINK received:
http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html
<barry> maxb: right, thanks for the reminder!
<vila> sorry for the late arrival, lunch time [07:34]
<barry> vila: hi
<barry> wow. lots of bugs in needs release. do you know which (if any) are
being back ported to stable releases and which are for the next
release?
<jam> barry:
http://webnumbr.com/ubuntu-package-import-failures.max%28800%29.min%28400%29
[07:37]
<jam> [link]
http://webnumbr.com/ubuntu-package-import-failures.max%28800%29.min%28400%29
<MootBot> LINK received:
http://webnumbr.com/ubuntu-package-import-failures.max%28800%29.min%28400%29
<jam> barry: bzr bugs generally go straight to released. plugin bugs go into
needs-release [07:38]
<barry> jam: ah, i didn't know that!
<jam> I think we just need to poke jelmer
<jelmer> au!
<jam> he did all that wonderful bug fixing, just needs to release it to the
public
<barry> c'mon jelmer, bask in the glory! [07:39]
<jelmer> yeah, I need to do a few more releases
<barry> any other thoughts on bugs?
<barry> [TOPIC] * Alternate meeting times? [07:40]
<MootBot> New Topic: * Alternate meeting times?
<barry> so, 1100utc is doable for me, but it's way to early for slangasek. i
fear there's no way to have one single time that works for au,
us-east, us-west, and euro. otoh, it's hard enough to remember to
meet at the same time (for me too!) so alternating will only make it
worse. i'm open to any thoughts. what are your preferences? [07:42]
<jam> I prefer a same-time meeting [07:43]
<jam> but right now that is in my favor...
<barry> jam: and 2100utc, or thereabouts is still bad for you, right? [07:44]
<vila> same here, Wednesday is less practical family wise though (shudder, one
more constraint type ;-/)
<jelmer> 1100utc works well for me too, as well as in the .au morning
<barry> i talked briefly w/slangasek and he's okay if we keep a time more
convenient to the bzr center of mass, so i guess for now we'll just
keep it at 1100utc [07:45]
<jam> barry: 2100 is about 11pm. So it could work but not something I can do
regularly [07:46]
<barry> jam: yep, and i think moving it an hour or so earlier starts to make
it infeasible for pooie
<barry> er, poolie
<barry> okay, 1100utc it is
<barry> [TOPIC] Any other business?
<MootBot> New Topic: Any other business?
<barry> nothing really on my plate, anything else from y'all? [07:48]
<vila> You covered max's wonders earlier ?
<barry> vila: ? [07:49]
<vila> diagnosis on import failures, bugs with recipes to fix, etc
<barry> vila: yep
<vila> ok [07:50]
<barry> okay then, i think we're done.
<barry> #endmeetingDistributedDevelopment/20110601 (last edited 2011-06-01 14:56:46 by mail)