[[DistributedDevelopment]] steering meeting to be held in {{{#ubuntu-meeting}}} on 2011-01-26 at 2100 UTC. = Agenda = * Action items * ajmitch to come up with questions/topics for next meeting (re: REVU) * poolie to send bzr rotation pitch to platform mailing list * Bugs of interest: * http://pad.lv/674353 - graph packages built through UDD * http://pad.lv/556132 - don't drop SSH connection after sending 1GB; requested by kiko '''(done)''' * http://pad.lv/375013 - support committing direct to stacked branches '''(done)''' * bzr branches are too expensive to use for casual sponsoring, compared with downloading packages from my local mirror (slangasek) * [[https://launchpad.net/bugs/295274|watch file support]] * [[https://launchpad.net/bugs/653307|Import fails with missing referenced chk root keys]] * [[https://bugs.launchpad.net/bzr/+bug/603395|bzr commit in a heavyweight checkout does not propagate new tags]] * [[https://launchpad.net/bugs/653832|Import fails with "trying to import version ... again"]] '''(done)''' * [[https://launchpad.net/bugs/499684|Interface to dpkg-buildpackage inconsistent and not well documented]] * http://pad.lv/608450 and others - ways to update debian/control and versions from a recipe * AOB = Summary = * Bazaar team's [[https://wiki.canonical.com/Bazaar/Plan/2011/Tasks|plans for 2011]] * i believe we fixed 50% of the imports last week? * [[https://bugs.launchpad.net/~canonical-bazaar/+assignedbugs|Shortlist of bugs for Bazaar team]] = New Actions = * poolie to update hot bugs for next meeting * poolie to file bug about MOTD information for out-of-date packages * jam to review spiv's branch for bug 603395 * barry to file bug on debcommit/bzr commit * jam to follow up on pristine-tar stuff :) = Log = {{{ #startmeeting [16:00] Meeting started at 15:00. The chair is barry. Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] hi folks and welcome to this week's ubuntu distributed development meeting who's here today? o/ note that because we did the meeting last week largely in person at the natty rally, we don't yet have minutes up for the meeting on the 12th. hopefully we won't re-cover too much ground [TOPIC] agenda New Topic: agenda https://wiki.ubuntu.com/DistributedDevelopment/20110126 [LINK] https://wiki.ubuntu.com/DistributedDevelopment/20110126 LINK received: https://wiki.ubuntu.com/DistributedDevelopment/20110126 hello the raw transcript is in http://irclogs.ubuntu.com/2011/01/12/%23ubuntu-meeting.html#t21:06 hi james /wave jelmer, thumper, slangasek, ajmitch, james_w ping hi poolie [16:03] i like the hot bugs list hi i will take an action to bring that up to date for the next meeting, on the 10th feb i believe a few more things have been crossed off [16:04] we had a two-week sprint that was very productive yep, thanks [ACTION] poolie to update hot bugs list for next meeting ACTION received: poolie to update hot bugs list for next meeting i guess we'll just get started augh where did my morning go :/ [TOPIC] action items [16:05] New Topic: action items * ajmitch to come up with questions/topics for next meeting (re: REVU) ajmitch: i forgot, did we decide to keep this on the list? * ajmitch hasn't done much beyond the list that came up last time, sorry - that's probably fallen off pastebin by now barry: he wasn't there last time, so poolie had it stay [16:06] let's not just keep this thing dangling strike it from the list or discuss? ajmitch, do you have any particular things you think should be getting attention but aren't? let's discuss briefly if any come to mind now, let's do them in the meeting [16:07] otherwise if you want to nominate things, feel free to poke us any time ajmitch: I think the idea is that you can choose whether to bring stuff up or not, but we'd rather not have an on-going item that just never completes right I agree that the strength of that list is that it is nice and compact and *actionable* jam: right, I'd rather it not stay around [16:08] agreed. i'll strike it from the list for next week I don't really have any actionable items to discuss about REVU at this stage * poolie to send bzr rotation pitch to platform mailing list definitely today! \o/ ie keep it :) will do :) [16:09] It seems it would be interesting to have something revu-like integrated with the Launchpad merge-proposals stuff. though they may not be quite similar enoguh [TOPIC] bugs of interest New Topic: bugs of interest this list might be out of date, but let's go thru them quickly * http://pad.lv/674353 - graph packages built through UDD a gap analysis there could be good this was, specifically, that we'd insert markers to catch anything done by bzr builder or builddeb [16:10] we agreed to strike that particular implementation it's nontrivial work and it's not actually helping ubuntu developers poolie: so should the bug be closed as WontFix ? or is that bug #676766 [16:11] Launchpad bug 676766 in Ubuntu Distributed Development "insert package header field" [Undecided,New] https://launchpad.net/bugs/676766 instead, we'll measure things we're already doing that ought to correlate with user happiness/uptake jam: with a note next bug? * http://pad.lv/556132 - don't drop SSH connection after sending 1GB; requested by kiko [16:12] ] done, I believe fixed and deployed! you guys rock! * http://pad.lv/375013 - support committing direct to stacked branches done thanks to exarkun and mwh too you rock, jam! * bzr branches are too expensive to use for casual sponsoring, compared with downloading packages from my local mirror (slangasek) still on my rainy day hacking list lots of discussion at UDS, but I don't think we had strong concrete answers What class of solution is considered for that problem? I think it got put on the poker table (create a branch from a mirror tarball) you'd think Portland would give me rainy days to go around, but no and also shallow checkouts persia: I'm planning to implement support for automating mirroring of branches [16:14] Ah, OK. Thanks for the detail. i think we should keep this on the list, since it's a core improvement that the team is working on this is important to me even if other solutions (e.g., shallow branches) speed up the download from LP itself note that spiv and I were working on getting a fast shallow checkout from LP it is some of the specific things we discussed are in https://wiki.canonical.com/Bazaar/Plan/2011/Tasks [16:15] so it should be equiv to downloading a tarball from LP, which isn't as good as a local mirror including that (canonical-only, sorry) but better than full history I think it got slightly back-burnered vs other bzr work * [[https://launchpad.net/bugs/295274|(watch file support)]] - james_w and barry to sprint on that at uds-n [16:16] Ubuntu bug 295274 in Ubuntu Distributed Development "merge-upstream shouldn't require --version when debian/watch is present" [High,In progress] I don't think they got to it definitely talked about it note that i unassigned myself from this bug, sadly but no code was implemented jelmer has been hacking on that it needs some merge proposals reviewing ah, it says "jelmer hacked it together and will be submitting mps" Note that sometimes it is desireable to create a new upstream version which isn't the latest upstream version according to the watch file, depending on release status, etc. Please be sure to allow override, rather than relying purely on the watch file. [16:17] I don't think he has submitted anything persia: definitely. i don't think they plan to remove the explicit options, but just make the common case easy persia, "shouldn't /require/ --version" Just checking :) persia: I'm pretty sure the idea is that you don't *have* to specify version, but if you do, it will be used barry: sounds like 'in progress' but not closed yet [16:18] we'll keep it on the list; it's really nice to see progress on it (since i suck :) * [[https://launchpad.net/bugs/653307|Import fails with missing referenced chk root keys]] Ubuntu bug 653307 in Ubuntu Distributed Development "Import fails with missing referenced chk root keys" [Critical,In progress] this one falls under the general class of import failures, which i know is a top priority for the team [16:19] it is i believe we fixed 50% of the imports last week? [16:20] i wonder if the graph agrees? I'm pretty sure that specific bug is, restart them and they all work ah, ok *nice* http://package-import.ubuntu.com/status/ says it is back down a lot LINK received: http://package-import.ubuntu.com/status/ says it is back down a lot so that needs someone, probably spiv, to agree with james_w that it's ok to delete and restart it? nice that's a log scale of course [16:21] at the moment, it is all pretty manual meaning the software will crash if it ever reaches 0 :-) (jk) :) yes, that was bug #653832, right? Launchpad bug 653832 in Ubuntu Distributed Development "Import fails with "trying to import version ... again"" [High,Triaged] https://launchpad.net/bugs/653832 slangasek: nope, a different one bug 653307 Launchpad bug 653307 in Ubuntu Distributed Development "Import fails with missing referenced chk root keys" [Critical,In progress] https://launchpad.net/bugs/653307 (that one was coming up) ok it looks like bug 655307 is not blocked on james [16:22] jam: I thought 32 was the one that fixed 50% of the imports :) Launchpad bug 655307 in QBzr "using odt2txt to diff OOo documents" [Wishlist,Confirmed] https://launchpad.net/bugs/655307 ah, slangasek, yes that was the one I fixed we just need to do it which was 700 or so failures i know there was a bug about (or we talked about) making sure that bzr branch of a package that had import failures at least warned the user yes, we did talk about it i think we should file a bug poolie: i'll take that action item [16:23] i'll do that now oh, okay, i'll let you do it :) unless anyone knows of an existing bug [ACTION] poolie to file bug about MOTD information for out-of-date packages * barry looks aparrently mootbot only likes barry [16:24] ah bug 609187 exists which is funny, 'cause i hate mootbot Launchpad bug 609187 in Ubuntu Distributed Development "bzr branch lp:ubuntu/foo should warn when foo is out of date" [High,Triaged] https://launchpad.net/bugs/609187 [ACTION] poolie to file bug about MOTD information for out-of-date packages ACTION received: poolie to file bug about MOTD information for out-of-date packages whoever starts the meeting is stuck with it for the duration :) [16:25] poolie: i'll put that one on the hot list * [[https://bugs.launchpad.net/bzr/+bug/603395|bzr commit in a heavyweight checkout does not propagate new tags]] Ubuntu bug 603395 in Bazaar "bzr commit in a heavyweight checkout does not propagate new tags" [High,In progress] thanks barry fixed, or almost fixed? bug 603395 [16:26] Launchpad bug 603395 in Bazaar "bzr commit in a heavyweight checkout does not propagate new tags" [High,In progress] https://launchpad.net/bugs/603395 I think it is fixed thanks to spiv the bug is still in progress but the branch was merged apparently ah but isn't landed yet [16:27] right action item me to review it [ACTION] jam to review spiv's branch for bug 603395 ACTION received: jam to review spiv's branch for bug 603395 Launchpad bug 603395 in Bazaar "bzr commit in a heavyweight checkout does not propagate new tags" [High,In progress] https://launchpad.net/bugs/603395 * [[https://launchpad.net/bugs/653832|Import fails with "trying to import version ... again"]] Ubuntu bug 653832 in Ubuntu Distributed Development "Import fails with "trying to import version ... again"" [High,Fix released] fixed rock * [[https://launchpad.net/bugs/499684|Interface to dpkg-buildpackage inconsistent and not well documented]] Ubuntu bug 499684 in bzr-builddeb "Interface to dpkg-buildpackage inconsistent and not well documented" [High,Triaged] a.k.a. the ScottK special [16:28] spiv is away this week poolie: well I'm PP this week anyway, so take it over, etc as necessary [16:29] we'll just keep this one on the list and revisit next week * http://pad.lv/608450 and others - ways to update debian/control and versions from a recipe jam, thanks [16:30] nothing on that one k that's it for known hot bugs. i'd like to get the debcommit/bzr commit item on the radar. it's not critical, but i do view it as a wart. what do y'all think? [16:31] poolie just marked 608450 as invalid, do we take it of the list then? [16:32] barry: I don't fully understand what you need from it, but getting it specified and making sure we have the hooks, etc is certainly worthy Some other possible hot-items pristine-tar is the next most common import failure [16:33] and I have rt #43560 to have the new version backported which is in-progress, lamont said he's got the backport but needs to test it before deploying I don't think there is a bug on it. but after deploy the packages will need to be requeued i don't have a strong opinion on fixing it jam: i would like to recommend folks always use bzr commit, though debcommit does have some nice properties. lifeless (iirc, my email is unavail atm) suggested hooks to allow bzr commit to do the things debcommit does, which would be nice i just made bug 608450 wontfix because that's more accurate than invalid Launchpad bug 608450 in Launchpad itself "Can't use 'run' in recipe" [Undecided,Won't fix] https://launchpad.net/bugs/608450 [16:34] not that i don't like debcommit, but it would be better imo, to stick with bzr once you're accustomed to using it barry, i think that was a good idea poolie: right, but invalid/wontfiix sounds like it will kick it out of the hot-bugs to work on right, at the moment it won't be fixed should we reopen it? poolie: *I* have no need to reopen it :) barry: right, I did follow the discussions, and I think having it integrated well would be nice [16:35] iow you have to persuade lp devs, not specifically me I don't fully know what debcommit does, though, to say what it takes barry, I've previously needed to modify debian/changelog in a bzr maintained package where the bzr commit message should *not* match detected new entries from debian/changelog. [ACTION] barry to file bug on debcommit/bzr commit ACTION received: barry to file bug on debcommit/bzr commit persia: would -m be sufficient for you? or do you want to get a template that you can edit? i mentioned a bug in that thread to add hooks to enable it [16:36] persia: i'll subscribe you to the bug i'll file :) perhaps we should have a separate bug saying "and this hook should be used to ..." jam, -m is probably enough, but that may end up being comfusing when compared to debcommit -m I think there are other rough points where when giving a template if you *don't* modify it, then we assume you don't want to commit (or at least prompt you) which people didn't like any other comments about hot bugs before we move on? [16:37] barry: I don't know the specific workflow, but is a bzr commit *always* matching the changelog? Or would you do a couple intermediate cleanups before the branch is final? any more nominations of things people really want fixed? barry: action item to follow up on pristine-tar stuff *** ghostcube (~ghostcube@unaffiliated/ghostcube) has quit: Quit: Verlassend jam: i personally do many commits, then a dch -i as almost the last thing, then one last bzr commit. it's that last that debcommit is currently better at because it also --fixes to link the branch to the bug as well as using d/changelog entry [16:38] jam: but i also think that if d/changelog doesn't change, then it'll just be a 'normal' commit barry: right, so how does that interact with 'bzr commit' automagic? Just that it only kicks in if there is a *new* changelog entry ? [16:39] right [ACTION] jam to follow up on pristine-tar stuff :) ACTION received: jam to follow up on pristine-tar stuff :) jam: yes, i think so. would also be nice to warn if LP: #12345 wasn't included or mis-formatted jam: there's a question about what to do if you change a changelog entry (i.e. don't add a new one but edit an existing one). for now, i'd say whatever is easiest is fine (it's a bit of an uncommon - for me - occurrence) [16:40] editing changelog is the special case I mentioned above. anyway, we can carry that on in the bug comments or in the ml barry: right Another common case where I use debcommit is with -R magic, which would be nice to integrate if trying to emulate the tool. [16:41] <1235076782.10502.134.camel@flash> is interesting Re: debcommit * barry 's email is offline atm :( cool. if there are no other hot bug nominations, let's move on to aob k [TOPIC] aob New Topic: aob i have a couple [16:42] the floor is poolie's * bug queue management we agreed to make a small process change last week, as is <1236587080.23732.44.camel@flash> sidebar: what is AOB? which is that the shortlist of bugs for my team will now be (any other business?) [16:43] as opposed to previously opening a task against udd this is just fyi if any of you feel a bug is important to udd, please make that clear in comment text or set the importance as you see fit we can always change it or discuss it later [16:44] ERC> /msg jam any other business also, i will try to set up an instance of jkakar's kanban software to give a view of this questions/comments? poolie: how do we handle it when someone on the team starts it [16:45] poolie: just to clarify: we still have (i think) some uncertainty whether to file bugs against udd or bzr-builddeb. do you have some clear guidelines for folks on that? do we reassign it? or just mark it in-progress? reassign to that person and inprogress i'm hoping that lp:kanban will give us an aggregated view, or can be tweaked to do so barry, i think the rule now would be, file against whatever code base needs the fix [16:46] if in doubt, udd poolie: thanks barry: right, and then when it is something that the canonical team is going to focus on, it gets assigned to that team [16:47] but we monitor udd/bzr/bzr-builddeb etc at least, I know *I* get emails for bugs in both :) if I happen to ignore them... next item? * bzr team theme we're going to make it possible to stop doing source package uploads by uds [16:48] the main things under this seem to be, 1- reliable package imports, so people have a place to start from 2- build from branch into the main archive this doesn't mean we'll turn off dput uploads, but we want to make it possible for people to do that if they want [16:49] are you targeting the current devel distro only? and i hope that around that time frame, some people will be finding it worthwhile to stop doing source package uploads yes ok just checking; I'm still keen to see -proposed queues turned into merge requests :-) [16:50] very cool for past releases, i think lp should always keep supporting the toolchain used when they were originally released i think this is a good goal because it will help us distinguish the 'must be done' features [16:51] poolie: do you foresee requiring udd-only for 12.04 and onward? and, remove some complexity or inconsistency from supporting multiple mechanisms barry, well, it's not for me to set that kind of requirement barry: it is under discussion we'll do our best to get things to a state where the TB can decide that they will do udd-only but as poolie says, that is something outside the bzr group to control * barry nods [16:52] I think it also affects stuff like the linaro build process there's a middle step where lp could get an acl on source packages in particular releases to say they should only come from branches to let them be used as canaries for the process that's a good idea poolie: well, bear in mind that ~4 months after UDS we enter archive freeze, and then LP should /not/ automatically build from branch... [16:53] or at least, not from any branch ubuntu-dev can commit to directly slangasek, right, only, what ~archive-admins can approve things? I'm not sure it will even be automatic there is a question here about whether committing should automatically build [16:54] or whether there is a separate 'do it' step poolie: in practice archive admins push the button, though this is a (minor) LP bug it should be the release team slangasek: so how is the dput uploads processed. Just restricted to specific users after a given point? slangasek: so the build from branch implementation will initially be a front-end to the uploader and for previous releases, the SRU team it might be nice to do the build as an intermediate step, but have different criteria for upload-to-archive jam: dumped into an 'unapproved' queue within soyu^W launchpad slangasek: so all the normal policy knobs, freezing etc will operate unaltered. lifeless: fair enough interesting idea [16:55] ah, what else we will probably still publish source packages we can iterate for deeper glue etc once regular uploads *cannot happen* - e.g. in 7 years :P right https://dev.launchpad.net/LEP/BuildFromBranchIntoMain [16:56] an update of a very old spec but now in reach! Given 7 years, it oughtn't be that hard to implement a `dput` that does the bzr stuff. so, this is what we're planning to do [16:57] point of order: we're coming up on an hour, so we should wrap up. anything else we need to discuss here today? if not, then... [16:58] #endmeeting }}}