20101006

UDD stakeholders meeting 2010-10-06 2100 UTC

Meeting to be conducted on #ubuntu-meeting @ freenode. Duration: 1 hour max.

Chair: Barry Warsaw

Agenda

  • Action items

    • poolie to confirm charline to do user studies at UDS-N (ongoing)

    • poolie to organize a foyer poster (ongoing)

    • barry to register udd sessions at uds (done)

    • barry to register general bzr/lp session in "app devs" theme (done)

    • barry to make ajmitch be udd stakeholder representing REVU (done)

    • poolie to get a better graph of package import failures (done)

    • barry to start some sphinx docs to be well-integrated w/ wiki.u.c (ongoing)

    • barry to talk to dholbach about making sure udd is well advertised in pkg guide (ongoing)

    • barry/poolie to write up job announcements; barry posts to python job board, james_w/slangasek posts to debian-jobs, ubuntu-devel (ongoing)

    • james_w to merge bzr-debuntu to bzr-builddeb (-> barry has merge proposal pending)

  • MVO feedback
    • Fast and easy for simple case (version bump only)
    • upstream tarball is all you need (no source branch; debian/ only)

    • dch -i + build and that's it

    • people who are only packagers don't need full source
  • AOB

Top bug

Summary

Action items

  • all: sit down w/mvo @ uds and get more details about his use cases

  • barry to work on watch file support

Meeting log

<barry> #startmeeting
<MootBot> Meeting started at 16:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK],
          [VOTE]
* ajmitch will try & be around
<barry> ajmitch: cool
<barry> james_w: hi
<barry> y'know i don't know if rockstar plans to be around for these.  thunper
        was last time  [17:01]
<barry> slangasek: hi
* slangasek waves
<poolie> thumper is on holiday this week
<poolie> agenda?
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry> https://wiki.ubuntu.com/DistributedDevelopment/20100106
<barry> [LINK] https://wiki.ubuntu.com/DistributedDevelopment/20100106
<MootBot> LINK received:
          https://wiki.ubuntu.com/DistributedDevelopment/20100106
<barry> i figured we'd review action items first  [17:02]
<james_w> howdy
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<james_w> always a good idea
<barry>    * '''poolie to confirm charline to do user studies at UDS-N'''
<barry> 
<flacoste> hi folks
<poolie> hi flacoste
<barry> flacoste: hi!
<poolie> charline hasn't replied to my pings; i asked matthew to contact her
         but i still haven't heard back  [17:03]
<poolie> i'll escalate to someone else
<poolie> maybe she's been away
<flacoste> no she was there last week
<flacoste> have you sent her an email?
<poolie> yes, a couple
<poolie> mail pings, i meant, not irc
<flacoste> she's kind on the opposite end of the world to you
<flacoste> ok
<flacoste> i'll try to grab her tomorrow  [17:04]
<barry> flacoste, poolie thanks
<poolie> thanks, please just ask her to answer them or to call me
<barry>    * '''poolie to organize a foyer poster'''
<poolie> related note, the survey is now ready to launch
<poolie> i'll ask mrevell to turn it into production
<barry> poolie: very cool.  it will be nice to get some data before uds
<poolie> not done yet; still a good idea; will do it before we go  [17:05]
<poolie> flacoste: can you help me get a small bit of attention from design
         people?
<barry> np.  we can keep both on the list for next time
<barry> * '''barry to register udd sessions at uds''' (after finding the right
        theme/track)  [17:06]
<barry>    * '''barry to register general bzr/lp session in "app devs"
        theme'''
<flacoste> poolie: for charline or something else?
<flacoste> hmm, the foyer poster
<flacoste> forget it
<flacoste> you are on your own there :-)  [17:07]
<poolie> ok :)
<flacoste> no way they can do something about this before UDS
<barry> :D
<poolie> probably would be too long, yeah
<poolie> it'll be nerdy but it'll be there
<barry> poster board + fat sharpie :)
<barry> i coordinated both with robbiew who actually scheduled the blueprints
        for all three session we talked about last time
<barry> so i think we're good to go for uds sessions
<james_w> thanks  [17:08]
<barry>    * '''barry to make ajmitch be udd stakeholder representing REVU'''
<barry> 
<barry> done
<barry>    * '''poolie to get a better graph of package import failures'''
<ajmitch> not much to do with that one :)
<barry> ajmitch: no, but thanks for coming by today!
<poolie> i see james did some of that for me
<barry> saw that too, thanks james_w 
<james_w> jml fixed the internal graph
<james_w> and I produced some external ones
<james_w> already showing some interesting results :-)
<poolie> hottest100 is not yet graphed; i tried that but it got too many
         errors connecting to lp
<james_w> http://package-import.ubuntu.com/status/index.html
<MootBot> LINK received:  http://package-import.ubuntu.com/status/index.html
<james_w> see at the bottom for the graphs  [17:10]
<barry> james_w: what's the spike?
<poolie> lp outage, i think :)
<james_w> LP refusing to talk to us for a while
<poolie> to judge from the errors i saw yesterday
<barry> ;)  [17:11]
<james_w> I'd love it if someone could code a higher level of backoff too
<poolie> i think adding more graphs is not a priority atm
<poolie> i'd rather force that existing graph down to 0 and then worry about
         whether there are things its not measuring
<poolie> any objections?
<barry> agreed.  i think we can mark this one "done" for now  [17:12]
<james_w> poolie, which graph in particular, or all of the ones we have now?
<poolie> specifically "number of packages that failed to import"
<poolie> it would be a bit nice to graph "hottest100" and i may yet do it, but
         i don't know if i'll do it before UDD  [17:14]
<poolie> s//UDS-N
<james_w> ok
<barry>    * '''barry to start some sphinx docs to be well-integrated w/
        wiki.u.c'''
<barry> not done. will carry over
<barry>    * '''barry to talk to dholbach about making sure udd is well
        advertised in pkg guide'''  [17:15]
<barry> not done.  i'll probably wait and chat with daniel f2f @ uds
<barry>    * '''barry/poolie to write up job announcements; barry posts to
        python job board, james_w/slangasek posts to debian-jobs,
        ubuntu-devel'''
<james_w> not done
<poolie> perhaps we should have a small udd docs session at uds? maybe just
         informally
<barry> i have a template almost ready for review for the python jobs board.
        i'll send around a pastebin when i think it's ready
<poolie> ok  [17:16]
<slangasek> I haven't been given anything to post, so haven't posted :)
<poolie> i'm planning to do some interviews before UDS
<barry> poolie: good idea
<poolie> http://webapps.ubuntu.com/employment/canonical_BSE
<MootBot> LINK received:  http://webapps.ubuntu.com/employment/canonical_BSE
<barry> the python jobs board has a very specific template, which is what i'm
        fitting the above into
<poolie> thanks
<poolie> so doing it this week or at least next week would be really good
                                                                        [17:17]
<poolie> please also personally invite anyone you know with relevant skills
         that you'd like to work with
<barry> poolie: i'll have something to review by tonight or tomorrow.
        debian-jobs and ubuntu-devel might need a different format
<poolie> related question, would anyone like to interview shortlisted
         candidates?  [17:18]
<poolie> thanks very much barry, i really appreciate circulating it to there
<slangasek> I don't think debian-jobs has any particular formatting
            requirements, fwiw
<barry> poolie: i'm happy to, though i probably can't grill them too much on
        bzr internals
<james_w> poolie, I would
<james_w> though maybe would should avoid too many interviews :-)  [17:19]
<poolie> i think about 2-3 would be ok
<barry> james_w: maybe just make them fix a bug using udd as the first
        gauntlet
<poolie> so me plus one of you plus statik
<poolie> and write a short report on it :)  [17:20]
<james_w> heh
<barry> :)
<barry> poolie: sounds good
<barry> btw, i did post it on my fb wall for all the good it did ;)
<barry> anyway...  [17:21]
<barry>    * '''james_w to merge bzr-debuntu to bzr-builddeb'''
<barry> well, not done, but sort of morphed
<barry> bug 609186 is tracking this
<ubottu> Launchpad bug 609186 in Ubuntu Distributed Development "Really easy
         branching of Ubuntu packages" [High,Triaged]
         https://launchpad.net/bugs/609186
<barry> we're going to get the uncontroversial ones into bzr 2.3 and then
        worry about the rest
<barry>
        https://code.edge.launchpad.net/~barry/bzr/609186-shortcuts/+merge/37787
                                                                        [17:22]
<barry> that's it for the action items.  does anyone have comments to add on
        any of the above before we move on?  [17:23]
<james_w> on the poster idea from last time
<james_w> I have been thinking for a while that one of the issues people have
          with using bzr-builddeb is getting the mental model of what is going
          on right
<james_w> and I think I have some pictures that will help with this  [17:24]
<james_w> I started putting together an ebook that I showed barry, and he
          suggested perhaps getting it printed to hand out at UDS
<james_w> I thought that this was a great idea, but there are a couple of
          problems with it
<james_w> 1) that ebook is now on my barely-alive harddrive, so it may be lost
<james_w> 2) printing in that form would be very expensive  [17:25]
<barry> :(
<james_w> so, would something simpler be good to have
<james_w> say a 2-fold booklet or similar?
<poolie> perhaps
<james_w> we can still distribute a full thing electronically of course
<barry> james_w: definitely.  think we can get something useful on a single
        8.5x11 (front & back)?  we could print that at any kinkos to pass out
                                                                        [17:26]
<poolie> may also be more likely to be read in the short-attention-span
         environment of uds
<poolie> perhaps we could also put that content on the poster, along with a
         description of what we're doing and who to talk to
<james_w> barry, I haven't figured out how to present the information in that
          format yet, but I don't think it would be impossible to get
          something  [17:27]
<barry> be sure to include the url to the top udd wiki page
<james_w> I'm not sure a poster is the right format for what I was working on,
          as I'm not sure many people would digest it from a poster
<james_w> but if we can get something that works as a poster that would be
          great
<james_w> I wish I had the start of the content to show you all now, I'll try
          and rescue it and send it around  [17:28]
<barry> james_w: i was thinking about something we could (at least) hand out
        at the educating-users session
<poolie> james_w: next time, duplicity backups to s3 :)
<poolie> from cron :)
<james_w> :-)
<barry> james_w: i forget - did you email it to me?
<james_w> barry, no, I don't think so  [17:29]
<james_w> and I don't think I sent you the source either?
<barry> ah.  oh well
<barry> no, pretty sure you didn't
<james_w> ah, as it was IRC it is probably on the web somewhere
<barry> riigght  [17:30]
<james_w> yes http://people.canonical.com/~jamesw/guide.pdf
<barry> so for action item wrap up: poolie will continue with poster and james
        will send around his ebook, and (?) get it into a format for passing
        out at uds  [17:31]
<poolie> good  [17:32]
<barry> cool, moving on...
<poolie> and the rest of you will circulate/recommend the job ad
<barry> poolie: +1
<barry> [TOPIC] MVO feedback
<MootBot> New Topic:  MVO feedback
<barry> so, i had a brief mumble chat w/mvo today and we talked about udd a
        bit.  he had some interesting feedback that i'd like to share.  i'll
        paste the points here and then we can discuss...  [17:33]
<barry>    * Fast and easy for simple case (version bump only)
<barry>    * upstream tarball is all you need (no source branch; debian/ only)
<barry>    * `dch -i` + build and that's it
<barry>    * people who are only packagers don't need full source
<barry> (done)
<barry> so mvo was most concerned with packages who aren't developing the
        code, or the many people who just need to do a version bump.  [17:34]
<james_w> version bump with no changes?
<barry> his concern was that it needs to be at least as fast to do that with
        udd as it is now
<barry> james_w: yep
<poolie> that's a good test
<james_w> build-from-branch!
<barry> or, just grab debian version and bump
<james_w> if we have build-from-branch then we can make it super-cheap
<slangasek> yes, it does need to be fast - I think that ties in with my
            concerns about having easy-to-configure mirrors of bzr branches
                                                                        [17:35]
<james_w> then you don't even need to get the branch even, just commit
          remotely and request a build
<poolie> it'd be good to make sure they're documented, then see how simple the
         documentation looks and how long it takes to execute
<barry> james_w: can you elaborate?  mvo's main concern was downloading the
        source branch when a lot of folks (currently) only use debian/
<james_w> or we make it a non-issue by implementing rebuild support in soyuz
          :-)
* barry looks to flacoste   [17:36]
<james_w> barry, you don't /need/ the data locally to do that, Launchpad is
          the source and target, and so if the pieces are there we can just
          ask Launchpad to do the operation
<james_w> that will be faster than the current approach of apt-get source +
          dput  [17:37]
<barry> james_w: so no need to branch locally to dch -i?
<flacoste> i don't understand how rebuild helps here?
<slangasek> barry: I do disagree strongly with mvo's conclusion that packagers
            only need debian/; that guarantees that if that package ever needs
            patching to the upstream sources, you end up with a two-step merge
            (VCS merge, followed by a quilt merge).  debian/-only VCS branches
            drive me crazy!  [17:38]
<james_w> barry, we can remove that need, as bazaar's vcs means that you can
          commit remotely if you want
<james_w> barry, so we can simulate dch -i + commit remotely, and then request
          a build
<james_w> or, as I said, rebuild support makes it all a non-issue really, as
          you just ask soyuz to rebuild without a source change, so you don't
          need apt-get source, dput or bzr  [17:39]
<slangasek> james_w: "without a source change"?  [17:40]
<james_w> binNMU
<barry> i think i see.  this is definitely a workflow not covered in the
        current wiki docs
<flacoste> isn't a version upgrade a source code change?
<slangasek> my understanding is that "version bump only" refers to "upstream
            version bump only"... where you don't care about the old upstream
            source because you're forklift replacing it for the upload you're
            preparing
<james_w> <james_w> version bump with no changes?  [17:41]
<james_w> <barry> james_w: yep
<poolie> so the top level issue is, they want to just pull in a new upstream
         version, and that should be as fast and simple as possible? or no?
<james_w> I read that as "no-change rebuild", not "new upstream version"
<flacoste> right, that's the confusion
<flacoste> barry which one is it?
<barry> well, now i'm not 100% sure what mvo was getting at.  he kind of
        mentioned both scenarios  [17:42]
<flacoste> lol
<james_w> because "dch -i + build" isn't all you need for a new upstream
          version
<slangasek> james_w: it is for /many/ packages
<james_w> no, because dch -i gives you the same upstream version number as you
          had before :-)
<slangasek> oh, I interpreted that as pseudocode, sorry :)  [17:43]
<poolie> why would they want a no-change rebuild? to rebuild on new
         dependencies?
<james_w> poolie, yes
<flacoste> for the rebuild use-case, i agree that the easiest thing is to
           implement it in LP directly
<james_w> there are many reasons why it can happen, but there are several
          hundred occurences per-cycle
<barry> i'm sure mvo mentioned the "new upstream version" scenario  [17:44]
<james_w> "new upstream version" is harder, I agree, and we should ensure that
          it is optimised too
<flacoste> especially, if he was referring to the debian/ branch packaging
<poolie> that seems fairly obviously like the first thing someone might want
         to do in udd
<barry> yes, he specifically mentioned debian/-only branches  [17:45]
<james_w> where there are no patches, I would argue that we are /almost/ as
          efficient as the old way, discounting the overhead of bzr
          branch/push
<james_w> we just need someone to implement watch-file support in
          merge-upstream
<barry> james_w: that's something i'd like to attempt
<james_w> barry, great, I'm happy to help  [17:46]
<barry> thanks!
<poolie> so this should live in
         https://wiki.ubuntu.com/DistributedDevelopment/Documentation/NewUpstreamVersion
<james_w> where there are patches, then I think both methods are terrible, but
          I would think that the old method is currently better there
<poolie> and then you would do
         https://wiki.ubuntu.com/DistributedDevelopment/Documentation/UploadingAPackage
         ?
<james_w> because it's less likely to get you really stuck  [17:47]
<james_w> poolie, yes
<barry> poolie: i'm not sure i have a good enough sense of what to add there
        for this scenario
<poolie> ok, so what are we going to do on this topic, beyond this meeting?
                                                                        [17:49]
<poolie> just reaffirm that that story is important?
<poolie> perhaps james and/or myself should go over those pages with mvo and
         see where the problems are?  [17:50]
<barry> we should make sure mvo comes to the user feedback session at uds so
        we can mine this topic more
<james_w> barry, +1
<barry> poolie: yes, that would be great, but i think f2f @ uds will be the
        most productive
<james_w> to me this reaffirms the importance of having a good patch handling
          story, and speed of bzr+LP  [17:51]
<barry> james_w: big +1 to both of those
<poolie> right
<barry> so i'll contact mvo and invite him to the session.  i'm sure he'll be
        happy to join us
<barry> anything else on this topic?  [17:52]
<poolie> perhaps we can have footnote-like links to bugs from the udd doc
         pages, pointing to ways they could be better
<poolie> i think that's it for me
<barry> good idea.  i have a place for those i think  [17:53]
<barry> [TOPIC] AOB  [17:54]
<MootBot> New Topic:  AOB
<barry> anybody have anything not on the agenda?
<barry> going once...
<james_w> I think we are missing the one thing that we want to fix first
<poolie> that'd be a good recurring item to add  [17:55]
<poolie> any nominations for most-wanted bug?
<barry> agreed.  i'll add that to the ongoing agenda
<barry> watch file support?  [17:56]
<james_w> +1, it's fairly small, easy and well-contained, and will have a big
          usability win
<barry> (though i don't see a bug open on that yet)
<barry> cool.  i'll open a bug and see if i can put together a branch
<james_w> then we can move on to something larger next meeting :-)
<barry> [ACTION] barry to open bug for watch file support  [17:57]
<MootBot> ACTION received:  barry to open bug for watch file support
<james_w> bug 295274
<ubottu> Launchpad bug 295274 in bzr-builddeb "merge-upstream shouldn't
         require --version when debian/watch is present" [Wishlist,Triaged]
         https://launchpad.net/bugs/295274
<barry> ah, it's on bzr-builddeb not udd
<james_w> feel free to add a udd task  [17:58]
<barry> +1
<barry> so, if there's nothing else.  meet again in 2 weeks?  (that'll be
        right before uds so we can do last minute planning)
<poolie> wfm
<slangasek> sure
<barry> #endmeeting  [18:00]
<MootBot> Meeting finished at 17:00.
<barry> thanks everyone.  see you in 2 weeks

DistributedDevelopment/20101006 (last edited 2010-10-08 15:41:15 by mail)