20110518

DistributedDevelopment steering meeting held in #ubuntu-meeting on 2011-05-18 at 1100 UTC. Note the time change.

Chair: barry

Apologies

Agenda

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

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

DistributedDevelopment/20110518 (last edited 2011-05-18 12:19:40 by mail)