20110126

DistributedDevelopment steering meeting to be held in #ubuntu-meeting on 2011-01-26 at 2100 UTC.

Agenda

Summary

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 Smile :)

Log

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

DistributedDevelopment/20110126 (last edited 2011-01-27 20:47:10 by mail)