20101103

UDD stakeholders meeting 2010-11-03 2100 UTC

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

Chair: Barry Warsaw

Agenda

Summary

  • UDS was good. Though we had some scheduling snafus the planning session went well. More people seem to be trying UDD.

  • submittodebian is a good way to get changes to them; a bzr submittodebian might be nice

New action items

  • barry to contact poolie about getting his UDS session notes into the blueprint

Meeting log

<barry> #startmeeting
<MootBot> Meeting started at 16:02. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK],
          [VOTE]
* james_w apologies as he will have to leave before the hour mark
<thumper> ah...
<thumper> is this the time we had it last time?
<ajmitch> it is
<barry> [LINK] https://wiki.ubuntu.com/DistributedDevelopment/20101103
<MootBot> LINK received:
          https://wiki.ubuntu.com/DistributedDevelopment/20101103
<james_w> I'm pretty sure
<flacoste> me
<barry> utc-wise, yes :)
<barry> flacoste: hi!
<flacoste> barry: poolie is
* ajmitch is here, though I'd forgotten about it  [17:03]
<barry> [TOPIC] action items  [17:04]
<MootBot> New Topic:  action items
<barry>    * barry to start some sphinx docs to be well-integrated w/ wiki.u.c
<barry> 
<barry> not done
<barry>    * barry to talk to dholbach about making sure udd is well
        advertised in pkg guide
<barry> 
<barry> i did talk a little to dholbach about this at one of the many uds
        sessions.  james_w was probably there too (as was poolie).  he wants
        to promote/document udd we just have to figure out how to do this
<barry> so i think this item is "done" though there's probably a future action
        item about actually helping dholbach with the integration
<barry> james_w: your thoughts?
<james_w> indeed
<james_w> barry, I agree with barry
<barry> cool
<barry>    * poolie to start list thread to find problems which can be carried
        on at UDS
<barry> 
<barry> i think this is not done
<persia> Just as a note on historical practices, it might be better to take an
         action to write the docs in consultation with dholbach, rather than
         helping him with them.
<barry> persia: i figure it will us writing the bulk of the docs and daniel
        helping to integrate them  [17:07]
<barry> well, poolie's action item is probably moot now, but i'll leave it on
        the agenda until he says otherwise
<barry> [TOPIC]  * UDS post-mortem  [17:08]
<barry> 
<MootBot> New Topic:   * UDS post-mortem
<barry> just a quick apology for letting two of our sessions get lost in the
        shuffle.  after talking with robbiew about rescheduling due to
        poolie's travel adventures, i lost track of the sessions and realized
        too late that the education and user feedback sessions didn't get
        rescheduled :(  i take the blame for that  [17:09]
<barry> we did have a good planning session though i thought
<barry> we need to get poolie's notes into the blueprint though because gobby
        was down at the time
<barry> i'll take an action item to check with him on that  [17:10]
<barry> [ACTION] barry to ask poolie to put his session notes in the blueprint
<MootBot> ACTION received:  barry to ask poolie to put his session notes in
          the blueprint
<barry> does anybody else have any feedback on uds?
<james_w> I found it very useful  [17:11]
<james_w> there was better feedback than previous UDS, so I think that it's
          something people are thinking about much more
<james_w> unfortunately though there are still plenty of hurdles
<barry> true.  on the positive side, i've heard we may have a really stellar
        candidate for the job opening  [17:12]
<james_w> excellent  [17:13]
<barry> i also think the planning session was really excellent.  great
        feedback from folks like slangasek
<slangasek> sorry I couldn't attend the whole session, but glad my feedback
            was helpful  [17:14]
<barry> any other thoughts on uds?
<barry> flacoste: we missed you and illuminati :)
<barry> [TOPIC] top bugs  [17:15]
<MootBot> New Topic:  top bugs
<james_w> the session identified some focii for the various teams, but didn't
          really get them all assigned, do we need to work on that?
<james_w> whoops, sorry
<jelmer> 'evening  [17:16]
<barry> jelmer: hi!
<james_w> hi jelmer
<flacoste> barry: i should be at the next one :-)
<barry> james_w: we do, but i think poolie's got the list so i think we have
        to wait for him
<barry> flacoste: \o/
<barry> here's the pre-uds list.  i guess next time we can consolidate them
        with the list from the session:  [17:17]
<barry> * bzr branches are too expensive to use for casual sponsoring,
        compared with downloading packages from my local mirror (slangasek)
<barry>    * [[https://launchpad.net/bugs/295274|(watch file support)]] -
        james_w and barry to sprint on that at uds-n
<barry>    * [[https://launchpad.net/bugs/653307|Import fails with missing
        referenced chk root keys]]
<barry>    * [[https://bugs.edge.launchpad.net/bzr/+bug/603395|bzr commit in a
        heavyweight checkout does not propagate new tags]]
<barry>    * changelog merge problem (probably caused by
        dpkg-mergechangelogs).  need more investigation by barry
<ubottu> Launchpad bug 295274 in bzr-builddeb "merge-upstream shouldn't
         require --version when debian/watch is present" [High,Triaged]
<ubottu> Launchpad bug 653307 in Ubuntu Distributed Development "Import fails
         with missing referenced chk root keys" [Critical,In progress]
<ubottu> Launchpad bug 603395 in Bazaar "bzr commit in a heavyweight checkout
         does not propagate new tags" [High,In progress]
<barry> james_w: and i looked at the watch file bug and i made notes.
        hopefully i can understand them now that uds is over and make some
        progress on the bug  [17:18]
<slangasek> james_w: any status change on bug #653832? 696 failed imports :/
<ubottu> Launchpad bug 653832 in Ubuntu Distributed Development "Import fails
         with "trying to import version ... again"" [High,Triaged]
         https://launchpad.net/bugs/653832
<persia> For the watchfile thing: probably best to check for debian/rules
         get-orig-source: before trusting it
<james_w> slangasek, yes, at least in the gourmet case, did it ever get
          retried?  [17:19]
<slangasek> james_w: it was retried before you commented that the bug was
            "harder than you thought"
<barry> persia: right
<slangasek> not retried after that, is that the next step?
<james_w> slangasek, ok, I'll retry now
<slangasek> ok, thanks
<james_w> slangasek, it may well stamp on your revisions in that branch though
          :-(
<slangasek> fwiw, gourmet is far from the only interesting package in that
            list  [17:20]
<james_w> indeed
<slangasek> ah, well, I guess I'll cope :)
<barry> any other feedback on top bugs?
<james_w> spiv seemed to have a good handle on the corruption in bug 653307,
          but not exactly how it came about  [17:22]
<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> excellent
<james_w> he said that the easiest fix might be to re-import all of those
          branches  [17:23]
<ScottK> barry: I'd like to see someone tackle Bug #499684 sooner rather than
         later as the more users there are, the harder it will be to change to
         something better.  [17:24]
<ubottu> Launchpad bug 499684 in bzr-builddeb "Interface to dpkg-buildpackage
         inconsistent and not well documented" [High,Triaged]
         https://launchpad.net/bugs/499684
<barry> ScottK: yeah, we talked about that at uds.  the -- is really ugly :/
                                                                        [17:25]
<ScottK> Yep
<barry> ScottK: i'll put that on the top bugs list  [17:26]
<jelmer> james_w: do you know whether it's easily possible to support not
         explicitly declared options in a bzr subcommand?
<james_w> jelmer, I do not. It's probably not that much work to add
<james_w> I got bored of trying to add them explicitly, mainly because trying
          to explain the meaning of things like -su vs. -sa is really hard
<barry> james_w: where is -su documented?  i don't see it in dpkg-genchanges
                                                                        [17:29]
<barry> (manpage)
<james_w> sorry, I mean -si
* barry nods
<barry> moving on...  [17:30]
<barry> [TOPIC]  * USA leaves DST
<MootBot> New Topic:   * USA leaves DST
<james_w> plus I think they are interface warts, so I'm not pleased about
          inheriting them
<barry> it would be best if users didn't need to worry about them at all, but
        i don't know if that's possible  [17:31]
<james_w> indeed
<barry> i mention the dst thing because the meeting will be an hour earlier
        local time for me.  it's still fine, but i wanted to give folks a
        chance to chime in if the current 2100 utc meeting time has become
        inconvenient for them
<james_w> it still works for me
<slangasek> fine for me  [17:32]
<james_w> and this time is better for our antipodean friends
<barry> cool.  no change necessary then
<barry> [TOPIC]  * Pushing changes to Debian (python-cheetah use case)  [17:33]
<MootBot> New Topic:   * Pushing changes to Debian (python-cheetah use case)
<barry> i bring this up because it's something i'm thinking about now and it's
        a use case we should address
<barry> but we don't need to solve it here
<barry> basically: i fixed python-cheetah in the ubuntu source branch but we
        really should get the changes into debian.  i don't know that udd has
        a good story for that yet  [17:34]
<james_w> something like submittodebian?
<barry> james_w: something like that, yeah.  there is bug reporting via email
        involved
<barry> reportbug on ubuntu does not make debian developers happy  [17:35]
<james_w> shouldn't be too hard to generate the diff
<james_w> emailing is perhaps a trickier fish, though perhaps we just modify
          and rely on submittodebian
<slangasek> you mean we can't just push to lp:debian/$package and have Debian
            build from branch? <g,d,r>
<barry> slangasek: :-D  [17:36]
<barry> james_w: oh.  submittodebian(1)  \o/
<james_w> heh
<barry> james_w: looks very interesting, and i'll give that a try with
        python-cheetah  [17:37]
<jelmer> a "bzr submittodebian" that takes into account common ancestors etc
         might be nice
<persia> Might be nice to have three stories: 1) pushing a change to the BTS,
         2) committing a change to Vcs-*, 3) push to lp:debian/foo and upload
         package
<barry> would pushing to lp:debian/foo get clobbered when the change lands in
        debian and gets imported back into launchpad?  [17:38]
<persia> Wouldn't that have the same handling as when folk push to
         lp:ubuntu/foo and then upload now?
<slangasek> jelmer: I did hack submittodebian a while back to notice when it
            was on a bzr branch and attempt to DTRT
<slangasek> could stand to be improved some, yes  [17:39]
<jelmer> slangasek: ah, that's probably even nicer than adding yet another
         (sub)command.
<barry> otoh having it as a subcommand makes it more discoverable perhaps
                                                                        [17:40]
<jelmer> persia: supporting push to lp:debian/foo would require us to have a
         Debian build environment on Launchpad
<jelmer> persia: support push to lp:debian/foo and build, that is  [17:41]
<james_w> well, in some sense push as well right now
<james_w> ACL are tied to upload rights  [17:42]
<james_w> unfortunately I have to leave now, sorry  [17:43]
<james_w> thanks everyone
<jelmer> Thanks James
* slangasek waves
<barry> that was very helpful, thanks.  i'll add my experience to the wiki and
        file a bug for a new feature 
<barry> thanks james_w
<barry> we're basically done anyway  [17:44]
<barry> [TOPIC] AOB
<MootBot> New Topic:  AOB
<barry> do you have anything else not on the agenda?
<persia> jelmer, I meant the build to be done on the local machine where the
         developer has the necessary key to upload to Debian: I doubt any DDs
         would trust those to LP.
<jelmer> persia: Ah, ok
<jelmer> persia: Yeah, I wouldn't trust them to /any/ remote machine.
<persia> For some definition of remote.  I know several who don't trust them
         to laptops, and use debsign -r against trusted machines that may not
         be local (but are housed in a trusted environment)  [17:46]
<persia> (or debrsign, depending)  [17:47]
<barry> anything else for today?
<barry> #endmeeting  [17:48]

DistributedDevelopment/20101103 (last edited 2010-11-05 16:18:50 by mail)