20100922
UDD stakeholders meeting 2010-09-22 2200 UTC
Meeting to be conducted on #ubuntu-meeting @ freenode. Duration: 1 hour max.
Chair: Barry Warsaw
Agenda
- Planning for UDS-N
- How many sessions do we need? (e.g. an educational one for new users, a dev one for planning Natty work)
- Who will register and lead the sessions?
- Which track should it be in?
- What are the top three things we need to add to make UDD more attractive to established devs?
- In Bazaar?
- In Launchpad?
- What critical bugs exist that are blocking people right now from using or experimenting with UDD?
- How do we promote and evangelize UDD to the wider Ubuntu developer community?
- Promote open job on Python job's board?
bzr-debuntu - good idea, crappy implementation?
- AOB?
Summary
- Three sessions for UDS-N
- educate new users (on-ramp session) - including a short demo
- feedback from current users/experimenters
- development planning
- Top "three" things UDD needs to attract more ubuntu developers:
- git round-trip support (slangasek)
- review stuff - queues, notifications, landing stories (lifeless)
- replace REVU with launchpad (lifeless)
- lifeless: "basically we have a generic nice tool (Merge proposals) but we need to have a generic nice tool *for packages* too."
- slangasek: "lifeless: that's *my* killer feature for UDD... but I don't think it's possible to achieve unless we're already flipping the switch for building packages from branches"
- slangasek: building from branches
- james_w: tools for local partial mirrors of bzr package branches
- poolie: we'd heard previously that resolving some conflicts were difficult
barry notes: trunk merges always conflict on debian/changelog
- poolie: speed/memory usage on huge trees
- poolie: speed of accessing launchpad?
- james_w: v3 quilt packages IMO
barry: loom threads <--> patch system
- barry: nested branches for packaging (i.e. debian/)? - better integration with debian
- poolie: reliability of imports
- poolie: issues of mergeability between packaging branches and upstream
Action items
poolie to confirm charline to do user studies at UDS-N
poolie to organize a foyer poster
barry to register udd sessions at uds (after finding the right theme/track)
barry to register general bzr/lp session in "app devs" theme
barry to make ajmitch be udd stakeholder representing REVU
poolie to get a better graph of package import failures
barry to start some sphinx docs to be well-integrated w/ wiki.u.c
barry to talk to dholbach about making sure udd is well advertised in pkg guide
barry/poolie to write up job announcements; barry posts to python job board, james_w/slangasek posts to debian-jobs, ubuntu-devel
james_w to merge bzr-debuntu to bzr-builddeb
Meeting log
<barry> #startmeeting
<MootBot> Meeting started at 17:02. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK],
[VOTE]
<barry> welcome to the kickoff meeting for udd stakeholders. all are welcome
to join [18:03]
<barry> [TOPIC] agenda
<MootBot> New Topic: agenda
<barry> https://wiki.ubuntu.com/DistributedDevelopment/20100922
<poolie> good agenda [18:04]
<james_w> indeed
<barry> poolie's making a mumble room for us
<poolie> backchannel in Ubuntu/Ubuntu Distributed Development on mumble
[18:05]
<poolie> technology! :)
<barry> techmology (sic) [18:06]
<poolie> no additions to the agenda? next topic?
<thumper> as long as it is only a backchannel
<thumper> as NZ doesn't like mumble
<poolie> remember to use the mute button or push-to-talk
<barry> [TOPIC] * Planning for UDS-N
<MootBot> New Topic: * Planning for UDS-N
<barry> * How many sessions do we need? (e.g. an educational one for new
users, a dev one for planning Natty work)
<barry>
<lifeless> whats AOB?
<poolie> "any other business" [18:07]
<barry> lifeless: any other business
<james_w> we got some good feedback last time from a session dedicated to that
<poolie> i think one planning session would be good,
<barry> so, we definitely want to do a developers session. does it make sense
to do an evangelizing/educational session too?
<poolie> maybe one feedback session
<barry> poolie: would the feedback session be the developers session?
<poolie> Charline from DX (or something like that?) will be at UDS and i'm
trying to arrange for her to do some user studies of people actually
doing UDD [18:08]
<thumper> I think an educational session is needed
<poolie> or using bzr or launchpad
<james_w> If we have specific things to discuss in more detail then a UDS
session is appropriate. I would think that general planning might be
obsoleted by these meetings?
<poolie> that's probably not a session as such
<barry> poolie: +1 for charline doing that study
<james_w> yeah, and talking to developers outside sessions is always valuable
<barry> james_w: definitely
<poolie> mootbot: action: poolie to confirm charline to do user studies
<poolie> we could also line up some attendees to participate [18:09]
<barry> [ACTION] poolie to confirm charline to do user studies
<MootBot> ACTION received: poolie to confirm charline to do user studies
<poolie> feedback sessions can be good, but not everybody feels comfortable
speaking about their experience in a big room [18:10]
<poolie> or they may simply not remember what they want to say
<poolie> can we do this better?
<poolie> is there another example of a feedback-type session that's worked
really well?
<james_w> I think the need for work planning sessions may become obvious from
our discussions today and over the next month [18:11]
<poolie> mm
<poolie> if it's mostly work planning between the people already active in
udd, it may not strictly need to be at a session
<barry> is it enough just to make sure folks know how to contact the mlist or
stakeholders? e.g. pvt feedback which we can turn into bugs,
blueprints, etc?
<james_w> yeah
<poolie> otoh having it on the schedule allows interested people to turn up
and propose changes to the agenda
<poolie> or just find out about it
<james_w> barry: I think that's a good start, and talking to people to
encourage them and get feedback in an individual setting will help
[18:12]
<slangasek> poolie: include in the session a clearly identified "if you have
other feedback, contact/click [...]"? That way you grab any
feedback from folks who think of what to say afterwards or are shy
<james_w> but I think feedback session can be useful to draw some people out
of the woodwork
<barry> poolie: yep. it provides an outlet for people who may be interested,
or have dabbled, but don't focus on it that closely
<poolie> ok [18:13]
<james_w> 1 year ago it was basically mathiaz listing problems he had, as most
people in the room hadn't used it in anger, but 6 months ago there
was broader participation
<slangasek> and then have that in the gobby doc on the projector, etc., and
announced > 5min before end of session
<poolie> right, it does seem to be slowly building up
<barry> +1
<poolie> i don't know if we'll get around to it but it would be kind of cool
to have a poster in the foyer
<poolie> as another way to prompty people to talk to us
<barry> that's a good idea. i can talk to robbiew about that [18:14]
<poolie> he's going to draw the poster? :-) or just about whether he's ok with
it
<barry> whether it's okay, where to put it, etc
<thumper> I think having a gobby feedback file lowers the barrier for people
to comment/complain
<poolie> thanks
<thumper> there will be people that will write but not talk
<poolie> right, we can try to cover all channels [18:15]
<barry> [ACTION] talk to robbiew about getting a poster to prompt people to
contact us re: udd feedback
<MootBot> ACTION received: talk to robbiew about getting a poster to prompt
people to contact us re: udd feedback
<barry> thumper: cool
<slangasek> thumper: frustratingly, sometimes these are people who are remote
and have given us no other way to contact them for follow-up
questions ;)
<poolie> so we want an educational session, a feedback session, a planning
session [18:16]
<poolie> anything else?
<barry> so, one feedback session for sure. what about a separate educational
session? get the stakeholders to put together a short demonstration
about how all the pieces fit together?
<james_w> I think that would be a good ide
<poolie> i think a short demo would be good
<poolie> that may actually draw other good feedback
<poolie> "i tried that but ....."
<james_w> for one thing it forces us to look at the on-ramp
<thumper> slangasek: I think all you can do to address that is to indicate
clearly that to best get things changed we need contact details :)
<thumper> slangasek: although people will still leave that out
<slangasek> ack [18:17]
<thumper> barry: +1 on an educational on-ramp type session
<barry> excellent. and a planning session if we think it's worth it by the
time we get there
<james_w> +1
<slangasek> +1
<barry> * Who will register and lead the sessions?
<barry> * Which track should it be in?
<barry>
<barry> i'll register the sessions [18:18]
<poolie> [action] poolie to organize a foyer poster (assuming it will be
<poolie> (you get what i mean)
<barry> i do, but mootbot doesn't :)
<barry> [ACTION] poolie to organize a foyer poster (assuming it will be
<MootBot> ACTION received: poolie to organize a foyer poster (assuming it
will be
<UndiFineD> what will be the IRC channels for UDS ?
<poolie> snort
<james_w> UndiFineD: #ubuntu-uds
<poolie> are there going to be as many tracks as LaHulpe? that was pretty
enormous
<james_w> we are moving to something slightly different this time I think
[18:19]
<barry> UndiFineD: there will be session channels based on the track that the
session is in. it'll all be up on the wiki by that time
<slangasek> so one thing happening this time is that UDS is being organized by
"theme" rather than "track"
<james_w> though I don't know if many people understand what that will be
<UndiFineD> ah that's good to know :)
<slangasek> (but using all the existing summit code :)
<poolie> istr someone talking of there already being a draft schedule
somewhere?
<slangasek> http://summit.ubuntu.com/uds-n/
<MootBot> LINK received: http://summit.ubuntu.com/uds-n/
<slangasek> mind the falling tracebacks, though [18:20]
<james_w> in a debug method no less
<poolie> heh
<barry> wfm :)
<poolie> so i guess they would be "Development Process?"
<slangasek> anyway, that shows the current 'themes' that have been proposed
<slangasek> poolie: I think so
<james_w> http://uds.ubuntu.com/tracks/ [18:21]
<MootBot> LINK received: http://uds.ubuntu.com/tracks/
<lifeless> win 38
<poolie> perhaps something under "Application Developers" about just general
non-packaging use of bzr/lp, tutorial and/or feedback
<barry> yep, makes the most sense given what's there
<james_w> with a different list
<barry> yay
<james_w> poolie: I think that would be appreciated
<james_w> so +1 on development process if it is one of the tracks
<poolie> barry would you be so kind as to register that too while you're at
it; me as lead [18:22]
<james_w> otherwise some sort of "other, misc" I guess
<barry> james_w: agreed. poolie you mean, register a session on general
bzr/lp usage?
<slangasek> ah, so which set of themes is authoritative :/
<poolie> barry, yes, in the "application developers" stream
<barry> [ACTION] barry to register general bzr/lp session in "app devs" theme
[18:23]
<MootBot> ACTION received: barry to register general bzr/lp session in "app
devs" theme
<poolie> thanks [18:24]
<barry> i guess these things will get settled in the next couple of weeks. we
can look again at our next meeting for track/registration specifics
(if there's no obvious candidates)
<poolie> jameinel and myself will be there from bzr, plus about one person
from each lp subteam
<barry> i think we know what udd sessions we want though, shall we move on?
<poolie> agree
<barry> poolie: awesome [18:25]
<james_w> yes
<barry> [TOPIC] * What are the top three things we need to add to make UDD
more attractive to established devs?
<barry>
<MootBot> New Topic: * What are the top three things we need to add to make
UDD more attractive to established devs?
<barry> in bazaar; in lp?
<james_w> that's Ubuntu developers?
<barry> james_w: yes i think so
<barry> although i have a dream that everyone is an ubuntu developer :)
[18:26]
<james_w> :-)
<james_w> I guess not everyone is established though
<lifeless> review process
<james_w> I wonder if there are any Ubuntu devs watching that might like to
weigh in as well
<slangasek> git round-trip support? [18:27]
<lifeless> just to say, I think having the review stuff - queues,
notification, landing stories improved would probably help a lot
<lifeless> but thats wearing my motu hat.
<barry> lifeless: what specifically needs improving?
<slangasek> dunno, maybe that's not actually all that relevant to UDD /
established Ubuntu devs, but it's something I hear a lot :/
<lifeless> barry: spend a day in REVU
<james_w> lifeless: could you join the dots there please? [18:28]
<poolie> lifeless: #ubuntu-revu?
<lifeless> poolie: its a webapp
<lifeless> james_w: ok.
<james_w> slangasek: I believe it is on the way
<lifeless> so, motu gets a lot of new packages -many more than main -
<poolie> you mean, look at REVU for a smoother review workflow than is offered
by lp?
<lifeless> and there is a complex review process needed to vet the package.
<lifeless> Its a (slight) superset of the stuff needed when an upstream
release is made of an existing package. [18:29]
<lifeless> and the LP review process for package branches doesn't handle
either scenario (new, upstream-release) well.
<poolie> there's another related question which is: how do we best communicate
what we are doing, and what we think needs doing next
<lifeless> poolie: yes, look at REVU, its /much/ more comprehensive - showing
the diff is only a small fraction.
<poolie> this meeting, and the list, perhaps are enough
<poolie> thumper: ^^ :) [18:30]
<slangasek> lifeless: would that encompass, say, having branch perms change
with the state of the freeze and letting archive admins / release
team / SRU team land changes by merging?
<barry> poolie: though we do want to reach out to folks not on the udd list
<lifeless> slangasek: its in the broad topic I'm talking about, yes.
<thumper> poolie: yes, we know we don't handle package review very well
<lifeless> basically we have a generic nice tool (Merge proposals) but we need
to have a generic nice tool *for packages* too. [18:31]
<barry> lifeless: in your happy world, would lp eventually replace revu?
<poolie> barry, that's true
<lifeless> and there are lots of angles; I haven't done a pareto analysis to
say which bit should be done first.
<thumper> lifeless: there is work in progress to split the code-review from
the proposal-to-merge
<lifeless> barry: hell yes.
<slangasek> lifeless: that's *my* killer feature for UDD... but I don't think
it's possible to achieve unless we're already flipping the switch
for building packages from branches
<thumper> with the intention to make the review part usable elsewhere
<lifeless> thumper: that work is unrelated to me.
<barry> lifeless: that's what i wanted to hear! :)
<thumper> like package reviews
<thumper> is that unrelated?
<ajmitch> lifeless: I'd be happy to kill off REVU, too :)
<lifeless> thumper: but they are still branch reviews [18:32]
<lifeless> thumper: so I don't think splitting it helps at all
<slangasek> lifeless: since otherwise you make the freeze reviewer do all the
uploads & package signing besides
<thumper> hmm..
<lifeless> thumper: I'm not saying 'keep it unsplit' I'm saying 'its on a
different dimension'
<lifeless> slangasek: exactly.
* thumper nods
<james_w> slangasek: so that would be a vote for building from branches?
<james_w> (as a prerequisite for your vote for the landing of changes as a
release/SRU team member) [18:33]
<slangasek> james_w: yesyesyes
<slangasek> :)
<james_w> ok
<lifeless> I find a good way to join dots in situations like this is to take
someone - say slangasek - and watch what they do to do a review
during freeze; at the first non-well-integrated bit, hit the stop
button, go away, fix it.
<lifeless> :)
<poolie> so one lateral approach to this would be to see what is necessary to
make revu present the same ui/workflow on top of branches
<lifeless> (given that we have an overall vision already)
<slangasek> actually, thinking on it, -proposed might be the very place to
trial build-from-branch
<poolie> i don't know if that's at all feasible
<slangasek> once we're ready for such a trial :)
<james_w> poolie: should be feasible yes
*** gilir (~seagle@77.207.180.187) has quit: Quit: Ex-Chat [18:34]
<barry> who's responsible for revu?
<james_w> poolie: except that it has some tie-ins to source packages, and so
you have to deal with arbitrary code execution, or take as input a
branch and a source package
<slangasek> barry: community members [18:35]
<ajmitch> barry: I'm one of the revu admins
<slangasek> it's revu.ubuntuwire.com
<ajmitch> rainct has hacked on it quite a bit, branch is on lp:revu
<barry> ajmitch: hi. i wonder if, as a revu admin, it would make sense to
pull you in as a udd stakeholder?
<ajmitch> barry: sure
<slangasek> so another thing that's been on my list for a while that only just
now surfaced in my brain... tools for local partial mirrors of bzr
package branches [18:36]
<james_w> so far I have seen 1) better review of package branches (revu, new
upstream etc) 2) build-from-branch for PRIMARY
<barry> ajmitch: that would be cool. i'll add your name to
https://wiki.ubuntu.com/DistributedDevelopment/Meetings
<slangasek> I have a local source mirror of Ubuntu main; I can't easily do the
same for the branches AFAIK
<poolie> right, i can see how that would help a lot
<james_w> 3) interacting with git
<james_w> there must be more than that :-) [18:37]
* ajmitch had written up some stuff about branch mirrors somewhere, will take
a look for it
<barry> james_w: well, there are some lower level pet peeves of mine :)
<poolie> any particular bugs that bite?
<poolie> we'd heard previously that resolving some conflicts were difficult
[18:38]
<poolie> speed/memory usage on huge trees
<poolie> oh, speed of accessing launchpad?
<james_w> v3 quilt packages IMO
<barry> i'm thinking about the whole looms/packaging branches story
<barry> and loom threads <--> patch system
<poolie> that would be good [18:39]
<poolie> to me that's the likely next bit of feature work, together with
colocated branches
<poolie> obviously there are a few entangled bits there
<barry> i suspect nested branches will be part of that solution too
<barry> poolie: yeah
<lifeless> nested-loomed branches.
<lifeless> head-asplode [18:40]
<lifeless> barry: I'm not convinced - at all - that you want debian/ to be a
nested branch.
<barry> lifeless: the real goal there is i think better integration with
debian, so that we can get our changes to them
<lifeless> barry: I think that that would be a mistake.
<james_w> and just this second we have
https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/libvirt/maverick-201009222219/+merge/36394
to illustrate my point
<barry> james_w: lovely [18:41]
<poolie> how about issues of mergeability between packaging branches and
upstream
<poolie> or reliability of imports?
<barry> poolie: yes, to both, definitely
<poolie> i guess generally i'd like to get a sense for where our users want
the more_fixes:more_features slider to be set
<james_w> both ends at once [18:42]
<barry> lifeless: i've been struggling with the right model and try different
things each time. i'm not positive nested branches are right either,
but the current situation isn't ideal. but i'm very open to
suggestions. i just want the work flow to be much smother
<poolie> yeah i thought so :)
<barry> er, smoother (freudian slip)
* ajmitch thinks reliability of imports is a big one for adoption of udd -
people give up if the branch is several revisions behind
<slangasek> how are we on archive coverage in UDD (i.e., import failures)? My
general impression is that trying to use UDD and running into a
package that's not imported / not up-to-date kills any enthusiasm
they might've had [18:43]
<barry> yep, and i'm perfectly happy prioritizing bugs/features so we can
knock out the biggest roadblocks first
<slangasek> ah, ajmitch is on the same wavelength :)
<slangasek> so in that respect I think the slider needs to be heavily towards
'bugs' right now
<slangasek> er, 'fixes'; no more bugs please ;) [18:44]
<poolie> slangasek, barry: james may correct me but i believe the import
success rate is above 95% but below 100%
<james_w> we have 725 packages out of date right now
<poolie> so if people access many packages, they may hit that discouraging
situation of finding one out of date
<barry> poolie: that roughly jives with my own experience of finding missing
or out of date source branches
<james_w> unfortunately they aren't uniformly distributed across the set of
all packages [18:45]
<slangasek> IME the chance of a package being out of date is much, much higher
if it's a package that's frequently touched in Ubuntu
<poolie> james_w: out of about 20k?
<poolie> right
<james_w> poolie: ~17k
<slangasek> ... and particularly if it's a package I've touched because I tend
to use 'bzr co' instead of 'bzr branch' :/
<barry> james_w: is it at all correlated to vcs's or upstream hosting
provider?
<poolie> we did make a graph
<https://lpstats.canonical.com/graphs/UddSourcePackagesWithoutBranches/>
(canonical-only for technical reasons, sorry) [18:46]
<poolie> currently reading 0
<james_w> the latest failure appears to be because slangasek just pushed a
bzr-git branch to lp:ubuntu/armel-cross-toolchain-base
<poolie> but this is the number of packages with no import branch at all
<slangasek> james_w: oh, does that break things? Neato!
<poolie> which is not quite the same as them being up to date
<slangasek> james_w: I have two more of those coming ;)
<poolie> i could make a better graph that somehow runs the hottest-100 tool
<james_w> barry: not really. More correlated to the size of package/number of
uploads
<poolie> or indeed perhaps just one that parses that number out of the
package-import output [18:47]
* barry nods
<poolie> james_w would that be reasonable to use? the number on the home page
that's currently 725?
<james_w> slangasek: it's not broken as much as asking for a human to check
because from it's point of view it just went from one history to
another entirely
<james_w> poolie: two concerns, the first being asking the tool for the count
isn't going to be entirely accurate, the second being that parsing
the webpage probably isn't the cleanest way of doing it [18:48]
<slangasek> james_w: ok, so that's the intended effect then :)
<james_w> I have no problem with us graphing that number, and could probably
even have the tool do it itself
<barry> so, just to bring this topic around, i think we need a well-defined
way to identify the problems and publicize our priority for fixing
them. certainly the wiki can be the latter if we can keep it gardened
<poolie> james_w: perhaps i'll graph that as an intermediate step then arrange
for our hottest100 verifier (which isn't limited to the hottest100)
to be graphed [18:49]
<barry> i guess lp:udd for bugs for getting issues into the system
<james_w> poolie: fwiw there's already a script on jubany that will output
relevant numbers in cricket format
<poolie> [ACTION] poolie to get a better graph of package import failures
<poolie> is that going to work? [18:50]
<barry> and i will capture what's been identified above
<poolie> or it has to be Mr Barry?
<barry> [ACTION] poolie to get a better graph of package import failures
<MootBot> ACTION received: poolie to get a better graph of package import
failures
<james_w> barry: yes, udd for any bugs related to this at all
<poolie> ok
<poolie> so there's some useful feedback there
<james_w> I'm happy to move them to more appropriate places as needed
<poolie> some of these things are more like tasks; this doesn't totally fit
lp's "bug in a package" model
<poolie> but we can do it
<barry> poolie: mootbot is not your friend :)
<poolie> and people seem to generally agree with a slant towards removing bugs
that block what's available now [18:51]
<barry> sounds good
<poolie> and on performance it sounds like, more would be nice but it's not
generally the most pressing issue?
* ajmitch would love to see LP having mirrors of branches somewhere other than
the UK, but that's another topic :)
<james_w> I would appreciate someone thinking through with me making the
import service more reliable
<lifeless> move it to the main LP infrastructure
<lifeless> there's -lots- of machinery for reliability there. [18:53]
<poolie> heh
<barry> ajmitch: connectivity to my corner of the USA doesn't seem too bad :)
<lifeless> including scheduling, reporting and alterting
<UndiFineD> ajmitch, what is the size of LP ?
<slangasek> poolie: well, "need partial mirrors" was a proxy for "performance
sucks when I have to download the full branch fresh from launchpad
to work on an arbitrary package" :-)
<ajmitch> barry: right, it's something I've ranted about before but haven't
written up how I think it could possibly work
<poolie> btw jam has a branch up that when landed will cut a bit over 2s
overhead off opening an ssh connection to lp
<barry> lifeless: do you know someone on lp who can make that happen? <wink>
<thumper> UndiFineD: size of what? code base, number of branches, size of
branches?
<james_w> lifeless: it has scheduling and reporting
<thumper> james_w: who reads the reports? [18:54]
<UndiFineD> thumper, any info that is relevant to mirroring
<poolie> i'd like to break down the inertia that p-i is just james's thing
<barry> poolie: i *always* use a shared repo
<james_w> thumper: anyone who uses the webpage, I don't know if anyone else
looks at them regularly
<james_w> https://dev.launchpad.net/Code/PackageImporter
<poolie> i think some other people have sent you patches?
<poolie> but not very much
<james_w> jam has sent a few
<barry> shall we move on to the next topic? [18:56]
<lifeless> james_w: its up to you; I think you'd be less of a special case if
it ran as part of th eoveral LP stack is all
<lifeless> james_w: I'm not suggesting making it use the DB or anything.
<james_w> lifeless: see the wiki page above
<poolie> barry, yes, let's move on
<thumper> barry: you have 3 minutes :)
<james_w> plus, it would be nice to work out why LP now likes to do this every
so often: http://package-import.ubuntu.com/status/remote-tty.html
<lifeless> james_w: yes yes ;) [18:57]
<lifeless> oh that 401 is interesting.
<barry> thumper: we might go a little over. i'm going to skip the critical
bugs item because i think we've mined that in this topic (without
identifying specific bugs)
<barry> [TOPIC] * How do we promote and evangelize UDD to the wider Ubuntu
developer community?
<barry>
<MootBot> New Topic: * How do we promote and evangelize UDD to the wider
Ubuntu developer community?
<barry> certainly a uds session is a start
<barry> i've blogged about it, so that reaches two other people [18:58]
<ajmitch> consistent, clear documentation on how to do common tasks (what's
there is pretty good)
<james_w> the documentation could certainly be improved. I consider what's
there to be a bare minimum [18:59]
<barry> ajmitch: i think they are pretty good howtos now (maybe could use a
bit of gardening).
<james_w> I think some pictures would help
<barry> james_w: i'd be willing to start a branch of reST/sphinx docs [19:00]
<james_w> barry: lets do it
<poolie> it seems like it will tip over once it gets into the general 'how do
you start doing things in ubuntu?' documentation [19:01]
<poolie> not specific UDD stuff
<barry> we just have to be careful about not having two locations for docs
that get out of date
<slangasek> barry: how would that integrate with wiki.u.c, which is where
existing devs expect to findstuff?
<poolie> which you could say would be the moment we exit our alpha phase
<poolie> it's probably not ready to be the only thing recommended, but is it
mentioned there now?
<barry> slangasek: i don't have an answer for that atm, but it's what i was
getting at above [19:02]
<barry> poolie: i think it's pretty well hidden
<slangasek> barry: ack
<barry> [ACTION] barry to start some sphinx docs to be well-integrated w/
wiki.u.c
<poolie> can we make it a bit less hidden now?
<MootBot> ACTION received: barry to start some sphinx docs to be
well-integrated w/ wiki.u.c
<james_w> Daniel did some work on putting it in as an alternative in the
packaging guide I think [19:03]
<poolie> dholbach?
<james_w> yeah
<poolie> barry could you talk to him too?
<barry> poolie: yep. i think the way to describe it now is that udd is a
viable alternative, may have rough spots, but is the wave of the
future [19:04]
<ajmitch> it's currently in there at
https://wiki.ubuntu.com/PackagingGuide/Complete#Creating a Debdiff
<james_w> I think this is certainly a topic worth coming back to frequently
<barry> ajmitch: thanks
<barry> james_w: agreed
<barry> [ACTION] barry to talk to dholbach about making sure udd is well
advertised in pkg guide [19:05]
<MootBot> ACTION received: barry to talk to dholbach about making sure udd is
well advertised in pkg guide
<barry> [TOPIC] * Promote open job on Python job's board?
<barry>
<MootBot> New Topic: * Promote open job on Python job's board?
<barry> poolie: what do you think?
<james_w> what's the purpose of that board? [19:06]
<thumper> which job?
<barry> to reach the wider python community about job openings
<james_w> then I think it makes sense
<barry> thumper: sorry, i misplaced the link -- it's specifically a canonical
udd opening
<thumper> ok [19:07]
<barry> i will write it up in python job board fashion and submit it. i just
don't want the resumes :)
<poolie> barr, i think that would be great
<james_w> it will certainly involve a lot of Python
<barry> [ACTION] barry to submit udd opening to python job board
<MootBot> ACTION received: barry to submit udd opening to python job board
<poolie> i'm actually even more interested in how we could get people with
deb/ubuntu packaging experience [19:08]
<poolie> james_w: you don't have a sister do you?
<barry> poolie: or a twin/clone? :)
<james_w> poolie: I do
<thumper> sibling?
<james_w> not really her area of expertise though
* slangasek chuckles [19:09]
<poolie> is there an #ubuntu-jobs, or would it be horribly offtopic to post to
ubuntu-devel?
<slangasek> IIRC there's a debian-jobs
<ajmitch> people may watch the normal ubuntu.com/employment page
<james_w> I don't think it would be terribly offtopic
<barry> ajmitch: i think it's on there
<james_w> and we could sell it on debian-jobs
<barry> james_w: debian-jobs is a mailing list? [19:10]
<james_w> I think so
<poolie> it's http://webapps.ubuntu.com/employment/canonical_BSE
<barry> poolie: thanks
<slangasek> yes, lists.debian.org/debian-jobs/
<poolie> (incidentally the canonical employment page sucks to have such
generic text about the jobs, but it's being worked on)
<barry> slangasek: cool. well, if i'm going to do the pyjobs board, i can
send an email to that too. poolie will you work with me to craft the
right language? [19:11]
<poolie> sure
<poolie> james or slangasek, could you post to ubuntu-devel and to
debian-jobs?
<slangasek> though I guess as many Debian people read the webapps.ubuntu.com
postings as follow debian-jobs, maybe
<barry> [ACTION] barry and poolie to work on posting to debian-jobs
<MootBot> ACTION received: barry and poolie to work on posting to debian-jobs
<james_w> one of the things we are interested in is working better with
Debian, so debian-jobs seems vaguely appropriate
<slangasek> barry: we could also circulate it word-of-mouth within the Debian
python community, if we're specifically after python + packaging
experience
<barry> james_w: +1. happy too if you or slangasek want to take that on
<slangasek> I wouldn't post it to debian-python though :P
<barry> slangasek: :) [19:12]
<poolie> slangasek: i'd really appreciate that
<barry> cool. i think we've identified some good outlets [19:13]
<barry> [TOPIC] * bzr-debuntu - good idea, crappy implementation? :)
<barry>
<MootBot> New Topic: * bzr-debuntu - good idea, crappy implementation? :)
<barry> this is mostly just self gratification :)
<poolie> probably. next topic?
<poolie> :)
<poolie> no, actually it does look good
<ajmitch> brief explanation for the uninitiated?
<poolie> if it's a generic url-shortcutting thing we should probably split it
into a mechanism + setting thing
<james_w> barry: I would have no problem merging it with bzr-builddeb if you
wanted [19:14]
<barry> i wasn't sure if ubuntu:maverick/foo was better than
ubuntu+maverick/foo, but it was certainly easier to register
<thumper> barry: hmm...
<slangasek> sorry, what's bzr-debuntu?
<poolie> to me the first is more tasteful
<james_w> using one of poolie's favourite terms: "policy layer"
<barry> slangasek: bzr branch u:gtimelog == lp:ubuntu/gtimelog
<ajmitch> a bzr plugin for changing lp: urls to be shorter?
<slangasek> ah
<barry> ajmitch: yep [19:15]
<poolie> https://edge.launchpad.net/bzr-debuntu
<poolie> https://code.launchpad.net/~barry/bzr-alldocs/debuntu/+merge/36357
<ajmitch> that'd be a lot of documentation to change & habits to break :)
<barry> james_w: +1
<barry> ajmitch: it's just a convenience. it uses the launchpad plugin to do
the actual lookup. so "quick and dirty" [19:16]
<slangasek> is that going to be supported by bzr out-of-the-box, like lp: is?
Otherwise it may create tension when it comes to writing Vcs-Bzr
fields in packages in particular
<james_w> barry: with additional things that we discussed at the rally too
<thumper> barry: we want to stop the plugin actually doing lookups
<barry> james_w: +1
<thumper> barry: but there is a little more LP work to make that happen
<barry> thumper: nod [19:17]
<barry> anyway, no need to go into too much detail. bzr-builddeb does seem
like a happy home for it
<poolie> slangasek: i think it's be good to have it built in, which is why i'm
interested in making it clean and having separate policy
<poolie> just as simple as {'u': 'lp:ubuntu/'}
<poolie> for the expansions
<barry> cool [19:18]
<slangasek> ok
<barry> [TOPIC] AOB
<MootBot> New Topic: AOB
<barry> anybody have anything not on the agenda?
<slangasek> yeah, bzr-builddeb is something the dev may install /after/ doing
a debcheckout, so we don't want debcheckout to fail :)
<slangasek> not from me
<barry> slangasek: ultimately, they all map back to bzr+ssh urls
<poolie> thanks very much [19:19]
<slangasek> barry: but doing that mapping by hand as a non-bzr-y dev --> fail
<poolie> i know this meeting was a bit scrappy but it's really useful to be
getting some feedback regularly
<barry> one point of order. dst down under will mean we're moving this
meeting one hour earlier utc in two weeks. we'll keep it that way at
least until november (when the usa leaves dst)
<slangasek> poolie: happy to help :)
<poolie> let's do it again in 2m?
<barry> slangasek: i know :(
<poolie> i mean 2 weeks [19:20]
<james_w> ye
<james_w> p
<slangasek> yeppers
<barry> poolie: phew! i'm hungry. 2w, and yep i agree
<poolie> what barry said is what's already on the calendar, i think
<thumper> ack
<barry> fab. just wanted to thank everyone for coming and we'll chat again in
2w if not sooner
<barry> #endmeetingDistributedDevelopment/20100922 (last edited 2010-09-23 21:50:09 by mail)