[07:48] @time Singapore [07:48] Current time in Asia/Singapore: October 21 2008, 14:48:37 - Next meeting: Community Council in 4 hours 11 minutes === asac__ is now known as asac === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Community Council Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 21 Oct 14:00: Technical Board | 21 Oct 15:00: Server Team | 21 Oct 17:00: Kernel Team | 22 Oct 17:00: QA Team | 22 Oct 22:00: Platform Team [11:56] hi elmo [11:57] I pinged mako, sabdfl won't make it [11:57] Technoviking: are you up already? :-) [11:57] Burgundavia is not around yet [11:57] and mdke won't be able to attend, he's at work [11:58] only item on https://wiki.ubuntu.com/CommunityCouncilAgenda is: 'Is there a need to coin a new phrase for an "Ubuntero"? discussion' [12:00] there's a few suggestions on bug 272826 already [12:00] Launchpad bug 272826 in ubuntu ""Ubuntero" inappropriate for female contributors" [Wishlist,New] https://launchpad.net/bugs/272826 [12:01] if we can't reach quorum, I'd be happy to chase up everybody and come to a conclusion on the bug itself [12:01] elmo: WDYT? [12:01] sorry, just finishing up another meeting [12:01] let's wait a few then, np [12:02] dholbach: since we're clearly not quorum, I think chasing it out of band is probably a good idea [12:02] (unless anyone here has anything to contribute right now) [12:02] I personally wouldn't mind getting the input of all CC members on this one instead of just the input of the few who could make it [12:03] I have a question about something that I may raise at a later point, if you'll allow me. [12:03] james_w: sure, go ahead [12:03] If we are unhappy with the behaviour of someone on launchpad, would that be a matter for the CC, or the LP admins? [12:04] james_w: did somebody try talking to that person already? was there any of the team councils involved in discussions already? [12:05] generally, I'd prefer if we can reach out and talk to people before LP admins start deactivating accounts or something [12:05] I haven't asked around much yet, I'm not sure that there is an appropriate team council, hence asking the CC [12:05] oh yeah, it was more a question of whether the CC would just direct me straight to the LP admins to discuss it with them. [12:05] james_w: could you mail some details to the CC list about it? [12:06] sure, it's a private list? [12:06] yes [12:06] cool [12:06] community-council@lists.u.c [12:06] thanks a lot james_w [12:07] It's not got to stay private if I pursue it, but I don't want to risk tarnishing the person's name at this point [12:07] as I said, I'd be happier if we start reaching out first [12:07] OK, let's adjourn the meeting - I'll chase up everybody to express their opinions on the bug report itself [12:08] thanks elmo [12:08] thanks dholbach [12:08] dholbach, if you have time, i'd like to have some advices from you [12:08] Rafik: is this something you want the Community Council to think about or is this unrelated to the CC? [12:09] this is also a question i'd like to ask :) [12:09] i'm writing, in private [12:09] ok, ask your question :) [12:09] ah ok [12:09] thanks [12:09] thank you [12:10] * dholbach will update the CC's TeamReport [12:10] Adjourned. [12:10] see you around :) [13:04] dholbach: lp admins don't like disabling accounts either [13:04] dholbach: FWIW :) [13:04] lifeless: I know === davmor2 is now known as davmor2_lunch === davmor2_lunch is now known as davmor2 === njpatel is now known as njpatel_away === ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 21 Oct 14:00: Technical Board | 21 Oct 15:00: Server Team | 21 Oct 17:00: Kernel Team | 22 Oct 17:00: QA Team | 22 Oct 22:00: Platform Team | 22 Oct 23:00: Forum Council === bazhang_ is now known as bazhang === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Technical Board Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 21 Oct 15:00: Server Team | 21 Oct 17:00: Kernel Team | 22 Oct 17:00: QA Team | 22 Oct 22:00: Platform Team | 22 Oct 23:00: Forum Council [14:53] elmo: ping? [14:59] #startmeeting [14:59] Meeting started at 08:59. The chair is mdz. [14:59] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [14:59] Keybuk: ping [15:00] mdz: here, on the phone [15:01] Keybuk: ETA? [15:01] sabdfl will not be attending the meeting, so it is just us [15:03] [LINK] https://wiki.ubuntu.com/TechnicalBoardAgenda [15:03] LINK received: https://wiki.ubuntu.com/TechnicalBoardAgenda [15:04] [TOPIC] Upload rights for pre-MOTUs [15:04] New Topic: Upload rights for pre-MOTUs [15:04] recently, we've started to explore the possibility of granting upload privileges at a fine-grained (package) level [15:04] for example, allowing a MOTU to upload certain packages to main in advance of becoming a core developer [15:05] this has been broadly well received, and while there is some work to be done on policy and documentation, it is reasonably straightforward to offer this [15:06] perhaps as a result of this, we've also now started to receive inquiries about upload privileges from people who are not Ubuntu developers at all (but may be Debian developers), who want to be able to upload certain packages [15:06] this is not at all as straightforward [15:07] MOTUs can be reasonably expected to have a good working knowledge of the Ubuntu project, its policies and procedures, as validated by the MOTU council [15:07] fine-grained upload privileges for packages in main are a natural extension of t his [15:08] however, for someone who is new to the Ubuntu project, we have no assurance of this [15:09] the consensus in the tech board was that, since these amount to requests to fast-track or bypass the existing process, we needed to discuss this with the MOTU council in order to take a view [15:10] why is sponsorship not an option in these cases? It ensures there is someone who is familiar with the project looking at each upload. [15:10] I haven't received feedback from the MOTU council on this yet, but have asked to schedule a meeting with representation from both the technical board and the MOTU council [15:10] james_w: I think it absolutely is an option, but it is not what has been requested of us [15:11] MOTU Council has been discussing this, but has not yet reached consensus. [15:11] yes, sorry, why do these people feel that sponsorship is not sufficient for them? Do you know? [15:11] it's possible that there is a communication gap, and that the requestors are not aware of all of the options; I haven't investigated that thoroughly [15:12] we are (I am) a bit backlogged lately on TB issues and have been slow to process this [15:12] james_w, It's to cover the case where someone routinely does *all* the uploads of only one or two packages. A historical example would be Yokozar, who eventually became MOTU, but only after much discussion. [15:13] I think there's no question that we want to find ways for people in this situation, who want to contribute, to do so [15:13] these are, based on the examples I've seen, people who have demonstrated competency in packaging (e.g. in Debian) and are interested in similar work in Ubuntu [15:14] it may be that, simply because they are accustomed to working in a per-package manner in Debian, they come to Ubuntu looking for a similar arrangement [15:14] whereas we more easily accommodate developers who are interested in contributing to the system as a whole [15:14] From what loose consensus is present in MC, I can say that we view it typically as an exception, with sponsoring being more common. We don't want to encourage an adoption of general per-package maintenance. [15:15] such people may be put off by our descriptions of what a MOTU or core-dev does, because it is broader than their interests [15:15] I can understand not wanting to go through the MOTU application process and all the work that that involves if they only have an interest in one package [15:16] persia: why not? (I'm not necessarily disagreeing, but am interested in the rationale) [15:16] but if we are going to let them upload that package without supervision then why not just have a sponsor do cursory checks, that the package is appropriate for the point in the release cycle, etc? [15:17] mdz, I can't speak for the council for rationale, but personally, I believe it is a perception of value of a team approach, and wanting to continue to avoid the concept of maintainer-lock. [15:17] In the case of Roman, he was sponsored by siretart, who made the request for the upload rights, so was the sponsorship requirement slowing things down? [15:17] james_w: perhaps the sponsorship process can be a bit cumbersome compared to directly uploading (filing bugs, attaching patches, etc.) [15:17] james_w: if only we just had everything in revision control so it could be easily reviewed and merged...;-) [15:18] if only... :-) === njpatel_away is now known as njpatel [15:18] persia: I think avoiding maintainer-lock continues to be desirable and healthy, but does it actually conflict with what these developers want? [15:19] persia: is there an indication that they would expect to have an exclusive lock on that package? [15:19] I think not, as long as it is clear to them that they don't. === dholbach_ is now known as dholbach [15:20] mdz, The concept of exclusive lock has been discussed previously by regular serial uploaders, but I have not heard of any expectation for either the current candidates or the historical cases. [15:20] we should certainly try to avoid clashing of uploads etc., but that seems orthogonal to whether someone happens to work on one package or many [15:20] Again, I'm sharing some portions of a pre-consensus state, so it's certainly not complete. [15:20] Certainly. As much as anything it's about documenting the right properly. [15:20] after all, we could easily have the same problem with two MOTUs, for example, and it may have even happened before [15:20] I personally think it's fine that people will upload one package or packages of a certain genre, but when they apply for the 3rd or 4th time (for another package or another set), they probably have enough experience to join MOTU instead [15:21] Or if not, something else probably went wrong. [15:21] if I ask the question: would Ubuntu be better off with these uploads than without them? the answer seems clearly to be yes [15:22] but there are valid concerns about the process [15:22] Except in rare cases, "Yes" is the likely answer. [15:22] as dholbach points out, we do want to encourage and enable people to make a broader contribution if their interests expand [15:22] in the first case I understand why the person isn't pursuing rights to upload these packages to Debian, but can't we encourage most people to contribute their work on single packages to Debian through the DM scheme? [15:22] for me, the question is more: if we allow someone access to upload one package in universe, why wouldn't we allow them access to upload any? [15:22] however, if they've been uploading on their own, they won't have received any feedback, and how will we evaluate whether they should be accepted into MOTU? [15:23] james_w, Some packages need to have persisting variance. A common solution to embed this in the source in a sync-compatible way is yet to be well advertised. [15:23] sponsorship is not just about enabling contributions; it's what gives us insight into the quality of someone's work [15:23] Keybuk: from a process point of view they will have a harder time to demonstrate their technical ability when they just worked on one package [15:24] Especially for a package with a particularly well behaved upstream. [15:24] persia: ok, but to me that just makes the cases where this would be appropriate be even more exceptional. [15:24] how do they demonstrate their technical ability to work on that package in the first palce? [15:24] it's interesting that the requests are coming from Debian developers. in some sense, they could just request syncs rather than upload [15:24] james_w, Correct. [15:24] mdz: I wonder how much of this is the need for a sense of ownership [15:24] and maintainer lock [15:24] Keybuk: I do as well [15:24] perhaps what we need to do is talk to them about what they're really after [15:25] Keybuk: in cases of people who just care for one or two packages (let's call them "upstream MOTUs"), I'm more intersted how much they really maintain (in the true sense of the word) the package: work on bugs, work on forwarding them upstream talking to upstream, etc. [15:25] I took the requests at face value at first, but the discussion is leading me to want to dig deeper [15:25] Keybuk: if the end result is that they upload simply new upstream versions with less bugs, I'm happy :) [15:25] dholbach: why can't we do that within the bounds of the existing sponsorship process [15:25] and use that as proof of their technical ability to become a full MOTU? [15:26] Keybuk: because, as dholbach points out, their work on a single package might not provide enough information for the MC's selection process [15:26] Keybuk: we have done that before (YokoZar is a good example) - it turned out to take longer to demonstrate experience with packaging, etc. [15:26] Keybuk: someone who just serially uploads new upstream versions wouldn't really demonstrate much ability [15:27] YokoZar is the perfect example of the sort that we want to use such a mechanism. For Debian developers, it's a little more confusing why they would want it. [15:27] someone who just serially uploads new upstream versions, to my mind, requires sponsorship to ensure they're following our procedures and policies [15:27] they're unlikely to be reading our mailing lists, learning about our changes and habits [15:27] ? [15:28] Q-FUNK: thanks for joining us [15:28] persia: I think Yokozar is more an example of people thinking it wasn't possible to be MOTU based on experience with a single package. [15:28] Keybuk, That's one of the reasons why many uploads to a small number of packages has historically not been a good path to MOTUship. [15:29] ScottK, Yes, but it would have been nice to let him upload wine a year or so before he became MOTU. [15:29] mdz: I was just pointed to the agenda. let's continue. [15:29] Q-FUNK: it would help us discuss the issues if you could tell us about your reasons for wanting upload rights to Ubuntu: what do you want to do in Ubuntu? [15:30] persia: My vote would have been to make him MOTU the first time he applied, but we're wondering off the topic I guess. [15:30] mdz: understood. it mainly is that SRU for packages I maintain, especially the Geode X driver and dictionaries, keep on lagging behind when it coes to uploading fixes. [15:30] so far, SRU diffs tend to be approved quickly, bjut there's always ubuntu+1 to prepare, which means that Hardy work lags behind. === sme2k8 is now known as andre [15:31] Q-FUNK: that's interesting and unexpected [15:31] Q-FUNK: so you actually don't plan to work on the current development branch at all, you only want to upload SRUs? === andre is now known as Guest59742 [15:31] it would thus be simpler if I could upload approved SRU directly, rather than wait for X and language pack teams to find a minute away from ubuntu+1 and upload for me. [15:32] mdz: I might get involved on the development branches too, whenever appropriate. [15:32] my main concern is with how too many SRU remain unuploaded for too long and how it prevent hardware support issues from being adressed in a timely manner. [15:34] Q-FUNK: ok, that's a very different issue then, and one which wouldn't be very well addressed by an upload ACL [15:34] my secondary concern is with things like http://packages.qa.debian.org/r/rus-ispell/news/20081002T091712Z.html requiring swift actions on development branches too. [15:35] Q-FUNK: if SRUs take too long, then an ACL would only solve that problem for you, not for anyone else [15:35] for the above debia bug (also affects intrepid), dholbach already replied that the required build-dep wasn't in intrepid yet for this to be fixed. [15:35] if those contributions aren't being reviewed and sponsored effectively, I would rather fix that underlying problem than try to work around it [15:36] mdz: that would also work. agreed. personally, I see that X and kernel driver issues for LTS releases often remain unanswered for too long, or receive generic "try our latest and greates upcoming release" boilerplate replies which solve nothing. [15:36] it's true that a great majority of our work is focused on the upcoming release rather than maintenance of stable releases [15:37] I don't think there's a good focal point for that work either, such as a stable maintenance team [15:37] one thing that I would like to see is a team that is dedicated to LTS release issues, such as SRU and unanswered kernel driver bugs. if I can contribute anythingto that by taking the lead, I'd love to. [15:37] sync :) [15:38] I think it would be a good idea to bring together developers who are particularly interested in LTS maintenance [15:38] that's an issue I already mentioned to mpitt and hemo at IDS Intrepid in Prague. LTS needs its own dedicated team. [15:39] dholbach: what do you think about that? [15:39] mdz: I think it makes perfect sense [15:39] not directly related and more of a btw than anything else: [15:39] rushing gvfs into Hardy, when it's meant as an LTS release and gvfs was still uncooked, also relates to the sort of separate agenda I think would matter for LTS releases. [15:40] I'd also rather see more focus generally on stable updates than using ACLs to work around the issue. [15:40] we have lots of people who start doing development and think about "how do I fix in ?", people who triage those bugs, etc [15:40] Q-FUNK: let's take one thing at a time and try to stay on topic [15:40] any way I can be made to start or launch an LTS maintenance team, with guidance from existing core-dev, then? [15:40] we have several more agenda items we need to cover [15:40] öö.. start or join [15:41] ok [15:41] dholbach: would you be able to spend some time helping to set up such a team and gather people interested in stable maintenance? [15:41] can we put the issue of a separate LTS team for the next meeting, then? [15:41] mdz: I'll get working on that [15:42] Q-FUNK: you can work with dholbach on that, I think it's a fine idea. The question of what goes into an LTS release is a separate one, though, and can't be dealt with by a single team as it affects everyone [15:42] dholbach: please keep me in the loop by e-mail. I do debian/ubuntu work in my spare time and don't follow the mailing lists. :) [15:42] dholbach: ok, thank you [15:42] Q-FUNK: will do [15:42] * dholbach hugs mdz [15:42] cheers! :) [15:42] [ACTION] dholbach to work on setting up a stable maintenance team and gathering interested developers [15:42] ACTION received: dholbach to work on setting up a stable maintenance team and gathering interested developers [15:42] * Q-FUNK hugs dholbach [15:42] * dholbach hugs Q-FUNK back [15:43] siretart: are you here? [15:43] mdz, skipped stgraber ? [15:43] I'm curious about the circumstances of the emacs-snapshot case as well [15:43] ogra: I haven't skipped anything, we are on the very first agenda item [15:43] ogra: and 45 minutes into the meeting [15:43] oh, i thought that was done :) [15:44] (with aboves action) [15:44] ogra: siretart requested a similar arrangement for emacs-snapshot for Romain Francoise [15:44] ah [15:44] sorry ... [15:44] in that case, the rationale was also to avoid sponsorship delays [15:44] * ogra crawls back into corner keeping quiet [15:44] "Granting him upload access to ubuntu for this package would eliminate sync delays to intrepid" [15:44] dholbach: could you try to find out the cause of the delays and whether there is a better way around this? [15:45] we need to move on, I'll respond to Reinhard by email [15:46] [ACTION] mdz to follow up on Reinhard Tartler's request for emacs-snapshot upload ACL for Romain Francoise [15:46] ACTION received: mdz to follow up on Reinhard Tartler's request for emacs-snapshot upload ACL for Romain Francoise [15:46] mdz: I'll do that [15:46] [TOPIC] Limited main upload rights for Stephane Graber [15:46] New Topic: Limited main upload rights for Stephane Graber [15:46] * ogra crawls back out of the corner :) [15:46] [LINK] https://edge.launchpad.net/~stgraber [15:46] LINK received: https://edge.launchpad.net/~stgraber [15:47] the list of packages is italc, ltsp, ltspfs, ldm [15:47] stgraber would like to take over ltsp maintenance from me, he now works full time for a company on ltsp so can demote more time to it than i even can remotely [15:48] i think the recent intrepid uploads alone i sponsored for him prove the quality of his packaging skill (all went in untouched by me) and his interest [15:48] ogra: I thought stgraber was already a MOTU [15:48] nope [15:49] I only have one of my package in Universe and this one is now in Debian so I never had the need to upload something in Universe for a release or so [15:49] ogra: have you considered recommending him for MOTU? [15:49] i sponsor his uploads since a year or so regulary [15:49] (and so never felt the need of asking for MOTU as I don't think someone uploading only a single package should get MOTU membership) [15:50] (a single package in Universe that's) [15:50] Based on recent feedback for other candidates, I think it likely he'd get rejected for exactly that reason. [15:50] the main interest was to get him upload rights for ltsp and friends far *before* RC which sadly didnt happen yet, but ltsp really suffers from me having not enouch time for it [15:50] hmm, I thought we'd avoid another lengthy topic, but it sounds like perhaps not [15:51] ScottK: yeah, why I never asked :) I work for a company doing LTSP and educational stuff so my interest is in LTSP, iTalc and educational packages and all of these are in Main, not Universe [15:51] i wil have even less time for ltsp in jaunty by the looks of it, since ubuntu-mobile suddely gains lots of community attention [15:51] I think that scope of packaging work is not a good reason to reject someone for MOTU [15:51] knee-jerk reaction: I'd prefer not to short-cut someone straight into main, bypassing universe, and only with an ACL for a couple of packages [15:51] in and of itself [15:51] sounds like the problem I encountered a couple of years back. working on packages that are mostly in main, but only on these packages and not on ubuntu as a whole. [15:51] mdz: I agree, but that's what MC has been doing. [15:51] again, the reasons for having MOTU are not just technical, but a matter of community and practice as well [15:52] on a sidenote i'd like to point out that sabdfl gave a +1 by mail on the initial request sent to the TB ... though there wasnt the above discussion back then [15:52] if a developer does good quality work, and understands Ubuntu development practices well enough to be granted unsupervised upload rights, why should they not be MOTUs? [15:53] mdz, is tkamppeter MOTU ? [15:53] Not any more. [15:53] * ogra wasnt aware [15:53] ogra: yes [15:53] still? [15:53] Joined on 2007-12-12 [15:53] persia: he is still a member of that team === Guest59742 is now known as sme2k8 [15:54] persia: he was temporarily core-dev with a limited mandate for certain packages, and that was migrated to an ACL [15:54] Why was that not changed when he was removed from core-dev? Does that require separate action? [15:55] Alternately, is there a reason that the TB believes he shoud be MOTU? [15:55] persia: till was approved as a MOTU ages ago, there is no reason to question that [15:56] Well, I questioned it then, but I'll quiesce about it again. [15:56] persia: he was accepted as a MOTU ages before the ACL change [15:56] persia: I'm confused [15:56] persia: the MOTU council recommended him for core-dev in fact, but the TB elected to go with a more limited grant [15:56] are you questioning his right to be a MOTU? [15:57] are you questioning his conduct as a MOTU? [15:57] or are you suggesting that anyone granted core-dev should lose their MOTU membership? [15:57] this is completely off-topic I'm afraid [15:57] yes [15:57] I'm not formally questioning his conduct. It's off topic. [15:57] to come back to stgraber, I feel that the right thing to do is to support him in joining MOTU [15:57] and doesnt solve the prob that the massively regressed quality of ltsp in hardy got is a very bad community reputation which s the main point of my request [15:57] Forgetting the specifics, the question is really: is "MOTU" a wide group of developers, some of whom never upload to universe, or the set of people who upload to universe, who participate as part of the development team? [15:58] Essentially, while stgraber could apply for MOTU, if he's only working on main packages, the definition of MOTU in the eyes of the TB is important if the TB is expecting MOTUship prior to his grant. [15:58] there is a person who is willing to take care, has the skills and provides good quality packaging for it which is would like to be able to upload on his own [15:58] persia: it is both (hence the implicit membership core-dev has in MOTU) [15:58] *which is why [15:59] * mathiaz waves [15:59] o/^ [15:59] mdz: more accurately, ubuntu-core-dev and motu are both members of the ubuntu-dev team [15:59] the quality of intrepid is far beyond the one in hardy only because of stgraber [15:59] ogra: and that is to be commended [16:00] and my time is more and more limited to mobile tasks [16:00] stgraber has positive feedback from his sponsor, has demonstrated commitment to the project...why shouldn't he be considered? [16:00] and it sounds that both mdz and I would support his application to MOTU [16:00] which ends up in sponsored uploads being delayed etc === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Server Team Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 21 Oct 17:00: Kernel Team | 22 Oct 17:00: QA Team | 22 Oct 22:00: Platform Team | 22 Oct 23:00: Forum Council [16:00] and would be surprised if the MC did not [16:00] Keybuk, Which makes me wonder about requiring (or expecting) MOTU for those who don't touch universe. [16:00] * kirkland finds this conversation very familiar [16:00] persia: MOTU is also a training ground [16:00] well, I can't take a stance first-hand on his application, I'm only comparing superficially to other applications I've seen approved by the MOTU Council [16:01] mdz: if I may pop my head out for a second, I face a similar issue. I focus on maintaining specific packages, most of which are in main, thus why MOTU would be a nice test of community spirit, it does not come with the right upload rights to focus on packages in main. [16:01] Q-FUNK: that is deliberate [16:01] öö.. s/why/while [16:02] Keybuk, I understand, but it's about the shape of the graph. Ubuntu-dev = + is different than = + [16:02] o/ [16:02] persia: I suppose it depends on whether you see it as a responsibility or a privilege [16:02] well, it depends how the motu council sees it :) [16:02] persia: I don't see that there's any difference [16:02] imho you are expected to at least help with merges and syncs at the beginning of a cycle if you are motu [16:03] Keybuk: right, except that getting MOTU status gives me rights to upload to somewhere my packages don't belong, which is useless to me. heck, as a direct result, I cannot prove my deeds by starting in universe so, by default, never get to ACL or core-dev to take care of my packages in main. [16:03] mdz, Yes. I'm personally flexible either way, but I think either it should be explicit that MOTU is not necessarily related to universe, or there should not be an expectation of MOTUship for those applying for limited upload to main. [16:03] well, I actually never thought I should apply for MOTUship because I'm not touching any package in Universe anymore, so getting Universe upload right wouldn't make any difference, I would just wait some months and ask again for main upload rights [16:03] which means that there are responsibilities coming with the privilege [16:03] hey all [16:03] persia: I think the "developer" aspect of MOTU is (should be?) much more important than the "universe" aspect [16:03] mdz: you named it ;) [16:03] The server team community meeting should have started 3 min. ago, can this discussion be moved to another channel? [16:04] but there is a community requirement going hand in hand [16:04] is work in main less of a community effort? [16:04] .oO(wasnt the TB booked for 2h ?) [16:04] ogra: once upon a time it was [16:04] ah [16:05] ogra: mathiaz asked me if I saw a conflict between TB and the server team meeting at this time, and I said no [16:05] we have to many teams if it gets tight in -meeting :) [16:05] because we'd been finishing on time for quite a while [16:05] mdz, OK. I just wonder if upload access to universe is useful for those that do not intend to use it. I'm happy focusing on development and ignoring universe. Thanks for the clarification. [16:05] it looks like I was wrong [16:05] persia: you're not looking at the motu team in the same way we do [16:05] persia: same here. [16:05] persia: I think we need to take this to email and involve a lot more people [16:06] Keybuk, Right, which is why I sought clarification. [16:06] persia: I'd prefer to ask the question of MOTUs what the team means to them than to have the TB issue some official decree [16:06] persia: for us, grant of the privilege to upload to "main" - the set of packages installed by default on many people's machines and their related packages, is a privilege earned by demonstrating good work in the rest of the archive [16:07] [ACTION] mdz to start a discussion thread on the role of the MOTU team in the project and implications for new developers joining [16:07] ACTION received: mdz to start a discussion thread on the role of the MOTU team in the project and implications for new developers joining [16:07] Keybuk, That makes sense to me. It doesn't make sense for the cases of Till or stgraber, where that isn't expected to happen. [16:07] dendrobates: I will finish up here very shortly [16:07] Email is probably better. [16:07] [TOPIC] Approach to ffmpeg in ubuntu, cf. siretart's email to technical-board@ [16:07] New Topic: Approach to ffmpeg in ubuntu, cf. siretart's email to technical-board@ [16:07] persia: Till was a MOTU before he was granted limited core-dev [16:08] It was never exercised. [16:08] siretart has asked the technical board for a policy statement regarding codecs in ffmpeg in Ubuntu [16:08] Keybuk: this mostly makes sense, except that the packages I work on are those I already maintian at Debian and they already are in main. what to do, then? [16:08] persia, it has to have been exercised if he became a MOTU [16:08] Q-FUNK: how would you maintain them differently in Ubuntu than you do in Debian? [16:08] persia, how else would he have become motu ;) [16:08] unsurprisingly, the TB are not legal experts or familiar with the alleged intellectual property claims [16:08] Keybuk: please, let's take it to email and free up the channel for the server team [16:09] so I've sought advice from Canonical's legal counsel and will respond when I have more information [16:09] Keybuk: similar methods, but more community-oriented in Ubuntu - since there's no package ownership per se in Ubuntu. [16:09] [TOPIC] cdrtools update [16:09] New Topic: cdrtools update [16:09] we seem to be very close to a cdrtools package which has Eben Moglen's blessing [16:09] wow [16:09] we're just waiting for a few final clarifications from Eben and from Joerg [16:10] mdz: which worries me ;) [16:10] I'm not sure which immovable force has been moved [16:10] assuming the two of them can be satisfied with the same text, we will be able to go ahead [16:11] Keybuk: I can tell you about that later [16:11] [TOPIC] AOB [16:11] New Topic: AOB [16:12] any urgent business before we turn over to dendrobates? [16:12] ok, thanks all [16:12] #endmeeting [16:12] Meeting finished at 10:12. [16:12] dendrobates: apologies for running over [16:12] * nealmcb figures AOB is Any Other Business :) [16:12] hello [16:12] mdz: np [16:13] let's get the server team meeting started [16:13] #startmeeting [16:13] Meeting started at 10:13. The chair is mathiaz. [16:13] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [16:13] o/ [16:13] o/ [16:13] \o [16:13] Today's exceptional agenda: https://wiki.ubuntu.com/ServerTeam/Meeting [16:14] Last week minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20081014 [16:14] [TOPIC] python-vm-builder [16:14] New Topic: python-vm-builder [16:14] So I've started to look at python-vm-builder. [16:14] And did a lot of testing. [16:14] Things are in good shape. The last bit I'm testing is the ec2 plugin. [16:15] I'm able to boot an instance, but not able to ssh in [16:15] did you install ssh? [16:15] nijaba: thanks for all the hard work you've put in fixing the bugs [16:15] zul: yes. [16:15] zul: I may ask some help later on this part. [16:15] mathiaz: a learning treasure and pleasure while soren was away [16:15] mathiaz: okies [16:16] soren: did you have some time to review all the changes to vmbuilder? [16:16] soren: do you want to do the upload? [16:18] I'd like to to the upload, but I've not caught up yet. [16:18] I still have 25 commits to look through. [16:18] soren: ok - the deadline is thursday [16:18] * soren nods [16:18] soren: IMO we'll have to ask for a FFe as we're introducing the ec2 public.; [16:18] soren: other than that everything looks like bug fixes [16:19] soren: yeah nijaba has been a busy little beaver [16:19] mathiaz: Sort of. [16:19] mathiaz: The ec2 plugin is already in the version in the archive. [16:19] mathiaz: ec2 plugin was there in v2 [16:19] ah - hm- ok then [16:19] mathiaz: we added missing parameters, to fix bugs [16:19] then I don't think we've added new features [16:20] mathiaz: I had to refrain myself ;) [16:20] that's all I have on vmbuilder [16:20] zul: nijaba: anything else? [16:20] mathiaz: nope [16:20] So is the ec2-ami-tools upload that was just done only bugfix? [16:21] nope [16:21] mathiaz: nope [16:21] the ec2-ami-tools was the tools for ec2 [16:21] ScottK: but this had its own ffe [16:21] ScottK: which upload? [16:21] New package: ec2-ami-tools (multiverse) [1.3-26357-0ubuntu3 → 1.3-26357-0ubuntu4] [16:22] The ubuntu4 one [16:22] thats me...I just uploaded a typo fix in a patch [16:22] zul: OK. I'll ask to get it accepted then. [16:22] k thanks [16:23] ok. There are other things than need to be fixed. [16:23] zul: what did you fix? [16:23] mathiaz: the upload bundle ruby script was pointing to the wrong directory [16:23] I've noticed that there is a curl dependency missing as well as a fix in the point-to-right-location patch [16:24] zul: ok - that's the second fix I'm talking about [16:24] ScottK: I'll do another upload to fix the curl dependency [16:24] uhhh...ok [16:25] that's all from last week minutes [16:25] anything else to add? [16:26] nope - let's move on [16:26] [TOPIC] iscsi support for interpid [16:26] New Topic: iscsi support for interpid [16:26]