UDD stakeholders meeting 2010-11-03 2100 UTC
Meeting conducted on #ubuntu-meeting @freenode. Duration: 1 hour max.
Chair: Barry Warsaw
Agenda
- Action items
- 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 (done)
- poolie to start list thread to find problems which can be carried on at UDS (ongoing)
- UDS post-mortem
- Top bugs:
- bzr branches are too expensive to use for casual sponsoring, compared with downloading packages from my local mirror (slangasek)
(watch file support) - james_w and barry to sprint on that at uds-n
bzr commit in a heavyweight checkout does not propagate new tags
Interface to dpkg-buildpackage inconsistent and not well documented
- changelog merge problem (probably caused by dpkg-mergechangelogs). need more investigation by barry
- USA leaves DST
- Pushing changes to Debian (python-cheetah use case)
- AOB
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]