20101020
UDD stakeholders meeting 2010-10-20 2100 UTC
Meeting 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 (done)
poolie to organize a foyer poster (ongoing)
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 (done)
- UDS prep
Top bug: watch file support - barry
- AOB
Summary
- UDS-N actions
- sit down with scottk and watch his diff/patch method for porting clamav updates to all releases and see if UDD can help.
- face-to-face feedback from mvo
- have complete end-to-end story, including reviewing merge proposals and landing new packages from branches
- 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
- changelog merge problem (probably caused by dpkg-mergechangelogs). need more investigation by barry
New action items
- poolie to start list thread to find problems which can be carried on at UDS
Meeting log
<barry> #startmeeting
<MootBot> Meeting started at 16:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK],
[VOTE]
* slangasek waves
<barry> https://wiki.ubuntu.com/DistributedDevelopment/20101020
<barry> [LINK] https://wiki.ubuntu.com/DistributedDevelopment/20101020
<MootBot> LINK received:
https://wiki.ubuntu.com/DistributedDevelopment/20101020
<poolie> hi all [17:01]
<barry> hi slangasek, poolie, jelmer, ajmitch
<flacoste> hi
<barry> hi flacoste
<barry> james_w sends his apologies
<flacoste> barry: thumper should join
<barry> thumper: hi
<jelmer> hi
<thumper> hi
<barry> the agenda link is:
https://wiki.ubuntu.com/DistributedDevelopment/20101020
<barry> [TOPIC] action items [17:03]
<MootBot> New Topic: action items
<barry> * '''poolie to confirm charline to do user studies at UDS-N'''
(ongoing)
<barry>
<poolie> done, i think
<poolie> i see i have a new mail from her
<poolie> very slow, nm [17:04]
<poolie> let's say that's done
<barry> poolie: thanks, i'm looking forward to that!
<barry> * '''poolie to organize a foyer poster''' (ongoing)
<barry>
<poolie> not done yet, will do that today or tomorrow
<barry> cool [17:05]
<barry> * '''barry to start some sphinx docs to be well-integrated w/
wiki.u.c''' (ongoing)
<barry>
<barry> not done
<barry> but...
<barry> * '''barry to talk to dholbach about making sure udd is well
advertised in pkg guide''' (ongoing)
<barry>
<barry> will do that at uds
<barry> * '''barry/poolie to write up job announcements; barry posts to
python job board, james_w/slangasek posts to debian-jobs,
ubuntu-devel''' (ongoing) [17:06]
<barry>
<poolie> i know you've sent it to python because we got lots of applicants
<barry> python jobs board post done. poolie tells me we have some interesting
candidates already
<poolie> i haven't seen any from debian so i suspect that wasn't done
<poolie> however we probably have a selection, so no more advertisement is
needed atm
<barry> nice
<poolie> incidentally, i'm told that we'll soon have better recruiting
management software [17:07]
<poolie> which should be nice for all involved
<barry> indeed :)
<poolie> (not hraspace :)
<barry> i think we can mark this one done for now though, right?
<poolie> yep
<barry> thanks everyone
<barry> [TOPIC] uds prep
<MootBot> New Topic: uds prep
<barry> i believe we have 3 sessions scheduled, so it probably makes sense to
prep for them. i plan on at least looking at that over the next two
days [17:08]
<slangasek> poolie: do you prefer that I not post it to debian-jobs then,
given the tardiness?
<poolie> slangasek: yes, better not too [17:09]
<slangasek> ok
<poolie> feel free to post other job ads though :)
<barry> probably the most work will be for the user session. i'll have to
ping james_w about that tomorrow so we're on the same page.
<barry> does anybody have any thoughts about prepping for the sessions?
* ScottK reminds barry he's promised to sit down with me and watch my
diff/patch method for porting clamav updates to all releases and see if UDD
can help. [17:11]
<barry> ScottK: right, thanks. we're also going to sit down with mvo for his
feedback
<barry> there is a "user feedback session" that this will probably be
appropriate for, and i'll add action items to the blueprint for that
[17:12]
<barry> [ACTION] barry to add ScottK and mvo feedback to uds session
<MootBot> ACTION received: barry to add ScottK and mvo feedback to uds
session
<ajmitch> you have a few usecases listed for the user feedback session?
<barry> ajmitch: i was going to work off of the udd wiki page use cases
<ScottK> Please don't distract ajmitch from fixing boost. ;-) [17:13]
<barry> one thing i'd really like to address is getting more reviews and
sponsor landings from merge proposals
<poolie> i guess all interested parties need to to subscribe to the sessions
<ajmitch> ScottK: I can sense your impatience :)
<poolie> as in, how to get more reviews?
<ScottK> Me? Impatient?
<barry> poolie: well, right now mp's seem to be a black hole. i don't think
sponsors are tuned to looking at mps yet
<poolie> :/ ok, that's a good thing to think about
<barry> and since i can't sponsor, it's unclear in my mind what *should* be
the workflow
<thumper> barry: when talking to people about this, can you try to gather
work-flow information? [17:15]
<thumper> barry: I'm keen to know how people do use MPs, and how they'd like
to use them [17:16]
<ajmitch> there are a few different workflows depending on what's being
sponsored
<slangasek> solve the "bzr branches are too expensive to use for casual
sponsoring, compared with downloading packages from y local
mirror" problem?
<barry> thumper: sure. aren't you keen on hooking that up to
build-from-branch? :)
<slangasek> +m
<poolie> so popping up one meta-level, we want
<poolie> - to help people understand how to use what is there [17:17]
<thumper> barry: I'm not sure I understand what you are suggesting
<poolie> - to make sure we have a good triaged list of what's inadequate -
either technically failing, or failing as process
<poolie> - to recruit some people willing to try our solutions to the previous
point
<poolie> heh, so as far as actions:
<poolie> - do we need more sessions?
<barry> right now, i think "no" [17:19]
<poolie> - i propose we start a list thread to find problems and then carry
that on at UDS
<poolie> - if we want to go into them in detail i suggest we continue after
the 'steering committee' bit of the meeting is over
<poolie> therefore, done?
<barry> poolie: i like your list. for me it really comes down to having a
complete, end-to-end story for devs and sponsors
<barry> poolie: thanks. would you like to kick off that thread? [17:20]
<poolie> i will
<barry> thanks!
<barry> [ACTION] poolie to start list thread to find problems which can be
carried on at UDS [17:21]
<MootBot> ACTION received: poolie to start list thread to find problems which
can be carried on at UDS
<barry> any other uds related comments?
<poolie> no [17:22]
<barry> [TOPIC] top bug [17:23]
<MootBot> New Topic: top bug
<barry> bug 295274
<ubottu> Launchpad bug 295274 in bzr-builddeb "merge-upstream shouldn't
require --version when debian/watch is present" [High,Triaged]
https://launchpad.net/bugs/295274
<poolie> nice agenda item!
<barry> james_w: and i are going to sprint on that at uds
<poolie> that would rock
<poolie> current top udd bugs for us: andrew is working on bug 655307 [17:24]
<ubottu> Launchpad bug 655307 in QBzr "using odt2txt to diff OOo documents"
[Wishlist,Confirmed] https://launchpad.net/bugs/655307
<barry> indeed, both because i think it will eliminate a pain point (one which
i witnessed first hand yesterday) and because it'll help get me
acquainted with the code
<poolie> or not
<poolie> bug 653307
<slangasek> bug 603395
<ubottu> Launchpad bug 653307 in Ubuntu Distributed Development "Import fails
with missing referenced chk root keys" [Critical,In progress]
https://launchpad.net/bugs/653307
<ubottu> Launchpad bug 603395 in Bazaar "bzr commit in a heavyweight checkout
does not propagate new tags" [Medium,Confirmed]
https://launchpad.net/bugs/603395
<poolie> heaven help us when we get to 7 or 8 digit bugs
<poolie> slangasek: that's your nomination, 603395?
<barry> we'll have to start tinyurl'ing them
<poolie> barry: you know about pad.lv, right? [17:25]
<poolie> i guess it could fold them into base64 but .. shudder
<slangasek> poolie: it's the one that breaks every UDD merge I do unless I
remember it beforehand; maybe I'm the only one running into it?
<barry> poolie: yeah, i was using the generic :)
<slangasek> rather, it breaks the branches /after/ I've done a merge
<lifeless> barry: hi
<barry> lifeless: hi
<lifeless> barry: I want you after this meeting :)
<poolie> slangasek: i'll bump it up
<ajmitch> most people probably use bzr branch instead of checkout?
<barry> slangasek: i'll add it to "top bugs". i haven't hit it because i
always branch [17:26]
<barry> lifeless: ooooohhhh :)
<slangasek> barry: am I wrong in thinking co is supposed to be cheaper than
branch? maybe I should just be larting myself [17:27]
<poolie> a heavy checkout won't be much cheaper
<poolie> its main effect is that commits synchronously update the master
branch
<poolie> a light checkout will be cheap to set up, but it has no local history
cache
* slangasek nods [17:28]
<slangasek> so maybe it's just a bad habit of mine; but it has taken its toll
on a number of the UDD branches to date
<barry> there is another problem that i always run into, but i haven't figured
it out well enough to submit a bug report on. it seems i always get
weird merges in debian/changelog
<slangasek> that's the new dpkg-mergechangelogs, I think [17:29]
<poolie> slangasek: it should be reasonably easy
<barry> slangasek: hmm, it *seems* like when i merge a branch, i don't get
conflicts, but i get some maintainer lines just getting overwritten
and other changelog sections moved way down in the file. [17:30]
<poolie> barry: i think bzr builddeb has a hook that tries a smart merge of
debian/changelog
<barry> but as i said, i need to find a good reproducible test case and
understand what's happening better. i'm usually in yak shaving mode
at that point so haven't stepped back to figure out what's going on
<poolie> it may not be as smart as it thinks
<slangasek> barry: bzr-bd calls dpkg-mergechangelogs, which is good, but
doesn't mind when it rewrites the entire history of the changelog
prior to the base revision, which is bad :)
<barry> slangasek: ;) [17:31]
<barry> poolie: gotcha
<barry> next time it happens, i'll at least get a bug reported
* ajmitch used to have the entire changelog appearing as a conflict, so it's
improved :)
<barry> any other top bugs that are buggin' ya?
<slangasek> so I think this is just a bug in bzr-bd needing to be smarter
about which changelog entries it passes to dpkg-mergechangelogs
for merging
<barry> slangasek: gotcha, thanks, that's definitely helpful [17:32]
<poolie> on our side, the speedup to lp-serve, which should cut ~2 seconds off
ssh connection time, is still winding its way through the lp
development meatgrinder
<slangasek> ajmitch: you'd think it's an improvement, until you notice in the
conflict-free diff that it's reordered all your history back to
1998 :)
<poolie> it may be live next week
<barry> poolie: nice
<poolie> our next devops-type change after that is to get the package-importer
moved into being a LOSA-run and monitored service
<poolie> i've seen people complaining about some particular package imports
failing [17:33]
<poolie> which is actually a great sign that they care
<poolie> so i hope we will find some time to work on that
<barry> yep. do you think it's possible to drive import failures to zero?
<ajmitch> barry: not really a bug, but is working with a package that uses a
patch system going to be talked about at UDS?
<poolie> one question: we're getting many questions from non-ubuntu bzr users
about memory usage and large file handling
<poolie> does anyone notice this as an issue in udd?
<barry> ajmitch: we can. it's definitely one on my list
<slangasek> "large file handling" - er, in the working tree or in the
repository? [17:34]
<poolie> both
<slangasek> to me "large file" means "> 2GB", I've yet to run into such a file
in UDD
* barry has not
<poolie> the typical user complaint is "i'm doing game development and i have
this multi-GB binary artwork asset"
<slangasek> ah, heh
<slangasek> ask the ubuntu-docs folks :)
<poolie> k
<poolie> i'm guessing the top performance thing for UDD would be network
latency for branch/checkout/push? [17:35]
<slangasek> I think so
* barry too
<ajmitch> those of us in NZ would readily agree :P
<thumper> :) [17:36]
<barry> tbh, i'm not really affected by it ;)
<poolie> any more top bug nominations?
<barry> 5
<barry> 4
<barry> 3
<barry> 2 [17:37]
<barry> 1
<slangasek> no, not that one
<barry> [TOPIC] aob
<MootBot> New Topic: aob
<poolie> i have one
<jam> poolie: would that include wanting stacked branches/history horizons?
<slangasek> bug 1 already gets enough attention ;)
<ubottu> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share"
[Critical,In progress] https://launchpad.net/bugs/1
<barry> slangasek: :)
<poolie> jam, i think at the moment plain roundtrips would be an easier place
to start [17:38]
<poolie> eg the get_parent_map calls
<poolie> but anything, really
<barry> oh, looms push/pull!
<jam> poolie: (I'm wondering if this is initial checkout, or ongoing updates)
<poolie> so i'm applying for an Ubuntu developer membership
<poolie> https://wiki.ubuntu.com/MartinPool/DeveloperApplication
<ajmitch> what's the state of working with debian packaging branches that are
in git?
<poolie> i should have done it ages ago, but here it is now
<poolie> if people would like to endorse me i'd appreciate it [17:39]
<poolie> and thanks to barry for already doing so
<barry> np
<barry> i'm confident you'll get ppu [17:40]
<slangasek> I maintain that having a documented, promulgated solution for UDD
branch mirroring, including partial mirrors, is a key to making
the workflow viable; lots of devs have local mirrors, and even
with decent bandwidth waiting for a fresh download is too much
downtime
<slangasek> local package mirrors, that is
<jelmer> ajmitch: They can be used, but their history is diverged from the
history of the package imports.
<poolie> i think you're right
<slangasek> poolie: I think it's great that you're applying for dev
membership, but I'm crap at writing endorsements for these things
so hopefully your application doesn't hinge on me doing so
<ajmitch> I'd agree there, being reliant on getting branches from 1 location
at the moment is just a bit painful
<poolie> slangasek: mind if i paste that?
<slangasek> poolie: uh... I don't mind :)
<poolie> i think you've even sometimes handled my small patches to debian
years ago [17:42]
<barry> btw, jelmer perhaps: do you know, is there a lag between package
upload and source package branch update? if so, what's the time frame?
<slangasek> I can't recall but frankly am happy to assume that's the case :)
<poolie> i wonder if we could have a eagerly caching proxy for connections to
lp or something...
<poolie> there may be something cheap we can do [17:43]
<poolie> slangasek: do you recall if there's a bug for mirroring?
<jelmer> barry: Sorry, I don't know how often the package importer runs.
<barry> k, np [17:44]
<slangasek> poolie: I haven't opened one, shall I do so?
<poolie> i'll have a look, open one, and subscribe you
<slangasek> ok, thanks
<barry> anything else from the peanut gallery? [17:45]
<barry> in that case... [17:46]
<barry> #endmeetingDistributedDevelopment/20101020 (last edited 2010-10-21 18:35:04 by mail)