=== mjg59_ [~mjg59@cpc2-cmbg5-4-0-cust206.cmbg.cable.ntl.com] has joined #ubuntu-meeting === mjg59_ [mjg59@cavan.codon.org.uk] has joined #ubuntu-meeting === rabidbt [~rabidbt@66.45.74.16] has joined #ubuntu-meeting === doko [doko@dsl-082-082-069-185.arcor-ip.net] has joined #ubuntu-meeting === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting === pitti [~martin@195.227.105.180] has left #ubuntu-meeting [] === mjg59 [mjg59@cavan.codon.org.uk] has joined #ubuntu-meeting === doko [doko@dsl-082-082-069-185.arcor-ip.net] has joined #ubuntu-meeting === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #ubuntu-meeting [05:11] CC meeting? [05:11] here [05:12] um, had forgotten about it [05:12] we don't seem to have any agenda items === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting [05:12] anything on the agenda? [05:12] nothing [05:12] nothing that i saw [05:12] agenda on the wiki seems to be empty [05:12] sorry for being late [05:12] i checked this morning and it was just old stuff [05:12] do we have AOB? [05:12] so made it blank [05:13] AOB? [05:13] any other business (i.e. off-agenda) [05:13] not from me [05:13] yes [05:13] I'd like to talk about the maintainer process [05:13] hmm... maybe conference invitations to community members [05:13] lack thereof, at the moment [05:14] is someone expected to be working on community processes? jdub? [05:14] mdz: do we have a framework for maintainers whohave been appointed? [05:14] i think mako [05:14] he sms'd me to say his net was busted [05:14] he's trying to make another plan [05:14] oh [05:15] i would really like to get a community team going [05:15] in other words have a few maintainers who are not Canonical folk [05:15] we have a keyring for the archive, and a queue of folks who want to be considered === daniels [daniel@fooishbar.org] has joined #ubuntu-meeting [05:15] with full upload capability [05:15] the rest is documentation and procedures === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting === hazmat [~hazmat@c-24-15-10-12.client.comcast.net] has joined #ubuntu-meeting [05:16] when mako and I talked about this last, we were on the same page as to how it should work [05:16] ok === ..[topic/#ubuntu-meeting:mdz] : Shotgun Community Council meeting === zul [~chuck@zul.developer.gentoo] has joined #ubuntu-meeting === mako2 [~mika@pool-70-18-203-202.ny325.east.verizon.net] has joined #ubuntu-meeting [05:17] ah, the clocks have gone back, that's why my alarm didn't go [05:17] 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 === seb128 [~seb128@ANancy-151-1-9-186.w83-194.abo.wanadoo.fr] has joined #ubuntu-meeting [05:18] 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] I wrote a document for the "I have a problem" case which walks through support and bug reporting basics [05:18] the MaintainerCandidates page has a few people [05:18] there is already a participate document [05:19] 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] mdz: do you think it should be built on top of that? [05:19] are there any there who have strong credentials from existing open source work that would allow us to approve them immediately? [05:19] also "when you *don't* need to be an Ubuntu developer in order to get your problem fixed" [05:19] mako2: possibly, I'm waiting for plone to give it to me so I can see [05:19] thinking of the people who want to join just in order to get some theme added or whatever [05:19] http://www.ubuntulinux.org/community/participate/document_view [05:20] mako2: perhaps that just needs some more specifics [05:20] "become a maintainer" doesn't tell you where to start [05:20] just needs a link to the relevant process [05:20] right === elmo [~james@83.216.141.215] has joined #ubuntu-meeting [05:20] (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] once the process is documented :-) [05:20] Kamion++ === mako2 apologizes if he gets disconnected.. i have the laptop halfway out the kitchen window and (am getting up to 30 seconds of lag) [05:21] http://www.ubuntulinux.org/wiki/MaintainerCandidates [05:21] is there anyone on there that we would feel comfortable approving right away? [05:21] mako2: I'm thinking that it should have some very simple bullet points which link to more detailed documents [05:21] mako2: each aimed at a use case which already exists [05:22] so that a user who comes to the page who already knows what they want, can find the relevant interface [05:22] Matthias Urlichs is a competent Debian guy, IIRC [05:22] mdz: i'm happy to help with that [05:22] i would be happy to approve some of the guys who have made great doc contributions already [05:22] Kamion: yes, we've been chatting a little bit offlist as wel [05:22] Thibaut VARENE is the ia64 guy and should be straightforward to approve [05:22] his name is familiar, but I can't vouch personally [05:22] as long as they agree just to work on package documentation [05:23] lamont can vouch for thibaut, IIRC [05:23] Kamion: he maintains some non-trivial python packages [05:23] python-docutils (RST) [05:23] elmo: do we have a public upload queue? [05:23] i can also vouch for thibaut [05:23] i was his AM in Debian so i've already gone through NM with him once [05:23] oh, he's the gnutls/gcrypt maintainer [05:23] mdz: no - we're waiting on zope 3's ftpd getting fixed - I've just pinged SteveA about it [05:23] $ grep-available -nsPackage 'Matthias Urlichs' | wc -l [05:23] 80 === mdz blinks [05:24] gosh [05:24] that would be a yes then [05:24] yeah, smurf's competent IMO [05:24] (quantity not implying quality or anything, but :-)) === plovs [~plovs@62.84.21.44] has joined #ubuntu-meeting [05:25] Kamion: why do I always find myself agreeing with you when you point out that sort of thing? [05:25] I'm just such an agreeable guy [05:25] erm. but i'm not. [05:25] because of his sneaky tendency to be correct [05:25] yeah, but he also maintains some touch ones [05:25] ah. yes, that [05:25] i've been working with him this week on preparing the new upstream release of python-docutils [05:25] ok, let's take these one at a time, maybe that would be better [05:25] we still need a proper process for guys we don't know already [05:26] mako2, can we leave the process documentation in your hands, deliverable for the next cc meeting? [05:26] yes [05:26] yes [05:26] and mdz, can we handle both techboard and cc approvals today, do you have your tech board handy? [05:27] mdz: help me outline and check it,eh? [05:27] hm, I'll see [05:27] mako2: definitely [05:27] ok: thibaut varene, opinions? [05:28] i was his am in debian [05:28] already discussed? [05:28] (prodded Keybuk) [05:28] i passed him there with glowing recommendations and i would do it again here :) [05:28] sabdfl: mako and lamont both say good things, I've chatted with him and found him sane [05:28] how do we want to do this, require all cc members to say aye or nay? [05:28] he's been sane when I've talked to him too; thibaut ack [05:29] ok, thibaut is in === Keybuk [scott@descent.netsplit.com] has joined #ubuntu-meeting [05:29] evening [05:29] cheers [05:29] from a cc perspective, mdz, you make the call for tech board [05:29] hiya scott [05:29] sivan green [05:29] he's been very "present" [05:29] sabdfl: I think requiring CC unanimity would be good until we have a clearer procedure === fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-meeting [05:29] lot's of enthusiasm on the doc front [05:30] 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] not much experience i don't think [05:30] a candidate for the full process? [05:30] I talk with him very often; he seems eager, but did not finish much up to now [05:30] he's been in contact with me directly several times a week about a number of things [05:30] mako and I talked a bit, and I think the full process can very nearly be condensed to a single bullet point [05:30] the key is that we can trust them to know their own limits [05:30] i gather that sivan would be happy with the fully process [05:30] right [05:31] I think so, too [05:31] mdz: can you turn that into something a little less existential? [05:31] if we can be confident that someone will ask before entering unknown waters [05:31] but he should finish at least a small coding project before he starts the full process, right? [05:31] 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] and not touch things that they aren't entirely confident about [05:31] ok [05:31] I've certainly not got any objections, have seen him around and he seems willing to help [05:31] 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] Kamion: for my taste he even asks too much [05:32] pitti: I wasn't going to say that :-) [05:32] he's definitely enthusiastic; I can't say I know a thing about his technical interests or skills [05:32] mako2: i'm hesitant to pass him on the basis of enthusiasm alone [05:32] pitti: (yes, it can be annoying; it's better than the other way round though) [05:32] Kamion: but I do, he asks me all the time on every day [05:32] Kamion: I agree [05:32] oh, he has done some security work with you hasn't he? [05:32] As a matter of fact I already am a kind of mentor for him [05:32] pitti: how much has he actually done on the security front? [05:32] 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] Kamion: he helped with the Warty security review [05:33] research [05:33] Kamion: so far he helped with rewieving the 2002 DSAs, but nothing else (that I know of) [05:33] pitti: he's done documentation work [05:33] mako2: sure, but I cannot evaluate that [05:33] has the doc work he's done been reviewed? [05:33] doesn't the maintainercandidates page ask them to submit a resume? [05:33] i think sabdfl is correct.. lets have sivan work with pitti, myself, and whoever else [05:33] Kamion: no, but i can review the doc work for hte next meeting [05:33] he often asks me to assign some taks to him, but so far he did not finish anything [05:33] he did: http://www.ubuntulinux.org/wiki/SivanGreen [05:34] we should only fast-track people who we really know and have no doubt about [05:34] I would not want to fast-track him [05:34] sabdfl: agreed [05:34] ok [05:34] I will happily bring him through some sort of NM process [05:34] if it takes him two or three months, it's worth it for him and for us [05:34] pitti: that would be great :) [05:34] he seems eager to do the process, though [05:34] mako2: I have some experience as AM, [05:35] pitti: well, this will be a little different but we can discuss that outside of the meeting :) [05:35] mako2: but as I understood, the process should be shorter [05:35] mako2: ack [05:35] pitti: just long enough for you to be confident in him, and in your relationship with him [05:35] 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] sabdfl: I can check his technical skills (and help him with that), but not necessarily the doc stuff [05:35] pitti: that's ok [05:36] i can overview the doc stuff.. i follow their process/work [05:36] sabdfl: okay, I'll do it [05:36] he should be able to point to a list of doc contributions if that's his pitch [05:36] ok, next [05:36] sabdfl: but I will give him some real-world tasks rather than the theoretical Debian NM quesion [05:36] sabdfl: s/quesion/questions/ [05:36] mattias uhrlichs, smurf [05:36] sabdfl: aye [05:36] pitti: fine [05:36] Kamion: thanks [05:36] elmo? === hno73 [~Henrik@henrik.gotadsl.co.uk] has joined #ubuntu-meeting [05:37] perhaps it is sufficient to get N confirms, rather than tally votes from everyone? [05:37] sabdfl: for smurf? aye [05:37] i already nodded earlier [05:37] ok [05:38] smurf is approved from cc [05:38] mdz: only 4 people :) [05:39] oliver grawert? [05:39] bit of a lack of technical resume there [05:40] he's been active on -devel [05:40] mdz: what is his nick? [05:40] not known enough for me to like fast-tracking [05:40] mako2: not sure, I meant the mailing list [05:40] i believe his nick is ogra [05:40] ah, he's active on #ubuntu as well, then [05:41] yeah, i've seen his messages but i'm with sabdfl here [05:41] sabdfl: agreed [05:41] ok, full process [05:41] alexander poslavsky has been excellent on the wiki [05:42] Alexander Poslavsky is a doc team guy, very active [05:42] perhaps a doc candidate? === mako2 nods [05:42] what's our general rule on doc team <=> maintainership? [05:42] what does that mean? [05:43] Kamion: i think doc team members should have full commit capability [05:43] mdz: what sabdfl just said. :-) [05:43] sabdfl: ok [05:43] i think we said maintainers would also be able to push out a release [05:44] plovs is fine with me, I think he's earned his stripes up to now [05:44] 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] sabdfl: commits to the package archive? [05:44] sabdfl: disallowing [05:44] i'd fall on the other side :-) [05:44] most of them have neither interest in packaging, nor a GPG key [05:44] i agree with mdz [05:44] perhaps we could have a tighter policy post-freeze? [05:44] empowering is better, if someone trips up pre-freeze it's unlikely to be a disaster [05:44] i'd prefer to not have two classes of maintainers [05:45] mako2: we did already agree that though [05:45] contributor - sends patches [05:45] committer - can commit to the arch branches [05:45] right [05:45] maintainer - can trigger the release [05:45] i was taking about maintainers [05:46] in the absence of the arch infrastructure i'd prefer to use social structures to enforce "doc only" maintainership [05:46] if someone uploads something thats out of line, that's a social issue [05:46] which we can quickly sort out [05:46] there are more issues apart from uploading things out of line [05:46] it's hard enough to get people to do the not-so-sexy documentation thing.. full fledged maintainership, whatever that is [05:46] sound good to me [05:46] a new maintainer means a new key in the keyring, which needs to be properly signed and protected [05:47] right, so we have to have confidence in the person's gpg security knowledge [05:47] do the doc guys even want that responsibility? [05:47] mdz: i guess we should ask [05:47] what's the worst case? [05:47] worst case is http://www.google.com/?q=secring.gpg [05:48] *giggle* [05:48] that reminds me of... thom? [05:48] ;) [05:48] er, http://www.google.com/search?q=secring.gpg [05:49] why would a maintainer be able to change the keyring? [05:49] sabdfl: they can't - but if their key is insecure, then our packages are vulnerable [05:49] sabdfl: no, he's afraid they'll put their keyring somewhere whehere peopl can google it and download it [05:50] mako2: well, I said that's the worst case :-) [05:50] that's an outside risk, but it's an example of general key management incompetence, which in its general form is common [05:50] http://www.google.com/search?q=inurl%3Asecring.gpg [05:50] elmo: yeah, that one [05:51] whoever justin pryzby is, we wouldn't want his key in our keyring [05:51] 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] the danger is that we can't trust everyone who has their key :) [05:52] yeah, anyone who manages to expose a private key like that should be shot === Keybuk tickles thom playfully [05:52] mako2: the question is whether we need to force people through that process in order to be an official documentation person [05:52] i think it's reasonable to establish gpg practice understanding [05:52] if that's a key requirement [05:53] that is definitely a key requirement; it's the basis for our trust [05:53] i think a keyring of maintainers is a Good Thing for reasons other than uploading packages [05:53] voting, etc [05:54] yeah, but we should probably have a separate keyring for uploaders [05:54] the doc guys will need to be briefed and tested [05:54] 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] elmo: why have a separate keyring? [05:54] elmo: one for voters/et al, one for people who can upload [05:54] er [05:54] sabdfl: ^^ [05:54] sabdfl: so not everyone can upload libc6 [05:55] do we actually have any process in mind where we would hold a vote of the entire project? [05:55] *cough* voting *cough* === sabdfl wonders who ever considered democracy in these hallowed halls [05:55] mdz: cc/tb reelection [05:55] confirmation [05:55] Kamion: those are appointed positions, no? [05:55] 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] Kamion is (again) correct [05:55] call it consensus or just identifying yourself :) === mvo_ [~egon@suprimo-161.ping.de] has joined #ubuntu-meeting [05:56] elmo: but the doc guys are definitely going to be committing to the codebase, and that will require gpg keys [05:56] once we have bazaar flying, with hct [05:56] mdz: hm, there was talk of having them confirmed by plebiscite of maintainers to start with === mako [mako@micha.hampshire.edu] has joined #ubuntu-meeting [05:57] yes, nominated y me, confirmed by a plebiscite (!) === mako network is revived [05:57] 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] ok [05:57] sabdfl: (plebiscite is such a good word I just had to use it) [05:57] but the question is whether we want to allow a doc person to upload packages [05:58] sabdfl: no. if they upload packages, they're by definition not a doc person [05:58] if they meet the criteria, sure [05:58] what about documentation packages? :) [05:58] i think someone who understands gpg, and who has agreed not to touch code, should be allowed to do so [05:59] someone who understands gpg, and knows their limits [05:59] if they break the social agreement, we have a problem that can be solved simply === mako nods [05:59] perhaps we can switch modes post-freeze [05:59] to minimise the risk of an accidental stuffup [05:59] so the policy is "looser till freeze" [06:00] all of this is just till we get bazaar / hct [06:00] it is? [06:00] it seems like we have the same issues with baz/hct [06:01] but we can distinguish between commit and upload [06:01] whereas now we cant [06:01] but without someone reviewing the changes, they're pretty much equivalent [06:01] the additional review is a disincentive to contribution [06:01] being able to upload is a big motivator [06:01] instant gratification [06:02] I'm not really worried about folks who are comfortable working with gpg having commit access to write docs [06:02] i really think we should acknowledge the doc team's contribution with maintainer status [06:02] what I object to is making their official status contingent on gpg usage [06:02] they should at least be able to decline that piece, and still be officially recognized [06:02] so they can still vote [06:02] but not have to deal with gpg [06:02] that's fine by me [06:03] it's at their option [06:03] elmo, can you live with this? [06:03] separate keyring for voting, contains additional keys of maintainers who choose not to upload [06:03] 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] also true [06:04] sabdfl: yeah, if we can discourage gpg key use when it's not necessary, I'm all for it [06:04] what it sounds like we're moving toward is an official contributor status [06:04] that's someone who can't commit, but participates, and they have a voice [06:04] except that the "can't commit" is at their option, thus far [06:04] in oxford, we said that the contributor (with baz/hct) could be anyone [06:05] that it didn't require official status [06:05] only because bazaar will allow branching so easily [06:05] right [06:05] but a contributor could be someone with a vote [06:05] ok, this is a new idea [06:05] but a nice one [06:05] distinguishing them from the rest of the planet, community-wise [06:06] particularly for doc team, and community support people [06:06] guys who make a huge contribution [06:06] and in due course we'll have industrial karma to give clear indications of who gets that voice [06:07] i still am not too hot on the idea of having contributors and maintainers be different [06:07] i think it sets up a hierarchy with the doc people apparently being lower [06:07] 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] it's a meaningful infrastructural distinction, though [06:08] and reflects the way the community actually works [06:08] that's how we arrived at it in oxford [06:08] yes, but we also said at oxford that doc people should be able to be full maintainers :) [06:08] sure, they should be able to be [06:08] mako: this is nothing to stop a doc guy from being a maintainer [06:09] it's a new idea, afaict [06:09] so, to summarise, mdz shout if i have it wrong [06:09] we develop the concept of the "voting community" [06:10] this includes maintainers and people who are also given a vote because of a significant contribution in some other field [06:10] we already established a hierarchy of contributor -> committer -> maintainer -> ..., with "committer" being the point at which strong authentication is required [06:10] maintainership means "can trigger or upload a package release" [06:11] committer means "can commit to a package" [06:11] mdz: would you see the voters as being all committers then? [06:11] i'm not so sure about that [06:12] sabdfl: what I proposed in this meeting was that contributors be able to vote [06:12] which provides an official, voting status which doesn't require strong authentication [06:12] the only example we have of voting is confirmation of appointments to tech and community boards [06:12] and gives a useful home for contributors who aren't ready/willing to accept the responsibility of commit access [06:12] id like those voters to be limited to substantial contributors [06:12] but who are valued members of the community who should have a voice [06:13] i agree "substantial contribution" doesn't only mean code, and uploads [06:13] but it is still different from "have sent in a few patches" [06:13] I would think that anyone who makes regular, high-quality contributions would naturally become a committer [06:14] thats not what we were discussing though [06:14] so if what we want is for only substantial contributors to be able to vote, I think that would be committers [06:14] i was trying to follow up on your thought that "voters" need not equal "maintainers" [06:14] i'm not even comfortable with that [06:15] because we might ultimately have committers with fairly narrow commit rights [06:15] depending on how good we can get hct [06:15] we might, for example, give upstream guys all commit rights in the packages that they upstream code lives in [06:15] im not sure that should give them a say in who sits on your tech board [06:16] vs, say, a doc guy who has put in a lot of work on the wiki and website === mako nods [06:16] what the website currently says is "a vote amongst the maintainers" [06:16] I guess if that's the sort of thing we will be voting on, then yes, it should be more exclusive [06:17] 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] that's the only process we have that involves a vote [06:17] for the moment, i think the best plan is to make the big contributors maintainers [06:17] and have them agree not to touch code [06:18] so for the moment it's fairly binary [06:18] and the issue I raised with that is that it places a fairly strong technical burden on them, i.e. key management [06:18] (oh, and they can agree not to upload at all) [06:18] but they still kep their vote === mako agrees with sabdfl [06:18] later on, when we have better tools both for objective review of community participation, and code control, we can tune it [06:19] 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] if we had doubts, i suppose we could offer maintainership explicitly without upload capability === sivang [~dannyh@80.179.93.130.forward.012.net.il] has joined #ubuntu-meeting [06:20] sivang: hey there [06:20] 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] sivang: you'll want to read the logs of this meeting [06:20] mdz: that sounds reasonable [06:20] sivang: i can bring you up to speed aftewards as well [06:20] sabdfl : so I've heared :) [06:20] it's a simple way to get started [06:21] mako, sabdfl: I already told him the short-short version [06:21] ok [06:21] can i hear back from elmo, mako, kamion on this: [06:22] - we'll allow maintainers not to be in the upload keyring if they don't really need to be [06:22] - we'll approve some non-code contributors as maintainers, so they have a vote where it counts [06:22] - when we have hct / bazaar we can fine tune these [06:22] ? [06:23] works for me [06:23] that sounds fine [06:23] ok by me [06:23] mako : thanks [06:23] done [06:24] 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] anyone want to weigh in on those three? [06:26] Enrico's a reasonable Debian developer, he might not be limited to just docs === mako nods [06:26] but those three are certainly fine AFAIAC [06:26] ok [06:27] Enrico's not on MaintainerCandidates? [06:27] nope [06:27] he's the doc team secretary [06:27] seems sane to offer him the upload option, and a vote [06:28]