16:13 -!- T-Bone [~varenet@T-Bone.developer.debian] has joined #ubuntu-meeting
16:19 -!- TheMuso [~luke@dsl-202-173-132-131.nsw.westnet.com.au] has joined #ubuntu-meeting
16:30 < sparkes> could be a non productive meeting if this doesn't get sorted today
16:35 -!- fredo [~fredo@212.21.138.47] has joined #ubuntu-meeting
16:35 -!- fredo [~fredo@212.21.138.47] has quit [Client Quit]
16:53 -!- DacInBC [~darren@S0106000094c6219f.ok.shawcable.net] has joined #ubuntu-meeting
16:54 < DacInBC> Do I have the right time?
16:55 < asw> in one hour? 
16:56 < DacInBC> damn I thought I was 5 minutes away, I seem to be off by an hour
16:56 -!- fredo [~fredo@212.21.138.47] has joined #ubuntu-meeting
16:56 -!- fredo [~fredo@212.21.138.47] has quit [Client Quit]
16:59 < Kamion> well, we have three community council members here, can't be that bad
17:00 -!- Henri1 [~Henrik@henrik.gotadsl.co.uk] has joined #ubuntu-meeting
17:02 < asw> hi Kamion. I really enjoyed chatting with you the other day. 
17:06 -!- ph_ [~ph@pD9E106C1.dip.t-dialin.net] has joined #ubuntu-meeting
17:09 -!- ph_ [~ph@pD9E106C1.dip.t-dialin.net] has left #ubuntu-meeting ["Verlassend"]
17:20 < bluefoxicy> o.x tired
17:35 -!- jmchugh [~jmchugh@silenceisdefeat.org] has joined #ubuntu-meeting
17:43 -!- Henri1 [~Henrik@henrik.gotadsl.co.uk] has quit [Read error: 60 (Operation timed out)]
17:52 -!- olafura [~olafura@a058.nemendur.hi.is] has joined #ubuntu-meeting
17:53 < jmchugh> quit
17:53 -!- jmchugh [~jmchugh@silenceisdefeat.org] has quit ["BitchX: born to raise hell"]
17:53  * mako waves to everyone
17:53  * T-Bone waves back
17:54  * bluefoxicy yawns and tailwaves
17:54 -!- sivang [~sivan@box79162.elkhouse.de] has joined #ubuntu-meeting
17:55 -!- jmchugh [~jmchugh@silenceisdefeat.org] has joined #ubuntu-meeting
17:56 -!- johnlevin [~johnl@dsl-80-42-68-60.access.uk.tiscali.com] has joined #ubuntu-meeting
17:58 < mdz> who is running the CC meeting today?
18:00 < sivang> you maybe ? :)
18:00 -!- ctalkep [~ctalkep@212.21.138.21] has joined #ubuntu-meeting
18:00 < sivang> sabdfl ?
18:00 < ctalkep> hi guys
18:00 < mdz> he'll join shortly
18:01 -!- kent [~kent@h125n1fls24o825.bredband.comhem.se] has joined #ubuntu-meeting
18:01 < sivang> ProactiveSecurity is the first one?
18:01 -!- sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting
18:01 < sabdfl> hi all
18:01 < sivang> hey sabdfl
18:02 < Kamion> ProactiveSecurity isn't a CC matter; it should be discussed elsewhere, maybe ubuntu-devel and then the tech board if there's a controversial decision to be taken
18:02 < johnlevin> hi sabdfl
18:02 < johnlevin> hi sivang
18:02 < sabdfl> Kamion: agreed, let me get things rolling
18:02 < sabdfl> elmo, mako, around?
18:02 < sivang> ok
18:02 < mako> sabdfl: yep
18:03 < sivang> so the new developers mentoring maybe?
18:03 < Kamion> sabdfl: sorry to preempt, was mainly answering a question from sivang from just before you joined
18:03 < sabdfl> noprob, was late, apologies
18:03 < sabdfl> sivang: let's get elmo in here
18:03 < sivang> Kamion : you did ? what did I ask?
18:03 < Kamion> 17:01 < sivang> ProactiveSecurity is the first one?
18:03 < sivang> :)
18:03 < sivang> oh
18:03 < sivang> :)
18:03 < elmo> here
18:03 < sivang> hey elmo
18:04 < sabdfl> elmo: was just sms'ing a fly for the trout :-)
18:04 < sabdfl> ok, let's get going
18:04 < sabdfl> JohnMoser, around?
18:04 < mdz> not here
18:04 < sabdfl> not sure what his nick is on irc, but I agree with Kamion
18:04 < Kamion> that's bluefoxicy I think
18:04 < sabdfl> http://wiki.ubuntu.com/CommunityCouncilAgenda
18:05 < Kamion> 16:54  * bluefoxicy yawns and tailwaves
18:05 < Kamion> maybe gone to bed
18:05 < mdz> ah
18:05 < mako> five minutes before the meeting :)
18:05 < bluefoxicy> huh?
18:05 < bluefoxicy> hi
18:05 < Kamion> ah, there
18:05 < sabdfl> having said that, he did phrase it in a "what does the community want" sort of way, so let's address that
18:05 < sabdfl> technical discussion is tech board's department
18:05  * bluefoxicy John Moser
18:06 < bluefoxicy> Yes, I'm sure it'll be a very short discussion
18:06 < sabdfl> bluefoxicy: care to comment?
18:06 -!- kent [~kent@h125n1fls24o825.bredband.comhem.se] has left #ubuntu-meeting ["Lämnar"]
18:06 < bluefoxicy> the tech board will be where the deep discussion occurs on proactive security.  :)
18:06 < bluefoxicy> sabdfl:  about Proactive Security?  (*first time here*)
18:06 < sabdfl> do we need to discuss this here? your hnt was intriguing but oblique
18:07 < Kamion> actually I'd say the deep discussion should happen on ubuntu-devel; the tech board should take any hard decisions that aren't clear to the development community, I feel
18:07 < sabdfl> bluefoxicy: this is the community council meeting
18:07 < sabdfl> mainly, we are focused on how the ubuntu community organises itself
18:07 < sabdfl> roles and responsibilities
18:07 < sabdfl> appointments and policies
18:07 < bluefoxicy> sabdfl:  Ah.  I know nothing.  :)
18:07 < sabdfl> bluefoxicy: ok, then please read the governance section of the web site for future agenda items :-)
18:07 < bluefoxicy> sabdfl:  Would it be appropriate to skip the topic altogether and move it to a more appropriate forum?
18:08 < Kamion> is there a group of people interested in investigating this kind of issue, perhaps with the toolchain people?
18:08 < sabdfl> bluefoxicy: yes, thanks
18:08 < mdz> Kamion: I have a couple of names
18:08 -!- Henri1 [~Henrik@henrik.gotadsl.co.uk] has joined #ubuntu-meeting
18:08 < sabdfl> let's move on to mentoring
18:08 < Kamion> OK, maybe we can revisit this when there's some kind of appointment to be made
18:08  * bluefoxicy decides to stick around to get a better grasp on what goes on here, backgrounds.
18:09 < sivang> probably now ubuntu is laking manpower to do mentroing, IMHO
18:09 < sabdfl> we haven't done a good enough job of mapping out a "new maintainer" process
18:09 < sabdfl> maybethat's a good focus for discussion now
18:09 < sabdfl> and will lead us nicely into the "masters of the universe" topic
18:10 < sabdfl> can I throw it open for discussion on:
18:10 < sabdfl>  - what sort of process we want for maintainer appointments
18:10 < sabdfl>  - how we'll distinguish between universe and main maintainers, if at all
18:10 < sabdfl>  - how mentoring can fit into that framework
18:10 < sabdfl> ?
18:10 < sabdfl> fire away
18:10 < Kamion> before touching process, I think we need to know what criteria we expect maintainers to fulfil before accepting them
18:10 < Henri1> Perhaps one should set up a list of 'Junior Jobs', like KDE has, which are easy dev tasks for beginners to start on. I think they do it in bugzilla in fact.
18:11 < sabdfl> Kamion: also, need to define the responsibilities and authority, so we know how much good / damage a maintainer could do
18:11 < mdz> at the BOF in Oxford, we outlined a scheme which involved a natural progression from someone who submits patches through being a team leader
18:12 < T-Bone> sabdfl: what about gateways for say "people who are already debian maintainers"?
18:12 < mako> Kamion: a lot of those "answers" are up here: http://www.ubuntulinux.org/community/maintainers
18:12 < mdz> and what responsibilities would be involved at each level of commitment
18:12 < sabdfl> t-bone: yes, this makes sense
18:12 < sivang> T-Bone : this has already been used:) AFAIK
18:12 < sabdfl> in a real sense a dd is already an ubuntu maintainer
18:12 < Kamion> at the universe level, at least
18:12 < sabdfl> because when we are in hotsync mode an upload to debian is effectively also an upload to ubuntu
18:12 < Kamion> mako: ah, yes
18:12 < T-Bone> sabdfl: good to know. Given how long the Debian NM process is, i'd rather not go through it twice ;)
18:13 < mako> well, in a similar, so is an upstream.. but in relation to unierse, it is clearly the case
18:13 < mako> T-Bone: i don't think the goal is to replicate NM :)
18:13 < mako> at least, it's not my goal
18:13 < sabdfl> t-bine in addition to this it makes sense to have a fast track for proven dd's
18:13 < T-Bone> mako: *G* ;)
18:13 < T-Bone> sabdfl: right
18:13 < sabdfl> i'd like us to have fast track processes for people who are upstream
18:14 < sabdfl> as mako points out, it's their code we are shipping
18:14 < Kamion> there are upstreams and upstreams, of course
18:14 -!- hornbeck [~hornbeck@adsl-69-153-250-222.dsl.okcyok.swbell.net] has joined #ubuntu-meeting
18:14 < mako> i'd like us to fast track processes for anyone who has proven they are technical competant and socially capable :)
18:14 < mako> and motivated enough to stick around :)
18:15 < sabdfl> hmm... having written http://www.ubuntulinux.org/community/maintainers i'm finding it hard to disagree with it :-)
18:15 < T-Bone> mako: hehe; gonna make yourself a few friends ;)
18:15 < sabdfl> Kamion: naturally :-)
18:15 < mdz> and being an upstream does not usually qualify you to make packaging decisions
18:15 < Kamion> worth noting that we've had an upstream come very close to trying to trojan Debian in the past
18:15 < mako> if we know those things, and if the TB and CC can sign off on it, we're good to go
18:15 < sabdfl> Kamion: not a risk we can mitigate from serious projects
18:15 < T-Bone> both mdz and Kamion are right too
18:15 < sabdfl> we agreed TB and CC both need to sign off on a new maintainer
18:16 < mdz> most upstreams have zero experience with packaging, having relied on others to do it
18:16  * mako remembers at least one of them
18:16 < sabdfl> so fast track is fine, given that we have a review process
18:16 < mdz> what will the input to the review process be, though?
18:16 < sabdfl> i think in the early days we will get by with track record and community credibility
18:17 < sabdfl> i don't think we should decline Linus' request to maintain the kernel
18:17 < sabdfl> should it come :-)
18:17 < mdz> I think linus would be a fairly crap kernel package maintainer, to be honest :-)
18:17 < T-Bone> sabdfl: you'll have to define "community credibility" tho, adn that's not gonna be trivial, i'm afraid
18:18 < mako> mdz: well in your role on the TB, you'd be able to make that position heard IRT linus :)
18:18 < sabdfl> t-bone, to a certain extent we can be brutal in the beginning
18:18 < sivang> what is going to be done to allow new people into the NM / devel process? many want to assist and help in development, but don't know how to start.
18:18 < Kamion> in the early days, do we expect to have enough CC bandwidth to review candidates individually?
18:18 < T-Bone> sabdfl: agreed
18:18 < mako> Kamion: yes
18:18 < sabdfl> Kamion: i would rely heavily on peer assessment
18:18 < mdz> what about people that we don't already know, either personally or by reputation?  that's where we need additional input into the process
18:18 < mako> i mean sort of.. they will be mentored
18:18 < mako> and will have done work
18:18 < Kamion> I realise we won't, in the long run; but the experience will let us work out what we need from peer assessment
18:19 < mako> mdz: we ask them to find a mentor and to work in the community until they we do know them
18:19 < mako> mdz: until we do know them
18:19 < Kamion> sabdfl: that's fine, I'm just trying to work out whether we can get away without trying to delegate an essentially undefined process right from the start :-)
18:19 < sabdfl> we could think of this as an exercise in pipelining
18:19 < Kamion> we can delegate once it's better-defined
18:19 < sabdfl> we need to setup the pipeline, defining where people need to start
18:20 < sabdfl> for example, have a page that lists work that needs doing
18:20 < sabdfl> and a commitment to review submissions against that list
18:20 < sabdfl> and keep track of who has done what
18:20 < sivang> sabdfl : finally :)
18:20 < sabdfl> as people progress up that list, we'll get a sense of their progress
18:20 < mdz> who will do that bookkeeping?
18:20 < Kamion> mdz: of course, we don't necessarily have to be as focused on packaging as Debian is; most of our wishlist is development more than packaging
18:20 < sabdfl> so for absolute community newbies, they always know where they stand
18:20 < mdz> Kamion: true
18:21 < mako> so.. i guess my question is what is missing from the maintainers page now?
18:21 < mdz> Kamion: in our progression, though, we defined a maintainer as someone who makes new releases of packages
18:21 < sabdfl> i would very much like to keep an explicit test of packaging policy knowledge in the pipeline
18:21 < mdz> which is firmly in packaging territory
18:21 < T-Bone> sabdfl: looks like what you're defining is basically a BTS with assignement tracking
18:21 < sabdfl> mdz: do you have a url for those stages?
18:21 < mdz> sabdfl: I have a text file of my notes
18:21 < mdz> could paste it here
18:21 < sabdfl> t-bone: and a record of quality of work done
18:21 < sabdfl> mdz: go for it
18:22 < T-Bone> bugs are filed, with a "difficulty" markup, and assigned to volunteers
18:22 < mdz> patcher
18:22 < mdz>         makes changes in their own branches
18:22 < mdz>         uses branches to submit their changes to committers and maintainers
18:22 < mdz>         anyone can do this
18:22 < mdz>         essentially unprivileged, but much more fun than the unprivileged mode
18:22  * asw wonders if mdz could post the text file to devel
18:22 < mdz>         of most projects
18:22 < mdz> -> commit rights
18:22 < mdz>         can merge their stuff into mainline
18:22 < mdz>         granted by maintainer
18:22 < mdz> -> maintainership
18:22 -!- gruberman [~gruberman@h9n2fls35o294.telia.com] has joined #ubuntu-meeting
18:22 < mdz>         can issue a new official release
18:22 < mdz> -> team leadership
18:22 < mdz> -> technical council & governance council
18:22 < mdz>         include team leaders for decisions
18:22 < mdz> this was jdub's BOF; I expected he would post notes to the wiki
18:23 < mdz> so a patcher is essentially unprivileged, someone who is interested in doing work
18:23 < mdz> but we provide means for them to trivially submit their changes to committers and maintainers
18:23 < sabdfl> quite a lot of that depends on a good revision control system, which we do not have right ow
18:24 < mdz> that sounds like the right place to start, where this review would take place
18:24 < sabdfl> can we make this workable on a straight "flying patches" basis?
18:24 < mdz> well, making it trivial requires that
18:24 < mako> mdz: send that file to me and i will post it in the summary for the meeting
18:24 < mdz> sending patches is more work, but we can streamline that process as well
18:24 < mdz> mako: ok
18:24 < mdz> mako: they're raw
18:25 < sabdfl> ok. we have the MaintainerCandidates page on the wiki
18:25 < mdz> we could provide a simple command line tool or two to manage a patch queue
18:25 < sabdfl> mdz: ?
18:25 < mdz> sabdfl: so I've downloaded the source for a package, and make some changes
18:26  * sabdfl didnt think that he would ever hear "simple command line tool" and "revision control system" in the same line again
18:26 < mdz> sabdfl: we could make it easy to turn that into a patch and drop it someplace where it caneb reviewed
18:26 < sabdfl> bts?
18:26 < mdz> sabdfl: ah, that's because I was talking about doing this before revision control :-)
18:26 < mdz> I would actually prefer that it be more streamlined than a BTS
18:26 < mdz> that's part of the problem with the Debian contributor approach
18:27 < sabdfl> mdz: would you like a dedicated system for tracking each of these patches, in a queue?
18:27 < mdz> having to file a bug to submit something creates this negative ethos around the process
18:27 < mdz> maintainers take it as criticism, contributors shy away from it
18:27 < mdz> sabdfl: yes, but very very simple
18:27 < sabdfl> mdz: ok
18:28 < mdz> at its core it would take as input a source package and a working tree, and a description (log message)
18:28  * mako is still a little doubtful about another system
18:28 < mdz> and drop the patch into a directory where the maintainer can review it
18:28 < sabdfl> i don't think i can add another project to the development queue and have it ready before the december conf
18:28 < mdz> if the deadline is december, perhaps we can do better ;-)
18:29 < sabdfl> i can definitely do better, but it will be a trade of this for the bug tracker, sooner
18:29 < Kamion> it doesn't really want to be web-driven anyway, could just be mail triggered by a command-line tool
18:29 < mdz> this shouldn't be contingent on implementation details, anyway; the important thing is the role
18:29 < sabdfl> from my side we want to promise two things:
18:29 < Gmail> as we are on the subject of package maintanor i wound like to add: can the package maintanor add the program to gnome menu and kde menu when it makes sence to like all games should be in the games menu or you can do what debian does and make a ubuntu menu. </my-2cents>
18:29 < sabdfl>  - rapid review of patches, so candidates get steady, reliable feedback
18:30 < sabdfl>   - an insititutional memory of the quality of work that was done, so candidates build up a track record
18:30 < mdz> Gmail: that would be a technical decision to be made by the desktop team
18:30 < mako> Gmail: i think that's a slightly different topic.. and perhaps more for teh technical board
18:30 < sivang> sabdfl : insititutional <== maybe documented in some sort
18:30 < sabdfl> yes
18:31 < mdz> it screams revision control, doesn''t it?
18:31 < sabdfl> i'd lke people to be able to point at a web page somewhere and say "that's my contribution to date"
18:31 < mdz> s/"/'/
18:31 < sabdfl> yes, and database
18:31 < sabdfl> hmm.... :-)
18:31 < sabdfl> ?
18:31 < Gmail> isnt it the package manigers job to package stuff correctly? so it will be his job to package it that stuff gets added to the menu??
18:31 < bob2> hehe
18:31 < Henri1> A dedicated phpBB board where patchers write a short message describing their patch, and include it as an attachment?
18:31 < elmo> sabdfl: damn, dude, I'm surprised you manage to have lunch without finding a reason to design a database for it :-P
18:32 -!- Pluk [~Pluk@248-85.ipact.nl] has joined #ubuntu-meeting
18:32 < sabdfl> elmo: it's already in the design: industrial karma, remember?
18:32 < mdz> Gmail: it is the package maintainer's responsibility to follow the technical direction of the project
18:32 < Henri1> Could be set up in hours and would track user participation
18:32 < sabdfl> just not in the implementation  pipeline yet
18:32 -!- stvn [~steven@82.197.192.33] has joined #ubuntu-meeting
18:32 < mako> i don't think having a fully tracked full-blown database is necessary for determining if people do work to the point where they would make good maintainers
18:32 < Kamion> Henri1: I don't think most people want to fire up a web browser just to send a patch ...
18:33 < Kamion> Henri1: these people are already at the command-line doing work there
18:33 < sabdfl> ok, simplest option is to have a place that the maintainers can write to that says "i agree, xxx did this work, it was good"
18:33 < mako> i think we should insist on maintainers being mentored and trust that a lot.. and then expect maintainers to come forth with evidence of their continued and long-term good work :)
18:33 < mako> sabdfl: yeah, provide links
18:33 < Henri1> I guess I'm more gui and web based than most :)
18:33  * sivang agrees with mako
18:33 < sabdfl> ok, here's a proposal
18:33 < elmo> is the maintainers for MOTU or something else, btw?
18:33 < sabdfl> we put the cv tracking in the hands of the maintainer candidate
18:34 < sabdfl> on the wiki
18:34 < stvn> A
18:34 < mako> sabdfl: a fully blown echelon system would be great, or even a little brother system, but it's a lot of work and not essential :)
18:34 < sabdfl> so when someone has a patch accepted they add it to their wiki, with a comment from the mentor
18:34 -!- silbs [~sbsm0084@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting
18:34 < mako> an "application" to the technical board should include evidence of work in ubuntu and/or debian over a period of time
18:34 < mako> ergh. to the CC/TB
18:34 < T-Bone> don't want to sound too dark here, but managing maintainers also includes managing their removal, which can happen for various reasons (among which stands self-retiring, and inactive maintainers)
18:35 < mako> T-Bone: right, we've got automatic retiring if people don't renew it
18:35 < sabdfl> t-bone: what mako said
18:35 < T-Bone> i think elmo has some figures about how many inactive maintainers we have in debian already :}
18:35 < mako> sabdfl: which i was less excited about last time but super excited about now having talked to some folks about the way it works in freebsd :)
18:35 < Kamion> sabdfl: that works for me, puts the onus on the prospective maintainer, and we can do a quick check for truthfulness
18:35 < T-Bone> mako: ok
18:35 < sabdfl> yes
18:35 < mako> T-Bone: tbm is the one who has done that research AFAIK
18:35 < sabdfl> ok
18:35 < sabdfl> here's another suggestion
18:36 < sabdfl> let's use the existing bts's for tracking the status of the actual patch
18:36 < sabdfl> so say a bug gets opened, and a candidate wants to hepl out
18:36 < sabdfl> they put a note saying they are working on a patch
18:36 -!- arunbhanu [~arun@bb220-255-42-190.singnet.com.sg] has joined #ubuntu-meeting
18:36 < sabdfl> they attach the patch and then ask for a review
18:36 < thom> sabdfl: like the mozilla review and superreview stuff?
18:36 < mako> perhaps they cc a list
18:37 < sabdfl> when the patch is accepted, they can ad that bug to their wiki cv
18:37 < Kamion> thom: could be just by the maintainer in our case
18:37 < sabdfl> thom: yes
18:37 < Kamion> (which is kind of like mozilla sr I guess)
18:37 < sabdfl> we should offer a promise of a review within a certain timeframe
18:37 < thom> yeah, sr is the component owner, so =~ maintainer for us
18:37 < sabdfl> 48 hours
18:38 < sabdfl> so people don't work on patches that sit in limbo
18:38 < sabdfl> but, at the same time, we don't have to promise to try to turn turds into diamonds
18:38 < Kamion> perhaps 2 working days rather than 48 hours
18:38 < thom> sabdfl: a week is probably more reasonable ; aim for 48 hours, promise a week
18:38  * Kamion doesn't want to commit to working weekends :-)
18:38 < sabdfl> if the patch is b0rked, say so, 
18:38 < sabdfl> and move on
18:38 < sabdfl> with maybe a hint as to where to look for better results
18:39 < sabdfl> ok, happy for mdz and his team to set the level of the commitment they are comfortable
18:39 < sabdfl> with
18:39 < sabdfl> is this sounding workable?
18:39 < sivang> what about stuff other then docs that entails you to be called a maintainer? or is packaging most of it?
18:40 < mdz> I think we can implement it, yes
18:40 < Kamion> we haven't really done mentoring as such yet. perhaps mentors could act to review patches as well as the component maintainer?
18:40 < Kamion> that seems like a reasonably straightforward way to go about it, and IIRC bugzilla has some support for that kind of thing
18:40 < sabdfl> sivang: i'm open to suggestions as to how we can get doc writers to have full commit capability
18:41 < sabdfl> i think mentoring here is the general process of "reviewing patches" 
18:41 < sabdfl> hopefully people strike up personal relationships
18:41 < mdz> there is much more to it than reviewing patches
18:41 < sabdfl> if someone gets along well with an existing ubuntu maintainer, they will naturally ask them for guidance
18:41 < hornbeck> sabdfl: I think if doc writers are to have permission to commit they need to be mentored by dev's first in the proper way of doing everythin
18:41 < sabdfl> mdz: elaborate?
18:41 < mdz> there should be some assistance given to the process of learning how the system is put together, in order to make effective patches
18:42 < sabdfl> hornbecK: i would trust that a doc writer would not commit code changes, if that's part of the social structure and agreement
18:42 < mdz> sabdfl: what will we provide in order to allow the contributor to get to the point of making effective patches?
18:42 < hornbeck> sabdfl: true
18:42 < mako> hornbeck: if we can't trust doc writers to not upload kernels they shouldn't be maintiners
18:43 < mdz> probably a lot of documentation
18:43 < hornbeck> mako: understood
18:43 < sabdfl> mako: disagree
18:43 < mako> being a maintainer is ultimately about trust
18:43 < sabdfl> hmm... maybe agree, depending on how i interpret your words
18:43 -!- gro [~gro@u212-239-167-206.adsl.pi.be] has joined #ubuntu-meeting
18:43 < mdz> sabdfl: I think he was agreeing with you
18:43 < sabdfl> mako: yes, exactly
18:43 < sivang> sabdfl : agreed
18:43 < sabdfl> and that goes for docs as much as code
18:43 < mako> sabdfl: i think i agreed with you, so i suspect i'm just being opaque :)
18:43 < sabdfl> ok
18:44 < mdz> one of the points of consensus from oxford was that we would promote social solutions over technical ones for problems like this
18:44 < sabdfl> so an ubuntu maintainer is "someone with a track record of consistent, regular and excellent contributions to ubuntu"
18:44 < sabdfl> "who has the ability to make changes to ubuntu packages without reference to other maintainers when outside of freeze"
18:44 < sabdfl> sound good?
18:44 < sabdfl> could be docs, design, code
18:44 < sivang> sabdfl : how do we quantify that ?
18:44 < hornbeck> sounds good to me
18:45 < sabdfl> sivang: once you are in you are in
18:45 < sabdfl> at least, all of the above makes sense for main
18:45 < mdz> sabdfl: the key distinction of a maintainer from the governance BOF was that they can make new releases of a package
18:45 < sabdfl> what about universe / multiverse?
18:45 < mdz> that distinguishes them from someone with commit access who is not yet a maintainer
18:45 < sabdfl> mdz: when we have commit without upload, that will be meaningful :-)
18:46 < mdz> true enough
18:46 < sabdfl> ok
18:46 < sabdfl> mako, could you draw up a draft process
18:47 < sabdfl> using bugzilla
18:47 < sabdfl> how someone would flag a contribution for review
18:47 < sabdfl> and the commitment we make to that pipeline
18:47 < sabdfl> also, we need to discuss a test of knowledge of packaging policy
18:47 < sabdfl> i think that's importand for -doc and -dev teams 
18:47 < sabdfl> what's the best way to administer such a test?
18:47  * mako nods to sabdfl 
18:48 < sabdfl> mdz, kamion?
18:48 < mdz> that's the NM problem
18:48 < mako> sabdfl: i think the best test is just doing it
18:48 < Kamion> I'd rather the test be based on what people have produced
18:48 < T-Bone> heh, indeed
18:48 < mdz> if there were a straightforward solution, NM wouldn't be such a mess :-)
18:48 < Kamion> heh, mako> snap
18:48 < sabdfl> agreed, past product is essential
18:49 < sabdfl> but it's also useful to know if someone can actually give the right answer immediately without reference to the docs
18:49 < Kamion> you can't really test that, though, not without being in the same room
18:49 < mdz> having immediate recall is not all that important
18:49 < mako> the point is, if you have producing debs for debian for the last 4 years, ubuntu for the last 4 months, there is no need to ask you 50 questions on packing :)
18:49 < sabdfl> what about a telephone interview, answering 10 questions out of a possible 200?
18:49 < mdz> it lets you work faster, but not more effectively
18:49 < mako> sabdfl: i don't think that's important at all
18:49 < mdz> I find that a far better indication of the quality of someone's work is that they know when to look in the docs or ask questions
18:49 < Kamion> sabdfl: I'd much rather that somebody knew where to look in the docs than that they made up answers without looking
18:49 < sabdfl> mako: we don't want to tell people to go somewhere else for 4 years
18:49 < mako> sabdfl: in fact, knowing when to look at the docs
18:50 < T-Bone> sabdfl: telephone interview implies that the candidate is fluent in its interviewer language, too
18:50 < mako> sabdfl: that was an example of an overqualified applicatoin, not a suggestion for where the bar should be
18:50 < sivang> sabdfl : this is the exact feeling I've been getting :(
18:50 < sabdfl> Kamion: if they make up the answers, they are unlikely to get them right, ad they fail the test
18:50 < Kamion> sabdfl: the Debian NM "answer enormous numbers of arbitrary questions with no relevance to your work" is one of its biggest flaws
18:50 < mako> Kamion: AOL
18:50 < sabdfl> Kamion: agreed, and tb/cc can see past that
18:50 < Kamion> sabdfl: if the questions were relevant to their work, then the answers would already be demonstrably part of the work they've produced
18:50 < sabdfl> but i still think we should know that a maintainer, doc or dev, has really read and taken on board those documents
18:51 < Kamion> not to mention, experienced developers look up the documentation all the time
18:51 < sabdfl> sure
18:51 < Kamion> it's simply not a good use of brain cells to memorise them
18:51 < mdz> agreed
18:51  * mako nods
18:51 < sabdfl> and a reasonable answer might be "hell yes, i know that's in plicy under this section, i can't quite remember if it's this dir or that dir"
18:51 < mako> if you haven't read policy, you make policy mistakes
18:51 < Henri1> A telephone interview doesn't have to be standard questions, but could just rely on the interviewers judgement.
18:51 < Kamion> ok, if that's to be considered an acceptable answer, then fine
18:51 < sabdfl> but i feel strongly that an expectation of study and test is part of the process, if a small part
18:51 < sivang> sabdfl : do we have an ubuntu policy already? or are we reverting to debia's ?
18:52 < T-Bone> Henri1: still, there's the problem of language fluency
18:52 < sabdfl> T-Bone: we would accommodate that
18:52 < sivang> you could just being thoughtful for people who's english not their native tounge.
18:52 < mako> sabdfl: i'm worried that it is in danger of repliucating the parts of NM i like are most flawed
18:52 < sabdfl> sivang: eloquently put
18:52 < Kamion> it inevitably does colour an interviewer's judgement
18:52 < sivang> wait more for the answer, guide the person if he's on the right track
18:52 < sabdfl> :-)
18:53 < T-Bone> sabdfl: i honestly wonder how ;) Besides, people might not necessarily feel cumfortable in a telephone interview, though being potentially very good packagers...
18:53 < sabdfl> irc
18:53 < Henri1> People have to communicate to submit patches anyway
18:53 < mdz> where possible, we should match candidates with mentors who can converse with them in the language where they are most comfortable
18:53 < Kamion> IRC interviews are much superior to telephone interviews for our purposes
18:53 < sabdfl> yes
18:53 < T-Bone> right
18:53 < Henri1> agree IRC sounds good
18:53 < sabdfl> ok, i think we're on the same basic track
18:54 < T-Bone> Henri1: it's much more easier to _write_ in a foreign language than to speak it fluently; for you have _time_ to consider what you're writing
18:54 < Henri1> For most people :)  
18:54 < T-Bone> and writings don't suffer from incomprehensible accents ;^)
18:54 < sabdfl> people will start by submitting patches, for review, managed in the bts
18:55 < sabdfl> they willkeep trak of actual work done
18:55 < mako> i think there are some very nice things we can do in an irc interview and it's worth following up .. but i still don't really like the idea of expecting peopel to memorize policy and be tested.. 
18:55 < sparkes> T-Bone, as someone with a strong accent I second that ;-)
18:55 < sabdfl> they will progress to the point they want to be considered as a maintainer
18:56 < sabdfl> they will understand that they will be tested, in an appropriate communications medium, on policy
18:56 < sabdfl> mako, i think it's vital people see it as a real test of knowledge
18:56 < sabdfl> you can be brilliant, and still clueless
18:56 < Kamion> mako: we can leave the extent of the test up to the judgement of the tester, I think
18:56 < T-Bone> absolutely right
18:56 < Kamion> don't think the CC needs to prescribe that just yet
18:56 -!- lamont [~lamont@mix.mmjgroup.com] has joined #ubuntu-meeting
18:56 < sabdfl> we'll have fast-track for people who can justify it
18:57 < sabdfl> dd's, upstreams-not-on-crack
18:57 < T-Bone> lol
18:57 < Henri1> An open book IRC test, where people have a chance to look stuff up
18:57 < sabdfl> judge's decision is final no correspondence will be entered into
18:57 < Kamion> above all, don't waste people's time when they're clearly good, and don't waste our time on people who are clearly hopeless :-)
18:57 < sabdfl> yes
18:57 < sabdfl> we should NOT promise that anybody can be a maintainer
18:57  * mako nods
18:58 < sabdfl> i won't be afraid to decline an application, i'll ask mdz to do the same
18:58 < T-Bone> sounds good
18:58 < hornbeck> thats the way it should be
18:58 < sivang> Again I am still puzzled how we can quantify the issue, especially for doc writers.
18:58 < mako> sabdfl: right, i see the argument for the test. i won't block consensus on it or anything but i'm not wild about it either, that's it
18:58 < mdz> the trick is to decline in a way that doesn't discourage improvement and re-submission
18:58 < sabdfl> sivang, we cant, but it's in our interests to try to build a healthy community of good people
18:59 < sabdfl> mako: let's see how it goes and tweak process based on experience
18:59 < sabdfl> ok, for a complete newbie, i expect the process to take... how long?
18:59 < sabdfl> 4-12 months depending on ability?
19:00 < sivang> that;s the question I was after..:)
19:00 < sabdfl> Kamion, elmo, mdz?
19:00 < mdz> hard to say
19:00  * Kamion isn't sure "complete newbie" is a useful place to start, it covers a multitude of sind
19:00 < Kamion> sins
19:00 < T-Bone> right
19:00 < sivang> I'll give myself as an example,
19:01 < sabdfl> ok, say someone who is a fast learner and puts in the time, knows linux well but not ubuntu or debian
19:01 < Kamion> somebody who can code but doesn't know anything about Ubuntu? couple of months
19:01 < mdz> sabdfl: a complete newbie to the process, or a complete newbie to Debian packaging?
19:01 < mdz> hmm
19:01 < Kamion> somebody who already has a good working knowledge of Linux and puts in the time? a month or so
19:01 < sabdfl> ok, we'll just have to find out
19:01  * asw offers self as test case.  me too.
19:01 < sivang> Knowing some Debian and linux, knowing how to code
19:01 < Kamion> but this is all finger-in-the-air made-up numbers :-)
19:01 < sabdfl> ok
19:01 < mdz> it's much more a factor of their attitude and commitment than the time
19:01 < sabdfl> ok
19:02 < sivang> having troubles with packaging though,
19:02 < T-Bone> sabdfl: if that's just about "learning packaging practices", (someone who's definitely not a newbie then), i'd say that 1 month is a max
19:02 < mdz> I know people who, even though they are completely ignorant of Debian packaging, I would trust them to begin work immediately, because I know that where they don't know the answer, they would seek it out
19:02 < sabdfl> it will be hard to say no to some enthusiastic guys, but mdz is right, it's more a question of deferrment till the level of quality is right
19:02 < DacInBC> here's another example: long time programmer, linux experience, no debian or ubuntu experience
19:02 < mako> mdz: yesyesyes
19:02 < Kamion> (took me about six months from starting to mess about with Debian packages to even applying, and that wasn't because I was put off by the process; admittedly I was doing finals at the time)
19:02 < mdz> that is the kind of quality that I look for
19:02 < sivang> sabdfl : meaning I should not ask, until i have _exhusted_ all other resources?
19:03 < mako> mdz: right, me too
19:03 < sabdfl> all other resources?
19:03 < sivang> docs,howtos,
19:03 < asw> I've used debian for years and GNU/Linux since forever but I thought package maintainers were some kind of gods... 
19:03 < sivang> mailing lists (debian)
19:03 < sivang> etc
19:03 < Kamion> sivang: there's no sense wasting your time when you're clearly stuck and need guidance, but at the same time you shouldn't expect other people to read you the documentation
19:03 < sabdfl> no, ask on -devel
19:03 < sabdfl> but read whatever you are pointed to
19:03 < sivang> Kamion : I wasn't expecting that. Just had time where I dind't know _what_ the docs are 
19:04 < sabdfl> Kamion: snap
19:04 < sivang> i mena, where to read
19:04 < Kamion> sivang: certainly 'tis fair to ask for pointers
19:04 < sivang> I mean, going over /doc at debian's sure has lots of inof,
19:04 < sabdfl> ok, another thing we could do is publish a maintainers reading list :-)
19:04 < sivang> info
19:04 < mdz> in general, if I answer with a google URL which finds you the answer with some obvious keywords, you should have searched first :-)
19:04 < sabdfl> ok
19:04 < sabdfl> mako, could you also put together a set of url's to relevant docs for new maintainers?
19:05 < sabdfl> hornbeck: this could also be a useful focus for the -doc team
19:05 < mako> sabdfl: yes
19:05 < asw> sabdfl, all: I think keeping an up-to-date reading list on the wiki is a great idea.  
19:05 < sivang> mdz : ahh, I agree. I would contribute this to an overwhelmning enthusiasm. I am working to tame this , I think you've already felt that :)
19:05 < sabdfl> great
19:05 < mako> if the doc team wants it, that's be great
19:05 < mako> my plate is brimming already :)
19:05 < hornbeck> sabdfl: putting together some maintainer guides?
19:05 < mako> hornbeck: yeah, we can talk after the meeting about it
19:05 < sabdfl> hornbeck: yes
19:05 < hornbeck> sabdfl: or pointing to them
19:05 < sivang> mako : that'll be great
19:05  * mako nods to sivang 
19:06 < hornbeck> mako: will do
19:06 < sabdfl> hornbeck: start with pointing, then write better ones?
19:06 < sabdfl> i *think* that takes us to the masters-of-the-universe discussion
19:06 < sivang> mdz : I apologize hereby for all those link questions :)
19:06 < hornbeck> sabdfl: sounds great
19:06 -!- enrico [~enrico@enrico.developer.debian] has joined #ubuntu-meeting
19:06 < mdz> sivang: :-)
19:06 < mako> enrico: ciao
19:06 < enrico> hello!
19:06 < sabdfl> let me outline the goals:
19:07 < sabdfl>  - the core team is focused on main
19:07 < sabdfl>  - universe and multiverse for warty were largely just a frozen snapshot
19:07 < sabdfl>    (with a bit of a nudge to build)
19:07 < sabdfl>  - for hoary, we want a process where the community can garden universe and multiverse
19:08 < sabdfl>   - mainly focused at sync from debian and other sources
19:08 < sabdfl>  - aimed at closing rc bugs before the release, during the freeze
19:08 < sabdfl> but this could be expanded to include:
19:09 < sabdfl>  - uploads of brand new packages that don't exist elsewhere
19:09 < sabdfl>  - uploads of fixes that are better than a sync to sid
19:09 < sabdfl> phew
19:09 < sabdfl> comments, thoughts, volunteers?
19:09 < elmo> bear in mind that gardening of universe increases the merge load
19:09 < mdz> sounds about right
19:09 -!- piller [~piller@piller64.sns.ornl.gov] has joined #ubuntu-meeting
19:09 < mdz> elmo: gardening includes  merging :-)
19:09 < pitti> As I already said on the ML, I think it would be good to focus primarily on sid
19:09 < hornbeck> sabdfl: are you looking for a few people to sit for request and be the ones who work through them?
19:09 < elmo> okay, as long as that's clear (to the gardeners
19:10 < pitti> having sid packages will ease maintenance in the long run
19:10 < asw> sabdfl: you know I'd like to do this: "uploads of brand new packages that don't exist elsewhere"
19:10 < Kamion> particularly for uploads of brand new packages, I would like some (not necessarily all) of the mastersoftheuniverse to take responsibility for pushing what we do back to Debian, where appropriate
19:10 < pitti> Kamion: +1 :-)
19:10 < sabdfl> hornbeck: i would like the outcome of this discussion to be a process that can run itself largely without input from the core team
19:10 < mako> Kamion: ++
19:10 < sabdfl> it would be a major responsibility in that regard
19:10 < DacInBC> sabdfl: Same here on the new packages, I want to develop some
19:10 < hornbeck> sabdfl: alright
19:10 < sivang> anyway, I have to go now people, I hope mako would summerize it all
19:10 < pitti> a Master of the Universe should be a DD in all cases
19:10 < sivang> mako : :)
19:10 < mako> sivang: i will
19:10 < Kamion> this isn't to say that people can't do work directly in hoary/universe, and there will be people who are interested who aren't Debian developers, and I think that's fair
19:10 < asw> I think the "universe" could be a gentle path to becoming an ubuntu maintainer.  is that the idea? 
19:10 < Kamion> pitti: I wouldn't go that far, although it depends what "Master" is
19:10 < pitti> even if a package is not in Sid, being a DD ensures at least a minimal quality standard on audit
19:10 < sabdfl> asw: yes
19:11 < asw> kamion: absolutely (re pushing back to debian)
19:11 < mako> pitti: not necessarily
19:11 < pitti> Kamion: if a MOU wants to sponsor uploads to Debian, it will be good if he is a DD
19:11 < lamont> pitti: MOTU should not require DD-hood
19:11 < Kamion> pitti: there need to be some people taking responsibility for it, but it doesn't have to be all of them
19:11 < pitti> The problem is, when we play around with our own universe only, the merging problem will aggravate badly over time
19:11 < sabdfl> ubuntu is not a subset of debian
19:11 < lamont> pitti: being a debian developer ensures that you can write lengthy answers to arcane questions.
19:12 < lamont> it says nothing about package quality
19:12 < pitti> lamont: :-)
19:12 < mdz> we can make it very easy for Debian to incorporate our work
19:12 < mdz> but we cannot do Debian's work for them
19:12 < lamont> mdz ++
19:12 < pitti> well, it's the same as a driver's license. Most drivers don't behave well anyway, but at least they (should) know what "good behavior" is
19:12 < Kamion> mdz: I'd like us to be doing active liaison
19:13 < mdz> Kamion: agreed, I am saying that we should not be doing package uploads as part of that process
19:13 < Kamion> rather than just "here's a repository of stuff"
19:13 < mako> Kamion: i think it's very important
19:13 < mako> mdz: no
19:13 < pitti> lamont: if I look at the packages my applicants presented me, it does make a difference to be a DD
19:13 < mako> mdz: as in, i agree
19:13 < Kamion> mdz: s/doing/requiring/ and I'd agree
19:13 < Kamion> I think it's a useful optional step, and it will ease our merge load in the long run
19:13 < pitti> I think pointing "Debian" (whoever that is) to a repo of stuff won't do anything
19:14 < pitti> there's nobody in Debian who goes around and collects packages
19:14 < Kamion> also if we do active liaison we increase the likelihood that Debian will take our packages rather than some other ones, further simplifying the merge load
19:14 < pitti> Debian packages need a maintainer and they must be pushed into Debian, not pulled
19:14 < mdz> I agree that active liaison is beneficial and appropriate
19:14 < Kamion> if we don't do that, we're going to run into the situation where we have to choose between the packaging in Debian and the packaging in Ubuntu
19:14 < Kamion> and version number / upgrade problems etc. will ensue
19:15 < pitti> so we shouldn't enforce it, but encourage?
19:15 < mdz> but I do not feel that uploading Ubuntu packages to Debian is appropriate, unless the Ubuntu maintainer is also a Debian maintainer and will fulfill the duties of that role
19:15 < Kamion> mdz: that's why I said "responsibility" rather than anything else
19:15 < pitti> mdz: if he is not willing to maintain the package, it is useless anyway
19:15 < mdz> I do not want a Debian developer to sponsor uploads of a bunch of Ubuntu packages without anyone taking responsibility for them in Debian
19:15 < pitti> IMHO we should avoid the situation that many people dump packages into universe and does not care about them any more
19:16 < pitti> so they need a maintainer anyway
19:16 < mdz> yes, an Ubuntu maintainer
19:16 < mdz> but that person is not necessarily a Debian maintainer, and that will only become more common as time goes on
19:16 < sivang> so basically, people maintaining universe would have to be DD first?
19:16 < pitti> that can as well be the Debian maintainer, it's just another name for the same thing
19:16 < Kamion> let's try to avoid the situation where there are two entirely separate packagings of libfoo sharing the same version number space.
19:16 < sabdfl> sivang: no
19:16 < mdz> sivang: absolutely not
19:16 < asw> mdz: my understanding would be that a person could be an ubuntu "master of the universe" and NOT a DD.  They could not push to debian then.  However, it would be the intention (in the longer run?) of most Ubuntu Master of the universe to become Debian maintainers. 
19:16 < Kamion> we can do that by monitoring Debian wnpp and pointing out our packaging to people who post intent-to-package notices
19:16 < sabdfl> Kamion: i'd like to think that if someone in debian wants libfoo, they will open a line of communication to people who have done that work
19:16 < pitti> asw: ++
19:17 < sabdfl> and figure it out reasonably
19:17 < mdz> asw: my feeling is that Debian maintainers and Ubuntu maintainers are two groups which have intersection
19:17 < mdz> a relationship with one does not imply a relationship with the other
19:17 < Kamion> sabdfl: it's not a reasonable expectation that somebody in Debian should have to look through the Ubuntu archive before making a change in Debian
19:17 -!- sivang [~sivan@box79162.elkhouse.de] has quit ["("will catch the summery, bye")"]
19:17 < mdz> Ubuntu maintainers who are not Debian maintainer must not be second-class
19:17 < lamont> Kamion: for new packages
19:17 < pitti> but Ubuntu maintainers can have their debian packages sponsored by a MOTU, they don't need to be DD themselves
19:17 < Kamion> sabdfl: that's why I think active liaison is appropriate, monitoring the Debian new-packages list
19:17 < asw> mdz: but I'm confused because there seems to be another group "Master of the universe" kind of a junior Ubuntu maintainer with fewer priv.
19:18 < mako> i'm with Kamion on this
19:18 < mdz> asw: approximately, yes. but the same principle applies
19:18 < sabdfl> asw: in talking about the management of universe
19:19 < sabdfl> we want to have a core team that manages it - the masters
19:19 < sabdfl> but also a team of people who contribute to it
19:19 < sabdfl> they would be like "maintainers in universe"
19:19 < sabdfl> they can contribute uploads etc
19:19 < Kamion> sabdfl: it's in our own interests to do this, because otherwise eventually upgrades from Debian will get more and more difficult if there are radically different packagings of stuff in universe sharing the same version number space
19:19 < sabdfl> and the universe team gets to decide what goes in, and what does not
19:19 < pitti> sabdfl: shall they be able to upload  on their own?
19:20 < pitti> okay, that answers the question
19:20 < Kamion> pitti: masters of the universe definitely have to
19:20 < sabdfl> Kamion: we will always review the options and choose the better package
19:20 -!- AberMatt [~cxv@clarlp1mrm04.clar.aber.ac.uk] has quit [Read error: 232 (Connection reset by peer)]
19:20 < pitti> Kamion: no, I mean the contributors (the maintainers of the u)
19:20 < asw> kamion: I think it will be easier if you train "maintainers in universe" then as they get good they will become DDs ... potential for gentler curve... 
19:20 < Kamion> pitti: I think it would depend, might be different levels
19:21 < sabdfl> the universe process is still uncertain
19:21 < sabdfl> but i think we should leave it as flexible and open as possible
19:22 < sabdfl> our default option should always be to look to see if there's a debian package for something
19:22 < Kamion> do we have a set of people who are obvious candidates to coalesce into a core team?
19:22 < sabdfl> but if we have someone who wants to do uploads to ubuntu with improvements, and the universe team likes it, then we will accept them
19:23 < sabdfl> Kamion: not yet
19:23 < asw> so the structure is: cc/tb for "main" are roughly equiv. to Master's of Universe for "universe/multiverse"
19:23 < sabdfl> asw: no
19:23 < sabdfl> the universe is still part of the community, and still must work according to the policies of the tb
19:23 < Kamion> cc/tb are for Ubuntu
19:24 < Kamion> as a whole
19:24 < sabdfl> but the universe team gets to figure out how best to implement that within the universe
19:24 < sabdfl> the primary focus of this, once again, is post-freeze
19:24 < pitti> sounds like a good compromise
19:25 < sabdfl> when we freeze hoary, and start working on main, we don't want universe to stagnate as much
19:25 < sabdfl> we want to get new point releases, perhaps new packaging tweaks
19:25 < sabdfl> and we want the "nudge to build" stuff taken care of by that team
19:25 < sabdfl> so universe is useful throughout the release process
19:25  * mdz gasps at the phrase "point releases"
19:25 < mdz> oh, you meant upstream point releases
19:25 < sabdfl> not of the distro :-)
19:25  * Kamion chuckles
19:26 < sabdfl> say, something 2.1.2 is in universe and there is a 2.1.3 release
19:26 < sabdfl> the universe team decides whether or not that makes it in
19:26 < Kamion> presumably we have to start accepting bug reports on universe, and assigning them to the masters or whoever's appropriate
19:26 < mdz> a good entry level skill set for universe gardening is being able to fetch source packages from Debian, build and test them on Ubuntu
19:26 < sabdfl> right
19:26 < Kamion> are we going to attempt to do that in bugzilla?
19:26 < mdz> we can fairly easily pick up candidates from the mailing list for that
19:26 < sabdfl> Kamion: i don't know
19:26 < mako> mdz: sure
19:26 < mdz> I've been answering folks who ask for new stuff in universe to do exactly that
19:27 < mdz> s/to do/by asking that they do/
19:27 < Kamion> mostly worried about the component drop-down setting daniels' dialup on fire :-)
19:27 < sabdfl> :-)
19:27 < mdz> daniels has DSL now, don't pay him any mind
19:27  * Kamion makes a note to upgrade his DSL to cope with the component list then
19:28 < sabdfl> i *think* we'll have good infrastructure by  the hoary release
19:28 < mdz> I think lamont is the most bandwidth-starved now
19:28 < sabdfl> that will be dialup-safe
19:28 < mdz> sabdfl: I'm pretty strongly against tracking universe bugs in bugzilla
19:28 < mdz> at least, in the same bugzilla where we track main bugs
19:28 < sabdfl> mdz: agreed
19:28 < sabdfl> either a second bugzilla, or something else
19:29 < mdz> works for me
19:29 < sabdfl> ok
19:29  * asw thinking slowly, so, it's: cc/tb > Ubuntu Main Maintainers >= Masters of Universe > Ubuntu Universe Maintainers... 
19:30 < mdz> asw: it's a hierarchy more so than an inequality
19:30 < sabdfl> asw: yes, that puts it nicely into focus
19:30 < asw> mdz: that's helpful re. skills required.  (fetching source, build test...) 
19:30 < sabdfl> MOTU should also be able to take a sane view on the benefits of an update vs the risks
19:31 < asw> I like the name "gardners of Universe" ... 
19:31 < sabdfl> and be able to review an update and assess whether or not it is likely to cause breakage elesewhere
19:31 < sabdfl> ok, don't want this to turn into a much longer meeting
19:31 < asw> MOTU = MASTER or MAINTAINER 
19:32 -!- johnlevin [~johnl@dsl-80-42-68-60.access.uk.tiscali.com] has quit ["Leaving"]
19:32 < sabdfl> i'll draft something that outlines this and send it to -devel and -user
19:32 < sabdfl> also, publish on the site
19:32 < mdz> need to discuss the doc team still
19:32 < Kamion> asw: master
19:32 < hornbeck> mdz: please :-)
19:32 < mdz> hornbeck, plovs: still here?
19:32 < elmo> I HAVE THE POWER
19:32 < elmo> sorry, carton-flashbacks
19:32 < mdz> BY THE POWER OF GREYSKULL
19:33 < T-Bone> lol
19:33 < sabdfl> ok
19:33 < asw> kamion: thanks. I definitely nominate the term GOTU (Gardner of the Universe) for the lesser role. 
19:33 < sabdfl> next up
19:33 < sabdfl> doc team?
19:33 < hornbeck> yes
19:34 < sabdfl> there's been some excellent work, thank you guys
19:34 < mdz> agreed, kudos
19:34 < sabdfl> sorry for the imposed wiki switch
19:34 < hornbeck> :-)
19:34 < sabdfl> should have happened before release
19:34 < Kamion> asw: doesn't have the cartoon history to the name though :-)
19:35 < sabdfl> nonetheless, we are testing a conversion script as we speak
19:35 < sabdfl> we should have it all converted tonight, europe time
19:35 < hornbeck> nice
19:35 < sabdfl> when we start, we will lock the old wiki
19:35 < mdz> we appreciate your patience during the transition; I truly believe it will be worthwhile in the long run
19:35 < sabdfl> and the new one won't be widely announced till we've cleaned up the pieces of the conversion
19:35 < hornbeck> sabdfl: we are all ready to get at it
19:35 < sabdfl> ok
19:36 < sabdfl> for the moment, pick the format that works best for you
19:36 -!- enrico is now known as enrico_dinner
19:36 < sabdfl> the zwiki maintainer has been fantastic
19:36 < sabdfl> and has implemented moin 
19:36 < sabdfl> i think completely
19:36 < hornbeck> yes he has been helpful in answering questions for us
19:36 < mdz> sabdfl: does he scan the WikiWishlist?
19:36 < sabdfl> ok
19:36 < sabdfl> yes
19:36 < mdz> great
19:37 < sabdfl> he's actually helping with the setup etc
19:37 < sabdfl> with stevea
19:37 < sabdfl> so that should all be done soon
19:37 -!- DacInBC [~darren@S0106000094c6219f.ok.shawcable.net] has left #ubuntu-meeting []
19:37 < sabdfl> there are still some glitches relating to authentication (logging in)
19:37 < sabdfl> and also to tracking changes, but we will get them all sorted out
19:37 < hornbeck> good, that seems to be the biggest problem right now
19:38 < sabdfl> ALL members of the community can create pages anywhere in the site
19:38 < sabdfl> please use that very carefully
19:38 < sabdfl> i'd prefer to keep all brainstorming in the wiki
19:38 < sabdfl> then move content over to the main site
19:38 < hornbeck> sounds good
19:39 < sabdfl> since the main site uses ReST and StructuredText, it's beneficial to do the wiki the same way
19:39 < sabdfl> for the conversion later
19:39 < mdz> we should certainly convert the FAQs and How-Tos to the more structured plone documents
19:39 < mdz> and maintain those outside of the wiki
19:39 < hornbeck> mdz: that seems a problem right now with doc team
19:39 < sabdfl> hmm.. i wonder how hard a command line moin->ReST tool would be?
19:40 < mdz> hornbeck: in what way?
19:40 < hornbeck> mdz: I will address in a second
19:40 < mdz> ReST is crack
19:40 < mako> sabdfl: perhaps not trivial
19:40 -!- pitti [~martin@195.227.105.180] has quit ["Have a nice day!"]
19:40 < mako> mdz: i love ReST :)
19:40 < sabdfl> hornbeck: go ahead
19:40 < asw> mdz: is crack good or bad? 
19:40 < elmo> asw: drugs bad mmk
19:40 < hornbeck> I really wish more doc guys could have been here, first of all
19:41  * sparkes sparkes is here, just
19:41 < hornbeck> good to see you sparkes
19:41 < sabdfl> enrico_dinner: oh
19:41 < hornbeck> sabdfl: we seem to be in need of some guidence
19:41 < sabdfl> ok
19:41 < amu> moins
19:42 < hornbeck> everyone on the list seems to be infighting about which way to push forward
19:42 < sabdfl> ok, what options have been put out there?
19:42 < sparkes> I don't think infighting is the right word but we do have several options out there at the moment
19:42 < hornbeck> well alot seem to want to go straight wiki for almost everything, while others wish to move alot off wiki
19:42 < hornbeck> that is one
19:43 < sparkes> hornbeck, true
19:43 < hornbeck> another is whether or not to appoint a leadership role to push us in directions and to also talk between doc team and devs
19:43 < hornbeck> there seems to be one on one conversations between doc people and devs but it is not getting back to doc people
19:44 < hornbeck> I think someone is needed to rally the doc people in a direction
19:44 < sabdfl> ok
19:44 < hornbeck> I hope that is all right
19:44 < sparkes> there is also the issues of what licence is good for ubuntu and upstream
19:44 < hornbeck> yes
19:45 < asw> I think forcing people to check two places the "real" FAQ (more nicely formatted) and the Wiki FAQ (more current) is a recipe for problems if not disaster. If ReST lets us maintain the FAQ in the Wiki I think that would be very, very nice.  But I don't know if it's practical.   
19:45 < sabdfl> that's an easy one to solve
19:45 < sabdfl> the faq's should go straight into the faq section
19:45 < sabdfl> it's designed for it
19:45 < hornbeck> I really feel we need a leadership role in the doc team to over see what is happening and to stop arguements
19:45 < asw> sabdfl: agreed. 
19:45 < sabdfl> and i've no problem with people putting new faq's straight in
19:45 < mdz> I think they should be reviewed by the doc team
19:46 < mdz> using the facility provided by plone
19:46 < sabdfl> hornbeck: having an leader does not stop arguments
19:46 < asw> mdz: does PLONE do revision control the doc team can check changes? Possibly ban users if they've been putting in Bogus answers to faqs?
19:46 < sabdfl> asw: no
19:46 < hornbeck> but that person can step in and push for a certain direction or have a final say, or take to CC and such
19:47 < sabdfl> i've had some one on one conversations with different doc team members
19:47 < asw> bummer. revision control is that's what makes the moinmoin wiki stuff work.  
19:47 < sabdfl> enrico, hornbeck, sivang
19:47 < sabdfl> asw: there is a zope-based revision management
19:47 < sabdfl> but i' not sure how usable it is
19:48 < mdz> asw: plone provides a framework where people can write new entries and submit them for review
19:48 < mdz> asw: and then they can be published when they have been reviewed
19:48 < asw> sabdfl: yeah I haven't followed zope too closefly I know too many OpenACS/ACS guys... 
19:48 < mako> but that's workflow management, not revision control
19:48 < mdz> but it is not as straightforward to manage changes to existing documents
19:48 < sabdfl> once published, i think they can be edited and immediately published
19:49 < sabdfl> and we don't have revision control that's as effective from that point onwards
19:49 < mdz> right
19:49 < sabdfl> we could create a group of trusted users who can edit the site
19:49 < sabdfl> and let everyone else work in the wiki
19:49 < mdz> but zwiki has a basic revision control facility like moin's
19:49 < hornbeck> sabdfl: if not a leadership role a core type team of doc people who make choices
19:49 < asw> sabdfl: so I just don't get it.  Why would you use a wiki that doesn't give you revision control (like wikipedia or moinmoin)
19:49 < mdz> asw: the wiki does give you revision control
19:50 < sabdfl> i think it's worth trying to open up the site to the whole community to see what happens
19:50 < mdz> but the other parts of the site do not
19:50 < sabdfl> mdz: actually they do
19:50 < sabdfl> in the zope layer it stores every version of every object
19:50 < sabdfl> you can pack the db, and lose those
19:50 < sabdfl> and i think we will be doing that
19:50 < mdz> ok, not visiible in the ui presented to me
19:50 < sabdfl> i'm just not sure that plone exports the revisions as something useable
19:51 < mako> sabdfl: AFAIK it does not
19:51 < asw> mdz, sabdfl: so it's a matter of improving plone?  (that's do able I suppose...) 
19:51 < sabdfl> asw: not the optimal strategy
19:51 < mdz> asw: it would also be workable to continue to use the wiki as a staging area
19:52 < sabdfl> plone is big and hairy and built on zope2, which is bigger and hairier
19:52 < mdz> with the entire doc team behind it, things could be edited and moved into the FAQ much more quickly
19:52 < sabdfl> zope3 is now out, which is not backwards compatible
19:52 < sabdfl> the huge advantae of the new wiki is that the search will find data in the wiki
19:52 < sabdfl> as well as in the faq
19:53 < sabdfl> hornbeck: let's talk a bit further about leadership
19:53 < sabdfl> who have been the main contributors so far?
19:53 < hornbeck> sabdfl: in wiki or overall?
19:53 < sabdfl> overall
19:54 < hornbeck> sabdfl: the most vocal are myself, sivang, plovs, and now sparkes
19:54 < sabdfl> ok, what role has enrico played?
19:54 < hornbeck> BenEdwards is doing good stuff 
19:54 < sparkes> sabdfl, Also Ben 
19:54 < hornbeck> sabdfl: enrico, has poped in once in awhile
19:54 < mako> i've seen a bunch of enrico posts to the mailing list
19:55 < mako> with a lot of good stuff i thought.. although they didn't get a lot of reponse
19:56 < hornbeck> enrico, has posted four times on new list, with all very good ideas
19:56 < hornbeck> he does not seem to be very involved with everything though
19:56 < mako> hornbeck: and a bunch of times to -devel
19:56 < hornbeck> mako: true
19:56 < sabdfl> ok
19:56 < sabdfl> i've discussed with enrico having a "secretary"
19:57 < sabdfl> for the doc team
19:57 < sabdfl> someone to do 2-3 hours of work every day
19:57 < sabdfl> keeping the team focused and momentum going
19:57 < mako> like wiki gardening, etc?
19:57 < sabdfl> cleaning up the wiki etc
19:57 < hornbeck> that is what I am wanting to be in place
19:58 < sabdfl> hornbeck: is that what you are wanting to do?
19:58 < hornbeck> sabdfl: I would like to yes
19:59 < sabdfl> you have certainly been very visible in your contribution
20:00 < sabdfl> what needs to be done on a regular basis?
20:00 < hornbeck> for starters we need to round up the docs that we want to make solid for Hoary
20:01 < hornbeck> we also need to keep track of wiki
20:01 < hornbeck> need to start setting up solid areas for people to work in, and getting certain doc writers doing certain docs
20:01  * enrico_dinner lands here
20:01 -!- enrico_dinner is now known as enrico
20:01 < hornbeck> welcome back enrico
20:01 < enrico> catching up
20:01 < sabdfl> hi enrico, do you have scrollback?
20:02 < hornbeck> we are all kinda out there right now
20:02 < sabdfl> ok
20:02 < hornbeck> need someone to keep people on those task and do it in a way that is encouraging to them and to keep them happy
20:02 < enrico> sabdfl: I do, I caught up
20:02 < sabdfl> i definitely can see a role for a wiki gardener
20:02 < hornbeck> and to make sure are docs are able to go back upstream
20:03 < sabdfl> i can also see a role for a "core team" that is responsible for decisions on documentation
20:04 < sabdfl> how can we best organise this?
20:04 < enrico> I haven't been much active because I didn't know how much time I could commit from now on
20:04 < hornbeck> I think a solid doc team is as important as a solid dev team, because people will always look toward the docs and without solid easy to read docs they are lost
20:04 < sabdfl> so far i've only heard from hornbeck
20:04 < enrico> I don't like to take responsibility for things without knowing if I can commit to them
20:04 < enrico> sabdfl: heard about what?
20:04 < sabdfl> in this forum
20:05 < enrico> sivan was here, but it got too late and he needed to head home
20:05 < hornbeck> sabdfl: I think to organize this, we should at least set up a core team that can make decissions
20:05 -!- AberMatt [~cxv@clarlp1mrm04.clar.aber.ac.uk] has joined #ubuntu-meeting
20:05 < sabdfl> ok
20:05 < sabdfl> here are the big questions
20:05 < hornbeck> sabdfl: we also could use someone who is always going to be reliable
20:05 < sabdfl>  - how should doc budget be spent
20:06 < hornbeck> doc budget?
20:06 < sabdfl>  - how should appointments to that core team be made
20:06 < sabdfl>  - do we need to appoint a specific team leader
20:06 < hornbeck> I think yourself and main core team should appoint the doc core team
20:06 < sabdfl>  - do we in addition need a secretary, or should they be the same role
20:06 < enrico> There have been mails in the list that were cautious about having a team leader
20:06 < hornbeck> we have made ourselves known and they mostly know us by now
20:07 < sparkes> enrico, I think people wanted to adapt a wait and see attitude while the team was small
20:08 < sabdfl> that makes sense
20:08 < sabdfl> at the same time, this is largely volunteer effort
20:08 < enrico> I once wrote that at the beginning, the Ubuntu Code of Conduct can be a good enough leader
20:08 < hornbeck> sparkes: we are growing real fast on the list and to many random ideas are being thrown without peoples saying, lets do this
20:08 < enrico> Ben today posted something ismilar
20:08 < sabdfl> so i don't think a leader is going to be able to direct effort so much as help to coordinate
20:08 < mako> sabdfl: yes
20:09 < hornbeck> maybe it sould be said coordinater instead of leader
20:09 < hornbeck> seems the term leader is throughing people off
20:09 < enrico> hornbeck: we can see if just having a secretary that picks up and cleans the ideas thrown on the ground is enough for people to cherry pick them
20:09 < sparkes> hornbeck, ;-)
20:09 < asw> I'm listening.  Since I'm writing a book length project, and am (newly) maintaining some public faqs / communities ; I'm not sure what I have to contribute, yet. 
20:09 -!- silbs [~sbsm0084@host217-37-231-28.in-addr.btopenworld.com] has left #ubuntu-meeting []
20:09 < enrico> Although someone that tells when something is ready for release, for example, may be needed
20:10 < sparkes> enrico, that's probally a better idea for the short/medium term
20:10 < hornbeck> a secretary would be good
20:10 < hornbeck> someone who can step in and make decissions
20:10 < sabdfl> docs are generally best owned by one person
20:10 < hornbeck> that is what I would like to see
20:10  * plovs just walked in
20:10 < sabdfl> i mean "a document" not "all the docs"
20:11 < sabdfl> so  maybe we need to think of ledership of specific pieces of it
20:11 < hornbeck> sabdfl: the concensus is no on that point from the doc team
20:11 < sabdfl> for example, one person who is master of the faq's
20:11 < sabdfl> and one person who takes a lead on the installer guide
20:11 < sabdfl> etc
20:11 < sparkes> sabdfl, this was brought up on the docs list before to a mixed responce
20:12 < hornbeck> sabdfl: people hated that idea on the doc list
20:12  * sparkes believed docs should have maintainers
20:12 < sabdfl> ok
20:12 < sparkes> ;-) just to disagree with hornbeck again and make it look like we never aggree in public ;-)
20:12 < enrico> It also depends on how the work is made
20:12 < sabdfl> hornbeck: consensus?
20:13 < asw> I think that doc maintainers and over-all project leaders can be complementary'
20:13 < enrico> If things are "let's throw in", then nothing is needed
20:13 < enrico> Then, we should see if it leads to enough quality
20:13 < hornbeck> sabdfl: agreement
20:13 < enrico> well, IMO a good piece of documentation needs a bit of planning, like identify a target, describing it throughly, stating a goal
20:13 < sabdfl> i don't think that a doc maintainer means "this is my island get off it"
20:14 < sabdfl> i just think that a body of work like that needs a certain amount of consistent care
20:14 < enrico> And before release, there's a need for some quality assessment, and someone that says "ehy, this is good!  Let's check the commas and release it"
20:14 < sabdfl> and that while everyone whould be free to contribute
20:14 < sabdfl> it's still good to be able to say "xyz is our faq-master"
20:14 < sparkes> sabdfl, agreed
20:14 < enrico> But we can apply the "YouAintNeedingItYet" pattern and defer until such problems happen
20:15 < sabdfl> ok, let's start with this:
20:15 < enrico> (one point in which to introduce quality control is when one says what goes into Hoary, and that has a release deadline as well)
20:15 < sabdfl> the initial doc team is hornbeck, sparkes, plovs, enrico, ben, asw
20:16 < sabdfl> Henri1: would you  be interested in keeping an eye on docs from aa11y point of view?
20:16 < Henri1> Sure
20:16 < mako> did sivang have a hand in it?
20:16 < enrico> sabdfl: sivan?
20:16 < sabdfl> sivang too, didn't mean to leave anyone off who's contributed
20:16 < enrico> "aa11y" ?
20:16 < sabdfl> i will ask enrico to act as a secretary for the next few months while the team settles down
20:17  * enrico puts on the wiki gardener hat
20:17 < sabdfl> i'd like you each to find an area that you particularly care about and make that your showcase
20:17  * sparkes hands over the wiki gardner gloves
20:17 < Henri1> I guess I can just try to feed them aa11y stuff; or do you mean to look at all the docs from an accessibility point of view?
20:17 < sabdfl> i'd like this team to come back to the next cc meeting with a list of doc priorities that we should publish for new people who come along and want to help with docs
20:17 < enrico> sparkes: you're welcome to continue gardening
20:18 < sabdfl> Henri1: contribute as you see fit, low hanging fruit first
20:18 < enrico> ah!  Accessibility!
20:18 < sparkes> enrico, no these are bespoke secretary gloves I had hand made for the chief gardner ;-)
20:18 < Henri1> OK
20:18 < sabdfl> gardening is much more fun in teams
20:18 < enrico> sparkes: Wow!
20:18 < mako> :)
20:18 < asw> hornbeck has suggested a "Learning Ubuntu" O'Reilly style book. If it's an updated version of: http://www.oreilly.com/catalog/debian/chapter/book/  With an equally liberal license I would be an eager participant. It might also be nice if we take care to mark the differences with Debian so that a debian user coiuld use the book too.  but that might be awkward.  
20:18 < plovs> sabdfl, can somebody from upstream make a list of what they would like to see? Or it's just us?
20:19 < sabdfl> hornbeck: great idea
20:19 < sparkes> I would have prefered to use the debian user guide (progeny) but the concenus seems to be against taht one
20:19 < asw> horbeck: did I get your suggestion right? (you suggested Learning Redhat Linux as example I think.)
20:19 < sabdfl> you guys need to discuss it amongst yourselves and come up with the list
20:20 < sabdfl> i can add some layering of priorities
20:20 < sabdfl> but don't want to issue the list
20:20 < hornbeck> asw: yes
20:20 < hornbeck> sabdfl: thanks
20:20 < sabdfl> i'm just very grateful for your contribution, and my role here is to try to help you feel like your contribution is most effective
20:21  * mako nods
20:21 < asw> sparkes: if it's under a liberal license then we should build on it. (re debian user guide) I don't see why it would harm us to build and improve on what exists! 
20:21 < sabdfl> i'm happy to use the most liberal licence o'reilly will go with, which makes the content available for debian, but don't want you to do extra work on that account
20:21 < sparkes> asw, it's gpl
20:21  * enrico loves GPL documentation
20:22 < hornbeck> sparkes: we would have to rework that whole doc
20:22 < plovs> under what license is the wiki?
20:22 < hornbeck> sparkes: it would be easier to make that a different project
20:22 < enrico> plovs: good question: it should be made explicit
20:22 < sparkes> ok, hornbeck 
20:22 < asw> sabdfl. at least one of my acquaintances published with oreilly. I can talk with them but I don't want to step on anyones toes.  This is hornbeck's idea. 
20:22 < sparkes> plovs, this is something we need to sort out to stop probs later
20:22 < hornbeck> asw: find out as much as you can about what we need to do
20:23  * sparkes has an orielly published freind too
20:23 < hornbeck> I am willing to get as much help as I can
20:23  * enrico would also like to have a 'documentation' metapackage in the BTS
20:23  * hornbeck will have final edit though :-p
20:23 < plovs> do we have an ata for the new wiki? 
20:23 < enrico> Now that I have the secretary gloves, I can take care of it
20:23 < hornbeck> enrico: I agree
20:24 < hornbeck> enrico: can you get me some coffee ? :-)
20:24 < sparkes> lol
20:24  * enrico hands hornbeck some dark italian coffee
20:24 < hornbeck> nice
20:24 < hornbeck> you will be good at this job enrico
20:24  * enrico hugs hornbeck 
20:24 < sabdfl> easy guys
20:24 < hornbeck> nice, I like a secretary who's "hands on"
20:24  * asw oh boy... 
20:25 < sabdfl> here we go
20:25 < hornbeck> hehe
20:25 < enrico> Ok, two things I'm taking care of: wiki license and documentation metapackage
20:25 < sparkes> hornbeck, you don't want another human theme on our hands
20:25 < sabdfl> alright, that's me done here. let's review in a few months
20:25 < enrico> ...and hornback, of course ;)
20:25 < enrico> ehm, hornbeck, sorry
20:25 < sabdfl> worse and worse
20:25 < sabdfl> what have i done
20:26 < sabdfl> anyhow, workrave is screaming at me now
20:26 < hornbeck> created a monster
20:26 < plovs> nerds and secretaries don't mix
20:26 < sparkes> plovs, they do here ;-)
20:26 < mako> ok, i want to know if its possible to split the internal documentaiton issues and the stuff that the cc need sto do
20:26 < sabdfl> go to it and enjoy
20:26 < sabdfl> and thanks again
20:26 < mako> :)
20:26 < sabdfl> a big measure of your success will be the extent to which you can bring more guys into the team
20:27  * mako nods
20:27 < sabdfl> cheers guys
20:27 < enrico> sabdfl: bye!
20:27 < hornbeck> thanks
20:27 < sparkes> thanks all
20:27 -!- gruberman [~gruberman@h9n2fls35o294.telia.com] has quit ["(nexxai) looking at porn with your dad's girlfriend in the room is weird"]
20:28 < asw> later
20:29 -!- sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has left #ubuntu-meeting []
20:29 < hornbeck> doc guys I will do a write up for the mailing list and send in alittle while
20:29 < enrico> hornbeck: mako's making a summary
20:29 -!- vrln [~vrln@195.10.181.201] has left #ubuntu-meeting []
20:29 < hornbeck> enrico: thats cool than
20:30 < sparkes> afk bbl
20:30 < enrico> I'll cut from mako's summary and post in the list
20:30 < hornbeck> enrico: sounds good
20:30 < hornbeck> I am back off to work, I snuck out to be here
20:30 < hornbeck> :-)
20:30  * enrico skuck out of dinner
20:31 < plovs> hornbeck, thanks
20:31 < hornbeck> plovs: no problem
20:32 < plovs> btw just got a mail that we will have a lot of cleaning up to do after the wiki 'upgrade'
20:32 < hornbeck> yes we will
20:33 < plovs> the guy resposible is stevea  and he lives in #zwiki
20:33 -!- arunbhanu [~arun@bb220-255-42-190.singnet.com.sg] has left #ubuntu-meeting []
20:34 < Henri1> I guess that's the end of the meeting. We still didn't officially discuss setting up an Accessibility team.
20:36 < asw> Henril: as in section 508?
20:36 < Kamion> Henri1: hm, that was confusingly put on the agenda for the previous meeting?
20:37 < Henri1> It was skipped then as well, due to the release
20:37 < olafura> I watched a talk on the net about NX at the KDE conferece. They talked about it's itegration into KDE development. This brings an interesting option for Ubuntu. Because you support a release for 18 months and your developement model is supposed to be distribued.
20:38 < Kamion> Henri1: please make sure it's actually on the agenda for next meeting so that we remember it
20:38 -!- ctalkep [~ctalkep@212.21.138.21] has quit ["Linux suxz...:("]
20:38 < Kamion> sabdfl's gone so I don't think we can do it now
20:38 -!- martinald [~hm@martinalderson.plus.com] has quit [Read error: 104 (Connection reset by peer)]
20:39 < Henri1> Right, OK. I've got to get with the procedures :)  It was on the agenda a few days ago, before it got restructured
20:39 < Henri1> Anyway, no rush
20:39 < olafura> Hoary has a possible goal to have an NX support. But would it also be smart to have a machine to test things for those less adventures.
20:40 < enrico> Who was the bugzilla guy again?
20:40  * enrico wants to request the "documentation" metapackage
20:40 -!- jmchugh [~jmchugh@silenceisdefeat.org] has left #ubuntu-meeting []
20:40 < Henri1> I guess it needs CC approval to actually become a team, but there seems consensus that we want one.
20:40 < Kamion> Henri1: ah, whoops
20:40 < Kamion> Henri1: it doesn't need CC approval to start getting the people together and work out what you want to do
20:40 < Henri1> Heh, no worries :)
20:40 < Kamion> Henri1: if anything, it's better to have that in place early
20:41 < Kamion> enrico: file a bug on Websites/Bugzilla
20:41 < Henri1> Righ, and were doing that, so no problem#
20:41 < enrico> Kamion: thanks
20:41 < Kamion> Henri1: ok, good; if we're really blocking you, a special meeting may be possible, but I hope we're not
20:42 < Henri1> No, it was actually Luke who wondered why we weren't listed on the main Ubuntu page as a team
20:43 < Henri1> The reason is of course that it needs CC approval first, but again, no rush
20:48 -!- T-Bone [~varenet@T-Bone.developer.debian] has quit ["off"]
20:49 -!- gro [~gro@u212-239-167-206.adsl.pi.be] has left #ubuntu-meeting []
20:49 -!- Henri1 [~Henrik@henrik.gotadsl.co.uk] has left #ubuntu-meeting []
20:54 -!- Topic unset by mdz on #ubuntu-meeting
20:54 -!- Treenaks [martijn@facecrime.net] has joined #ubuntu-meeting
20:55 -!- Treenaks [martijn@facecrime.net] has left #ubuntu-meeting []
21:01 -!- funkytwig [~ben@cpc2-pool1-6-0-cust191.sot3.cable.ntl.com] has joined #ubuntu-meeting
21:01 < KragenSitaker> is there a way to find out when these meetings are scheduled more than a day in advance?
21:02 -!- enrico [~enrico@enrico.developer.debian] has quit ["Gotta go out"]
21:02 < Kamion> CC/TB meetings are alternate Tuesdays, but subscribe to the agenda wiki page
21:03 < KragenSitaker> thank you!