## page was renamed from DistributedDevelopment/20110504 [[DistributedDevelopment]] steering meeting held in {{{#ubuntu-meeting}}} on 2011-05-18 at 1100 UTC. '''Note the time change.''' Chair: barry = Apologies = = Agenda = * Attendance/apologies * Action items * jam to propose/report plan for quilt imports '''(obsolete)''' * poolie to send link to plenary proposal. all to help finish that '''(done)''' * UDS-O session review * https://blueprints.launchpad.net/udd/+spec/foundations-o-udd-planning * https://blueprints.launchpad.net/udd/+spec/foundations-o-udd-onramp * Package importer progress * Bugs of interest: * See http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html * Any other business? = Summary = * UDS sessions well attended, with positive, encouraging feedback * solid feedback received on priorities for UDD * fixing "not hard" import failures should cut total failures roughly in half * bfbia was well received; prototype possible by UDS-P * riddell is getting bugs fixed * bzr 2.4 is going to be much faster for many things thanks to jam = New Actions = * 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 * jelmer to look into bug 609187 (warn when package import is out of date) = Log = {{{ #startmeeting Meeting started at 06:00. The chair is barry. Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] hello everyone and welcome to this week's udd steering committee meeting. who's here today? hi all hi hi Hi moi [LINK] https://wiki.ubuntu.com/DistributedDevelopment/20110504 LINK received: https://wiki.ubuntu.com/DistributedDevelopment/20110504 hello * poolie prods vila [07:02] it's probably a little early for slangasek :) hi [07:03] hi! poolie: vila isn't in the channel let's go? okay! what a great uds [TOPIC] action items New Topic: action items poolie: it was! [07:04] * jam to propose/report plan for quilt imports now, i know there was an idea that maybe there was a better/easier way to accomplish the same goal w/o looms? i don't think jam specifically sent a plan about it barry: no specific progress. Focused on other things, but I think this is still one of the "we need to get to this soon" for UDD there was some interesting discussion about this along the lines of maybe we should just do the merge in a similra way and at least as well as people do by hand [07:05] and then later move to looms so that would be basically, take the patches off the wt, reapply them merging as you go I think there was also a question of whether we could just write a helper that could stitch together quilts as part of post-merge stuff right i guess we should have an action to make a specific proposal nad decisiono on this [07:06] it is a compromise but perhaps a good intermediate one poolie: though it might also lead to something that allows us to merge looms, which we also don't have yet indeed at least, leads us to exploring the area, even if the exact code isn't usable do people want to discuss it here and now or should we just leave the item to make a proposal [07:07] poolie: i agree. i think we should remove jam's action item and replace it with one to study the feasibility of merge helper instead. jelmer, would you take that? poolie, already in my queue :) bug 608675 [07:08] cool Launchpad bug 608675 in bzr-builddeb "merge-package should have support for manipulating quilt v3 patch stacks" [High,In progress] https://launchpad.net/bugs/608675 next? I think the infrastructure we'd add to support that would be useful for some other kinds of custom merges, so even if it's not used by udd in the long term it's still a useful investment for bzr. yes jelmer: awesome. jam: any objections to removing your action item? barry: fine with me well, regarding looms, I already encountered bugs with just trying to use the same loom on my desktop and my laptop, i.e. just pushing looms has already some rough edges, I think I understand enough now to write failing tests for it [ACTION] jelmer to study the feasibility of merge helper (bug 608675) ACTION received: jelmer to study the feasibility of merge helper (bug 608675) vila: as i mentioned to poolie, i'm somewhat conflicted, because aside from udd, i'd still love to see great support for looms :) right vila, poolie is there an action item lurking there for next time? [07:10] however, perhaps we should skew mor etowards shorter dependency chains barry: me too, I think properly working looms would be really nice for this oh, what I meant was that I will work on that as I definitely want better loom support not blocking quilt support on getting great looms, including in lp etc right, let's get rid of the rough edges first poolie: +1 [07:11] sounds good. no action item then, but if you have some good stuff to report next time, we'll definitely make time for that it's partly the lp dependency that tips the scales for me tehy are supported but you can't properly viwe or review them yet k yep okay, this one's done but just ftr: [07:12] * poolie to send link to plenary proposal. all to help finish that just to be clear, the oaction here is that jelmer will make a more detailed proposal about doing it this one yes, i'm happy it was done seemed pretty popular jml and james_w also did cool presesntations yep, both were great. definitely check out the online videos (not sure if they're up yet) [TOPIC] * UDS-O session review [07:13] New Topic: * UDS-O session review * https://blueprints.launchpad.net/udd/+spec/foundations-o-udd-planning * https://blueprints.launchpad.net/udd/+spec/foundations-o-udd-onramp notes at http://summit.ubuntu.com/uds-o/meeting/foundations-o-udd-onramp/ and http://summit.ubuntu.com/uds-o/meeting/foundations-o-udd-planning/ thanks [07:14] these were also good the onramp session was less onramp and more feedback. i was really happy to see a general enthusiasm and buy-in for udd. yes, definitely a step up since last time i should probably take an action to send a condensed form of these good idea [ACTION] poolie to send condensed summary of uds sessions [07:15] ACTION received: poolie to send condensed summary of uds sessions there are a bunch of things but it seemed there was agreement the most useful immediate thing was to get all imports working thats also a nice simple clear goal there was a run-down of the top failures, and none of the really big ones seemed intractable [07:16] so i propose to have the canonical-bazaar team do that first iirc, fixing those would slash the failures roughly in half right do we want to timebox that effort? some have been fixed this week [07:17] mm Of the failures, the one most obviously in need of design is how to handle multiple source tarball packages one good arbitrary time would be the next Canonical quarterly planning cycle which would be ... the start of august? There are 66 multiple source tarball failures so the goal is only "hard" failures left by the start of August? [07:18] maxb: what's the underlying cause of those? pretty much barry: The importer specifically omits support for them or no failures left, except those with an explanation why it's not worth doing? i think there is some kind of effect where the importer is seen as scary to change or, not in the normal queue of things people look at i'd like to crack that [07:19] poolie: wasn't getting all the imports working a goal many quarters ago? yes, but there were too many other goals at the same time fair enough. so, this time for sure poolie: perhaps we can have an action item for next time which would be a summary of the current importer failures and a rough HARD/NOTHARD classification, along with # of failures each would fix? [07:20] good idea [07:21] also, let's keep score every week of the count great idea. who can i give that to? [07:22] http://webnumbr.com/ubuntu-package-import-failures LINK received: http://webnumbr.com/ubuntu-package-import-failures barry: I can try The top failure right now is fallout from packagers doing push --overwrite --- that's a hard one, because it will involve a fair bit of looking at individual branches Riddell: awesome, thaks vila: there's also a graph at the bottom of http://package-import.ubuntu.com/status/ er, thanks [ACTION] Riddell to give summary of current failures w/HARD/NOTHARD classification [07:23] ACTION received: Riddell to give summary of current failures w/HARD/NOTHARD classification right, honestly, none of them got the scale right though ;) any other feedback on the uds sessions? hm [07:24] spiv: but we could/should probably fix the one at p-i.u.c i would like suggestions on organizational or other hacks we can do to get the right attention on udd vila's link with spikes flattened somewhat: http://webnumbr.com/ubuntu-package-import-failures.below%283000%29 [07:25] i guess the other big thing at uds was discussion of bfbia which seemed generally welcomed... poolie: right, i should have included a link to that, sorry but probably.. .better to get this done first then think about it spiv: \o/ if we do well, we may still have a prototype by uds-p [07:26] Why do we allow --overwrite for those branches? poolie: that would rock. i want to convince ScottK by the sheer awesomeness of the feature :) spiv, we simply have no way to prevent it afaik poolie: that'd be neat :) [07:27] jelmer: well, setting append_revisions_only=True on those branches would at least discourage it? indeed :) doing that across all launchpad by default would be nice there's a bug for that shall we move on? [07:28] [TOPIC] * Package importer progress New Topic: * Package importer progress not sure there's much more to say about that one so... [07:29] [TOPIC] * Bugs of interest: New Topic: * Bugs of interest: pretty much covered it poolie: probably could be an action item. We could just go to the importer and do a for loop, since the james_w user can write to all those branches seem slike we still got through a lot of bugs [LINK] http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.htm LINK received: http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.htm you probably saw john's blog post for $branch in branches: bzr config -d$branch append_revision_only=True [LINK] http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html LINK received: http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html jelmer: heh, thanks once again, stunningly impressive the pqm machine is having a tough week :) jam: does --overwrite honor append_revisions_only ? :D jelmer: I can't say without testing one thing that sticks out there is the number of nonreleasede fixes [07:31] but it would still handle the primary case perhaps we need bzr-svn etc releases? most people don't --overwrite all the time (or the data may be old) poolie: not to mention that jubany is on 2.3 ? vila: wasn't there an action to get that updated? [07:32] is it now? it's not released yet just checked, 2.3.1 we could file an rt about that? jelmer: quick testing: "bzr push --overwrite" > bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "C:/Users/jameinel/dev/,tmp/x/". so, mostly: jml, james_w, barry, is there anything you think we should be doing but are neglecting? jelmer: so yes, append_revisions_only refused --overwrite [07:33] poolie: bug 609187 ;) Launchpad 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] https://launchpad.net/bugs/609187 jam: oh, great ! And what if you specify it in locations.conf ? jam: ah, interesting mm good idea jam: I should add a test for that and fix bzr-svn/bzr-hg/bzr-git :) oh, there's a related thing jam: Thanks which is that lp has been on a fairly old bzr for a while In that case, we need a --really-overwrite before we can turn on append_revisions_only for UDD branches, as the importer needs to be able to overwrite the branch if it detects a collision [07:34] and the bug that blocks upgrading is now fixed so, we can push that through vila: it has the same affect, but it won't affect *anyone else* maxb, we could potentially override append_revisions_only = False for the importer using locations.conf [07:35] maxb: the importer could temporarily unset that flag, push --overwrite, reset it. jam: bah, sorry, badly worded. What if the remote branch has append_revisions_only=True, but you say a_r_o = False in locations.conf vila: I would guess it would override :-/ just like all our other things do vila: That seems sensible - if somebody really wants to override they can always just edit .bzr/branch/last-revision vila: bzr has always been about consenting adults [07:36] I'm not sure if bzr+ssh will get in the way, and the remote bzr will refuse that takes a bit more to test yup, that's a flaw in our config scheme I think, this settings are under the server responsability and we should somehow require some special powers to change/override them jam: :) k so after lp is running a new bzr, we can start doing something towards a warning message maybe I should look at bug 609187 what else? Launchpad 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] https://launchpad.net/bugs/609187 [07:37] that's the one jelmer: that would be really great. it would really simplify the docs and give people peace of mind hope you don't mind... [ACTION] jelmer to look into bug 609187 ACTION received: jelmer to look into bug 609187 [LINK] https://launchpad.net/bugs/609187 LINK received: https://launchpad.net/bugs/609187 let's move on [07:38] we'll talk about it here [TOPIC] AOB New Topic: AOB any good news, or other interesting items folks have? [07:39] we fixed a ton of bugs [07:40] srus are proceeding riddell is getting some bugs fixed 2.4 is going to be much faster for many things thanks to jam i think that's it [07:41] thanks for coming guys on that note #endmeeting }}}