#Ubuntu-Meeting

Ubuntu-Meeting Log 2004-11-20

Topic: Shotgun Community Council meeting


05:11   mdz     CC meeting?
05:11   Kamion  here
05:12   Kamion  um, had forgotten about it
05:12   Kamion  we don't seem to have any agenda items
05:12   mdz     anything on the agenda?
05:12   Kamion  nothing
05:12   sabdfl  nothing that i saw
05:12   mdz     agenda on the wiki seems to be empty
05:12   sabdfl  sorry for being late
05:12   sabdfl  i checked this morning and it was just old stuff
05:12   Kamion  do we have AOB?
05:12   sabdfl  so made it blank
05:13   sabdfl  AOB?
05:13   Kamion  any other business (i.e. off-agenda)
05:13   sabdfl  not from me
05:13   mdz     yes
05:13   mdz     I'd like to talk about the maintainer process
05:13   sabdfl  hmm... maybe conference invitations to community members
05:13   mdz     lack thereof, at the moment
05:14   mdz     is someone expected to be working on community processes? jdub?
05:14   sabdfl  mdz: do we have a framework for maintainers whohave been appointed?
05:14   sabdfl  i think mako
05:14   sabdfl  he sms'd me to say his net was busted
05:14   sabdfl  he's trying to make another plan
05:14   mdz     oh
05:15   sabdfl  i would really like to get a community team going
05:15   sabdfl  in other words have a few maintainers who are not Canonical folk
05:15   mdz     we have a keyring for the archive, and a queue of folks who want to be considered
05:15   sabdfl  with full upload capability
05:15   mdz     the rest is documentation and procedures
05:16   mdz     when mako and I talked about this last, we were on the same page as to how it should work
05:16   sabdfl  ok
05:17   sabdfl  ah, the clocks have gone back, that's why my alarm didn't go
05:17   mdz     I also think it would be a good idea for someone on the community team to work with the doc team on a "how to get involved" document
05:18   mdz     the categories I have seen so far are "I have a suggestion for improving Ubuntu", "I have a problem with Ubuntu" and "I want to become an Ubuntu developer"
05:18   mdz     I wrote a document for the "I have a problem" case which walks through support and bug reporting basics
05:18   sabdfl  the MaintainerCandidates page has a few people
05:18   mako2   there is already a participate document
05:19   mdz     but i think it would be nice to have a very high-level document about how individuals can relate to the Ubuntu community
05:19   mako2   mdz: do you think it should be built on top of that?
05:19   sabdfl  are there any there who have strong credentials from existing open source work that would allow us to approve them immediately?
05:19   Kamion  also "when you *don't* need to be an Ubuntu developer in order to get your problem fixed"
05:19   mdz     mako2: possibly, I'm waiting for plone to give it to me so I can see
05:19   Kamion  thinking of the people who want to join just in order to get some theme added or whatever
05:19   sabdfl  http://www.ubuntulinux.org/community/participate/document_view
05:20   sabdfl  mako2: perhaps that just needs some more specifics
05:20   sabdfl  "become a maintainer" doesn't tell you where to start
05:20   sabdfl  just needs a link to the relevant process
05:20   mako2   right
05:20   Kamion  (is there any way we can get rid of those daft "/document_view" bits on the end of all the wiki URLs? the URLs work fine without them)
05:20   mdz     once the process is documented :-)
05:20   mdz     Kamion++
05:21   sabdfl  http://www.ubuntulinux.org/wiki/MaintainerCandidates
05:21   sabdfl  is there anyone on there that we would feel comfortable approving right away?
05:21   mdz     mako2: I'm thinking that it should have some very simple bullet points which link to more detailed documents
05:21   mdz     mako2: each aimed at a use case which already exists
05:22   mdz     so that a user who comes to the page who already knows what they want, can find the relevant interface
05:22   Kamion  Matthias Urlichs is a competent Debian guy, IIRC
05:22   mako2   mdz: i'm happy to help with that
05:22   sabdfl  i would be happy to approve some of the guys who have made great doc contributions already
05:22   mako2   Kamion: yes, we've been chatting a little bit offlist as wel
05:22   Kamion  Thibaut VARENE is the ia64 guy and should be straightforward to approve
05:22   mdz     his name is familiar, but I can't vouch personally
05:22   sabdfl  as long as they agree just to work on package documentation
05:23   daniels lamont can vouch for thibaut, IIRC
05:23   mako2   Kamion: he maintains some non-trivial python packages
05:23   mako2   python-docutils (RST)
05:23   mdz     elmo: do we have a public upload queue?
05:23   mako2   i can also vouch for thibaut
05:23   mako2   i was his AM in Debian so i've already gone through NM with him once
05:23   Kamion  oh, he's the gnutls/gcrypt maintainer
05:23   elmo    mdz: no - we're waiting on zope 3's ftpd getting fixed - I've just pinged SteveA about it
05:23   Kamion  $ grep-available -nsPackage 'Matthias Urlichs' | wc -l
05:23   Kamion  80
mdz blinks
05:24   sabdfl  gosh
05:24   sabdfl  that would be a yes then
05:24   elmo    yeah, smurf's competent IMO
05:24   Kamion  (quantity not implying quality or anything, but :-))
05:25   sabdfl  Kamion: why do I always find myself agreeing with you when you point out that sort of thing?
05:25   Kamion  I'm just such an agreeable guy
05:25   sabdfl  erm. but i'm not.
05:25   mdz     because of his sneaky tendency to be correct
05:25   mako2   yeah, but he also maintains some touch ones
05:25   sabdfl  ah. yes, that
05:25   mako2   i've been working with him this week on preparing the new upstream release of python-docutils
05:25   sabdfl  ok, let's take these one at a time, maybe that would be better
05:25   sabdfl  we still need a proper process for guys we don't know already
05:26   sabdfl  mako2, can we leave the process documentation in your hands, deliverable for the next cc meeting?
05:26   mdz     yes
05:26   mako2   yes
05:26   sabdfl  and mdz, can we handle both techboard and cc approvals today, do you have your tech board handy?
05:27   mako2   mdz: help me outline and check it,eh?
05:27   mdz     hm, I'll see
05:27   mdz     mako2: definitely
05:27   sabdfl  ok: thibaut varene, opinions?
05:28   mako2   i was his am in debian
05:28   sabdfl  already discussed?
05:28   mdz     (prodded Keybuk)
05:28   mako2   i passed him there with glowing recommendations and i would do it again here :)
05:28   mdz     sabdfl: mako and lamont both say good things, I've chatted with him and found him sane
05:28   sabdfl  how do we want to do this, require all cc members to say aye or nay?
05:28   Kamion  he's been sane when I've talked to him too; thibaut ack
05:29   sabdfl  ok, thibaut is in
05:29   Keybuk  evening
05:29   mdz     cheers
05:29   sabdfl  from a cc perspective, mdz, you make the call for tech board
05:29   sabdfl  hiya scott
05:29   sabdfl  sivan green
05:29   sabdfl  he's been very "present"
05:29   Kamion  sabdfl: I think requiring CC unanimity would be good until we have a clearer procedure
05:29   sabdfl  lot's of enthusiasm on the doc front
05:30   mako2   sivan has been working mostly on doc stuff up until now but is interested in working with a mentor towards other types of stuff
05:30   sabdfl  not much experience i don't think
05:30   sabdfl  a candidate for the full process?
05:30   pitti   I talk with him very often; he seems eager, but did not finish much up to now
05:30   mako2   he's been in contact with me directly several times a week about a number of things
05:30   mdz     mako and I talked a bit, and I think the full process can very nearly be condensed to a single bullet point
05:30   mdz     the key is that we can trust them to know their own limits
05:30   mako2   i gather that sivan would be happy with the fully process
05:30   mako2   right
05:31   pitti   I think so, too
05:31   sabdfl  mdz: can you turn that into something a little less existential?
05:31   mdz     if we can be confident that someone will ask before entering unknown waters
05:31   pitti   but he should finish at least a small coding project before he starts the full process, right?
05:31   Kamion  sivan definitely isn't an experienced developer; I'd be happy for him to work with a mentor to bring him up to speed, but I also think he is inclined to ask people rather than storm ahead
05:31   mdz     and not touch things that they aren't entirely confident about
05:31   sabdfl  ok
05:31   Keybuk  I've certainly not got any objections, have seen him around and he seems willing to help
05:31   mako2   sabdfl: so we pass him saying "you are a doc guy until we prove you can safely work beyon that. ubuntu is not the place to learn and experiment and make beginners mistakes"
05:31   pitti   Kamion: for my taste he even asks too much
05:32   Kamion  pitti: I wasn't going to say that :-)
05:32   mdz     he's definitely enthusiastic; I can't say I know a thing about his technical interests or skills
05:32   sabdfl  mako2: i'm hesitant to pass him on the basis of enthusiasm alone
05:32   Kamion  pitti: (yes, it can be annoying; it's better than the other way round though)
05:32   pitti   Kamion: but I do, he asks me all the time on every day
05:32   pitti   Kamion: I agree
05:32   Kamion  oh, he has done some security work with you hasn't he?
05:32   pitti   As a matter of fact I already am a kind of mentor for him
05:32   Kamion  pitti: how much has he actually done on the security front?
05:32   sabdfl  without wanting to rehash the previous process discussion, we did say that we would expect candidates to collect a list of real contributions made
05:32   mdz     Kamion: he helped with the Warty security review
05:33   mdz     research
05:33   pitti   Kamion: so far he helped with rewieving the 2002 DSAs, but nothing else (that I know of)
05:33   mako2   pitti: he's done documentation work
05:33   pitti   mako2: sure, but I cannot evaluate that
05:33   Kamion  has the doc work he's done been reviewed?
05:33   mdz     doesn't the maintainercandidates page ask them to submit a resume?
05:33   mako2   i think sabdfl is correct.. lets have sivan work with pitti, myself, and whoever else
05:33   mako2   Kamion: no, but i can review the doc work for hte next meeting
05:33   pitti   he often asks me to assign some taks to him, but so far he did not finish anything
05:33   mdz     he did: http://www.ubuntulinux.org/wiki/SivanGreen
05:34   sabdfl  we should only fast-track people who we really know and have no doubt about
05:34   pitti   I would not want to fast-track him
05:34   mdz     sabdfl: agreed
05:34   sabdfl  ok
05:34   pitti   I will happily bring him through some sort of NM process
05:34   sabdfl  if it takes him two or three months, it's worth it for him and for us
05:34   mako2   pitti: that would be great :)
05:34   pitti   he seems eager to do the process, though
05:34   pitti   mako2: I have some experience as AM,
05:35   mako2   pitti: well, this will be a little different but we can discuss that outside of the meeting :)
05:35   pitti   mako2: but as I understood, the process should be shorter
05:35   pitti   mako2: ack
05:35   sabdfl  pitti: just long enough for you to be confident in him, and in your relationship with him
05:35   mako2   pitti: i'd like to do a better job of documenting the process so we work together to sort do a self-documentating process :)
05:35   pitti   sabdfl: I can check his technical skills (and help him with that), but not necessarily the doc stuff
05:35   sabdfl  pitti: that's ok
05:36   mako2   i can overview the doc stuff.. i follow their process/work
05:36   pitti   sabdfl: okay, I'll do it
05:36   sabdfl  he should be able to point to a list of doc contributions if that's his pitch
05:36   sabdfl  ok, next
05:36   pitti   sabdfl: but I will give him some real-world tasks rather than the theoretical Debian NM quesion
05:36   pitti   sabdfl: s/quesion/questions/
05:36   sabdfl  mattias uhrlichs, smurf
05:36   Kamion  sabdfl: aye
05:36   sabdfl  pitti: fine
05:36   sabdfl  Kamion: thanks
05:36   sabdfl  elmo?
05:37   mdz     perhaps it is sufficient to get N confirms, rather than tally votes from everyone?
05:37   elmo    sabdfl: for smurf?  aye
05:37   mako2   i already nodded earlier
05:37   sabdfl  ok
05:38   sabdfl  smurf is approved from cc
05:38   mako2   mdz: only 4 people :)
05:39   sabdfl  oliver grawert?
05:39   Kamion  bit of a lack of technical resume there
05:40   mdz     he's been active on -devel
05:40   mako2   mdz: what is his nick?
05:40   sabdfl  not known enough for me to like fast-tracking
05:40   mdz     mako2: not sure, I meant the mailing list
05:40   daniels i believe his nick is ogra
05:40   mdz     ah, he's active on #ubuntu as well, then
05:41   mako2   yeah, i've seen his messages but i'm with sabdfl here
05:41   mdz     sabdfl: agreed
05:41   sabdfl  ok, full process
05:41   sabdfl  alexander poslavsky has been excellent on the wiki
05:42   mdz     Alexander Poslavsky is a doc team guy, very active
05:42   sabdfl  perhaps a doc candidate?
05:42   Kamion  what's our general rule on doc team <=> maintainership?
05:42   mdz     what does that mean?
05:43   sabdfl  Kamion: i think doc team members should have full commit capability
05:43   Kamion  mdz: what sabdfl just said. :-)
05:43   Kamion  sabdfl: ok
05:43   sabdfl  i think we said maintainers would also be able to push out a release
05:44   Kamion  plovs is fine with me, I think he's earned his stripes up to now
05:44   sabdfl  but in the absence of HCT, would we prefer to err on the side of allowing or disallowing uploads by doc team members?
05:44   mdz     sabdfl: commits to the package archive?
05:44   mdz     sabdfl: disallowing
05:44   sabdfl  i'd fall on the other side :-)
05:44   mdz     most of them have neither interest in packaging, nor a GPG key
05:44   fabbione        i agree with mdz
05:44   sabdfl  perhaps we could have a tighter policy post-freeze?
05:44   sabdfl  empowering is better, if someone trips up pre-freeze it's unlikely to be a disaster
05:44   mako2   i'd prefer to not have two classes of maintainers
05:45   sabdfl  mako2: we did already agree that though
05:45   sabdfl  contributor - sends patches
05:45   sabdfl  committer - can commit to the arch branches
05:45   mako2   right
05:45   sabdfl  maintainer - can trigger the release
05:45   mako2   i was taking about maintainers
05:46   sabdfl  in the absence of the arch infrastructure i'd prefer to use social structures to enforce "doc only" maintainership
05:46   sabdfl  if someone uploads something thats out of line, that's a social issue
05:46   sabdfl  which we can quickly sort out
05:46   mdz     there are more issues apart from uploading things out of line
05:46   mako2   it's hard enough to get people to do the not-so-sexy documentation thing.. full fledged maintainership, whatever that is
05:46   mako2   sound good to me
05:46   mdz     a new maintainer means a new key in the keyring, which needs to be properly signed and protected
05:47   sabdfl  right, so we have to have confidence in the person's gpg security knowledge
05:47   mdz     do the doc guys even want that responsibility?
05:47   mako2   mdz: i guess we should ask
05:47   sabdfl  what's the worst case?
05:47   mdz     worst case is http://www.google.com/?q=secring.gpg
05:48   elmo    *giggle*
05:48   fabbione        that reminds me of... thom?
05:48   fabbione        ;)
05:48   mdz     er, http://www.google.com/search?q=secring.gpg
05:49   sabdfl  why would a maintainer be able to change the keyring?
05:49   elmo    sabdfl: they can't - but if their key is insecure, then our packages are vulnerable
05:49   mako2   sabdfl: no, he's afraid they'll put their keyring somewhere whehere peopl can google it and download it
05:50   mdz     mako2: well, I said that's the worst case :-)
05:50   Kamion  that's an outside risk, but it's an example of general key management incompetence, which in its general form is common
05:50   elmo    http://www.google.com/search?q=inurl%3Asecring.gpg
05:50   mdz     elmo: yeah, that one
05:51   mdz     whoever justin pryzby is, we wouldn't want his key in our keyring
05:51   mako2   ok, so the danger is not that we can't trust the nm candidates, it's our job to make sure we can
05:52   mako2   the danger is that we can't trust everyone who has their key :)
05:52   Keybuk  yeah, anyone who manages to expose a private key like that should be shot
Keybuk tickles thom playfully
05:52   mdz     mako2: the question is whether we need to force people through that process in order to be an official documentation person
05:52   sabdfl  i think it's reasonable to establish gpg practice understanding
05:52   sabdfl  if that's a key requirement
05:53   mdz     that is definitely a key requirement; it's the basis for our trust
05:53   mako2   i think a keyring of maintainers is a Good Thing for reasons other than uploading packages
05:53   mako2   voting, etc
05:54   elmo    yeah, but we should probably have a separate keyring for uploaders
05:54   sabdfl  the doc guys will need to be briefed and tested
05:54   mako2   the documentation are not writing advertisemennet copy.. they're writing technical documentation.. they should be able to figure out how to use gpg and get some key safety :)
05:54   sabdfl  elmo: why have a separate keyring?
05:54   daniels elmo: one for voters/et al, one for people who can upload
05:54   daniels er
05:54   daniels sabdfl: ^^
05:54   daniels sabdfl: so not everyone can upload libc6
05:55   mdz     do we actually have any process in mind where we would hold a vote of the entire project?
05:55   sabdfl  *cough* voting *cough*
sabdfl wonders who ever considered democracy in these hallowed halls
05:55   Kamion  mdz: cc/tb reelection
05:55   sabdfl  confirmation
05:55   mdz     Kamion: those are appointed positions, no?
05:55   elmo    sabdfl: usual reasons: damage limitation, layered security, etc. - if the doc guys don't actually need their keyring, except once every two years or vote or something, they're much less likely to apply as-good-as-we-would-like security practices to their GPG key
05:55   sabdfl  Kamion is (again) correct
05:55   mako2   call it consensus or just identifying yourself :)
05:56   sabdfl  elmo: but the doc guys are definitely going to be committing to the codebase, and that will require gpg keys
05:56   sabdfl  once we have bazaar flying, with hct
05:56   Kamion  mdz: hm, there was talk of having them confirmed by plebiscite of maintainers to start with
05:57   sabdfl  yes, nominated y me, confirmed by a plebiscite (!)
mako network is revived
05:57   elmo    sabdfl: sure - but until we get there, I think we need separate keys.  and not all derivatives will be using upload-via-arch in any event, so we're going to have to deal with managing multiple "upload" keyrings anyways from an archive POV
05:57   sabdfl  ok
05:57   Kamion  sabdfl: (plebiscite is such a good word I just had to use it)
05:57   sabdfl  but the question is whether we want to allow a doc person to upload packages
05:58   elmo    sabdfl: <fascist-that-I-am>no.  if they upload packages, they're by definition not a doc person</>
05:58   mdz     if they meet the criteria, sure
05:58   mako    what about documentation packages? :)
05:58   sabdfl  i think someone who understands gpg, and who has agreed not to touch code, should be allowed to do so
05:59   mdz     someone who understands gpg, and knows their limits
05:59   sabdfl  if they break the social agreement, we have a problem that can be solved simply
mako nods
05:59   sabdfl  perhaps we can switch modes post-freeze
05:59   sabdfl  to minimise the risk of an accidental stuffup
05:59   sabdfl  so the policy is "looser till freeze"
06:00   sabdfl  all of this is just till we get bazaar / hct
06:00   mdz     it is?
06:00   mdz     it seems like we have the same issues with baz/hct
06:01   sabdfl  but we can distinguish between commit and upload
06:01   sabdfl  whereas now we cant
06:01   mdz     but without someone reviewing the changes, they're pretty much equivalent
06:01   sabdfl  the additional review is a disincentive to contribution
06:01   sabdfl  being able to upload is a big motivator
06:01   sabdfl  instant gratification
06:02   mdz     I'm not really worried about folks who are comfortable working with gpg having commit access to write docs
06:02   sabdfl  i really think we should acknowledge the doc team's contribution with maintainer status
06:02   mdz     what I object to is making their official status contingent on gpg usage
06:02   mdz     they should at least be able to decline that piece, and still be officially recognized
06:02   sabdfl  so they can still vote
06:02   sabdfl  but not have to deal with gpg
06:02   sabdfl  that's fine by me
06:03   sabdfl  it's at their option
06:03   sabdfl  elmo, can you live with this?
06:03   sabdfl  separate keyring for voting, contains additional keys of maintainers who choose not to upload
06:03   mdz     there's no need to require gpg for voting, since they should be able to do it by logging into the website or similar
mako happy with that
06:03   sabdfl  also true
06:04   elmo    sabdfl: yeah, if we can discourage gpg key use when it's not necessary, I'm all for it
06:04   mdz     what it sounds like we're moving toward is an official contributor status
06:04   mdz     that's someone who can't commit, but participates, and they have a voice
06:04   sabdfl  except that the "can't commit" is at their option, thus far
06:04   mdz     in oxford, we said that the contributor (with baz/hct) could be anyone
06:05   mdz     that it didn't require official status
06:05   sabdfl  only because bazaar will allow branching so easily
06:05   mdz     right
06:05   mdz     but a contributor could be someone with a vote
06:05   sabdfl  ok, this is a new idea
06:05   sabdfl  but a nice one
06:05   mdz     distinguishing them from the rest of the planet, community-wise
06:06   sabdfl  particularly for doc team, and community support people
06:06   sabdfl  guys who make a huge contribution
06:06   sabdfl  and in due course we'll have industrial karma to give clear indications of who gets that voice
06:07   mako    i still am not too hot on the idea of having contributors and maintainers be different
06:07   mako    i think it sets up a hierarchy with the doc people apparently being lower
06:07   mako    it doesn't bother me if they haev a gpg key, or not.. it's the political and social distinction that i'm most worried about
06:08   mdz     it's a meaningful infrastructural distinction, though
06:08   mdz     and reflects the way the community actually works
06:08   mdz     that's how we arrived at it in oxford
06:08   mako    yes, but we also said at oxford that doc people should be able to be full maintainers :)
06:08   mdz     sure, they should be able to be
06:08   sabdfl  mako: this is nothing to stop a doc guy from being a maintainer
06:09   sabdfl  it's a new idea, afaict
06:09   sabdfl  so, to summarise, mdz shout if i have it wrong
06:09   sabdfl  we develop the concept of the "voting community"
06:10   sabdfl  this includes maintainers and people who are also given a vote because of a significant contribution in some other field
06:10   mdz     we already established a hierarchy of contributor -> committer -> maintainer -> ..., with "committer" being the point at which strong authentication is required
06:10   sabdfl  maintainership means "can trigger or upload a package release"
06:11   sabdfl  committer means "can commit to a package"
06:11   sabdfl  mdz: would you see the voters as being all committers then?
06:11   sabdfl  i'm not so sure about that
06:12   mdz     sabdfl: what I proposed in this meeting was that contributors be able to vote
06:12   mdz     which provides an official, voting status which doesn't require strong authentication
06:12   sabdfl  the only example we have of voting is confirmation of appointments to tech and community boards
06:12   mdz     and gives a useful home for contributors who aren't ready/willing to accept the responsibility of commit access
06:12   sabdfl  id like those voters to be limited to substantial contributors
06:12   mdz     but who are valued members of the community who should have a voice
06:13   sabdfl  i agree "substantial contribution" doesn't only mean code, and uploads
06:13   sabdfl  but it is still different from "have sent in a few patches"
06:13   mdz     I would think that anyone who makes regular, high-quality contributions would naturally become a committer
06:14   sabdfl  thats not what we were discussing though
06:14   mdz     so if what we want is for only substantial contributors to be able to vote, I think that would be committers
06:14   sabdfl  i was trying to follow up on your thought that "voters" need not equal "maintainers"
06:14   sabdfl  i'm not even comfortable with that
06:15   sabdfl  because we might ultimately have committers with fairly narrow commit rights
06:15   sabdfl  depending on how good we can get hct
06:15   sabdfl  we might, for example, give upstream guys all commit rights in the packages that they upstream code lives in
06:15   sabdfl  im not sure that should give them a say in who sits on your tech board
06:16   sabdfl  vs, say, a doc guy who has put in a lot of work on the wiki and website
mako nods
06:16   mdz     what the website currently says is "a vote amongst the maintainers"
06:16   mdz     I guess if that's the sort of thing we will be voting on, then yes, it should be more exclusive
06:17   mako    all we need to figure out is how we are going to identify contributions that are meaningful and then recognize those with status. the detail of who can committ where and where seems like it might be a technical detail we don't need to take on fully
06:17   sabdfl  that's the only process we have that involves a vote
06:17   sabdfl  for the moment, i think the best plan is to make the big contributors maintainers
06:17   sabdfl  and have them agree not to touch code
06:18   sabdfl  so for the moment it's fairly binary
06:18   mdz     and the issue I raised with that is that it places a fairly strong technical burden on them, i.e. key management
06:18   sabdfl  (oh, and they can agree not to upload at all)
06:18   sabdfl  but they still kep their vote
mako agrees with sabdfl
06:18   sabdfl  later on, when we have better tools both for objective review of community participation, and code control, we can tune it
06:19   mdz     so the proposed solution to that issue is to allow them to voluntarily decline commit privileges on their way to becoming a maintainer?
06:19   sabdfl  if we had doubts, i suppose we could offer maintainership explicitly without upload capability
06:20   mako    sivang: hey there
06:20   sabdfl  but i would prefer that we simply test gpg knowledge, and if it's ok, let them have the option not to be in the upload keyring
06:20   sabdfl  sivang: you'll want to read the logs of this meeting
06:20   mako    mdz: that sounds reasonable
06:20   mako    sivang: i can bring you up to speed aftewards as well
06:20   sivang  sabdfl : so I've heared :)
06:20   sabdfl  it's a simple way to get started
06:21   pitti   mako, sabdfl: I already told him the short-short version
06:21   sabdfl  ok
06:21   sabdfl  can i hear back from elmo, mako, kamion on this:
06:22   sabdfl  - we'll allow maintainers not to be in the upload keyring if they don't really need to be
06:22   sabdfl  - we'll approve some non-code contributors as maintainers, so they have a vote where it counts
06:22   sabdfl  - when we have hct / bazaar we can fine tune these
06:22   sabdfl  ?
06:23   elmo    works for me
06:23   mako    that sounds fine
06:23   Kamion  ok by me
06:23   sivang  mako : thanks
06:23   sabdfl  done
06:24   sabdfl  on that basis, i think hornbeck and alexander poslavsky and enrico would be candidates for maintainership
sivang regrets for missing the CC meeting. seems some really cool thing been decided.
06:25   sabdfl  anyone want to weigh in on those three?
06:26   Kamion  Enrico's a reasonable Debian developer, he might not be limited to just docs
mako nods
06:26   Kamion  but those three are certainly fine AFAIAC
06:26   sabdfl  ok
06:27   Kamion  Enrico's not on MaintainerCandidates?
06:27   mdz     nope
06:27   sabdfl  he's the doc team secretary
06:27   sabdfl  seems sane to offer him the upload option, and a vote
06:28   mako    yeah, absolutely
06:28   sabdfl  can we move through the list quite quickly now?
06:28   mako    fine with me
06:28   Kamion  please
06:28   sabdfl  let's just focus on establishing if there are people we know well enough to ack immediately
06:28   sabdfl  others can go through the process
06:29   sabdfl  saravanan reju?
06:29   sabdfl  raju
06:29   mako    don't know..
06:29   mako    process
06:29   sabdfl  ok, full process
06:29   sabdfl  john levin
06:29   sabdfl  i don't know him
06:30   sabdfl  anyone in favour?
06:30   mdz     doc team guy
06:30   Kamion  I've seen him around, but process I think
06:30   mako    i know him from traffic on the doc list and such
06:30   sabdfl  ok, full process
06:30   sabdfl  martin krafft?
06:30   mako    he seems to be active but definitely a doc guy
06:30   sabdfl  full process
06:30   sabdfl  Darren Critchley
06:30   mako    full process
06:30   sabdfl  David Walker
06:30   mdz     talked to him, process
06:31   sabdfl  Marco Bonetti
mako nods
06:31   sabdfl  nods what?
06:31   mako    that was to the last comment
06:31   sabdfl  Luke Yelavich
06:31   mako    marco: i think i've met him but am not familiar with his contributions
06:31   Kamion  he's the accessibility guy, Jeff's been talking to him I think?
06:31   mako    luke: i don't know luke except a little bit of mailing list ubuntu stff
06:31   sabdfl  i don't know luke
06:31   Kamion  process, though
06:31   sabdfl  Diego Andrs Asenjo
06:32   sabdfl  process?
06:32   sabdfl  Christoph Haas
06:32   Kamion  Christoph> process, but would expect him to get through quickly
06:32   sabdfl  ok
mako doesn
06:32   mako    't know either
06:32   mdz     who will have responsibility for notifying anyone who just became a maintainer?
06:32   Kamion  he's the mentors.debian.net guy
06:32   sabdfl  i'll send them a mail
06:33   sabdfl  so let's be clear, i have:
06:33   sabdfl  thibault varene
06:33   sabdfl  alexander pos
06:33   sabdfl  john hornbeck
06:33   sabdfl  mathias urlichs
06:33   sabdfl  that's it
06:34   sabdfl  i'll send an email to -devel
06:34   sabdfl  and to them
06:34   mdz     you mentioned enrico zini earlier
06:34   sabdfl  yes, enrico too, but since he didn't put himself on the page i'll check with him first
06:34   mdz     ok
06:34   mako    sounds good
06:34   sabdfl  ok
06:34   sabdfl  are we done on the appointments front?
06:35   sabdfl  let's talk about community member sponsorship to the conf
06:35   mdz     ok
06:35   sabdfl  i think we can sponsor 10 people for travel and board, and 10 for board in each week, separately
06:36   sabdfl  so a total of 30 people
06:36   sabdfl  10 get travel and board if they are willing to come for a full week
06:36   sabdfl  20 more get a week of board covered, if they want to get themselves there
06:37   sabdfl  we have an internal wiki page, for internal nominations
06:38   sabdfl  but i think we should also ask community members who are keen to sign up somewhere
06:38   mdz     there is a page in the public wiki for that
06:38   mako    mdz: sort of
06:38   sabdfl  ok, has a mail gone to the lists inviting people to sign up?
06:38   mdz     I believe the announcement of the conference included a bit about that
06:38   silbs   yes, an email annoucement went out
06:39   sabdfl  ok, let's announce the sponsorship separately
06:39   sabdfl  we have already approved quite a few
06:39   sabdfl  mako, will you coordinate that email with silbs?
06:39   mdz     http://lists.ubuntu.com/archives/ubuntu-devel/2004-November/000913.html
06:39   mako    yeah, i sent the mail
06:40   mako    sabdfl: yes sure
06:40   sabdfl  great
06:40   sabdfl  that email didn't say (a) where to sign up and (b) that we have some sponsorship available
06:40   mako    sabdfl: where to sign up for sponsorship?
06:41   sabdfl  mako: yes
06:41   sabdfl  maybe also link to the mail archive from the web site home page conference headline
06:41   sabdfl  so people see ont he home page that sponsorship is available
06:41   sabdfl  Kamion, elmo, mako: any other business?
06:42   mako    nope
06:42   elmo    not from me
06:42   Kamion  nope
06:42   sabdfl  mdz, guests?
06:43   sabdfl  ok, take that as a no
06:43   silbs   on sponsorship - will nominees and decisions be public?
06:43   sabdfl  thanks everybody
06:43   sabdfl  i'm easy, i think it would be a good idea to send a mail saying who we were sponsoring
06:44   silbs   okay. We need to make sure it is fair - a deadline for signing up so it isn't just a first come, first serve, etc.
06:44   silbs   I'll work it with Mako
06:44   sabdfl  ok
06:44   sabdfl  thanks everybody
06:44   sabdfl  workrave time
06:44   sabdfl  meeting closed
11:14   cenerentola     hi there


Generated by irclog2html.pl 2.1 by Jeff Waugh - find it at freshmeat.net!