[14:59] <Keybuk> cjwatson, mdz: ping
[14:59] <mdz> hi
[15:00] <cjwatson> here
[15:00] <Keybuk> I've just /msg'd sabdfl
[15:00] <siretart`> hm. me is here as well, but need to leave for another meeting here at my job
[15:00] <Keybuk> siretart`: no problem, randa informed me that you'd need to leave earlier
[15:01] <Keybuk> cjwatson: you chaired the last meeting, right?
[15:01] <siretart`> in case that I don't manage to return before the end of the TB meeting:
[15:01] <cjwatson> I think so. Did I forget to do notes?
[15:01] <Keybuk> I can't see any notes since ~March
[15:01] <cjwatson> whoopsie
[15:01] <siretart`> I'd like to suggest to promote x264. it is clean license wise but implements an mpeg4 encoder
[15:01] <cjwatson> I'll sort that out, then, sorry
[15:02] <Keybuk> siretart`: Codecs in ffmpeg has been on the agenda before, and without the notes I can't remember what's left to discuss
[15:02] <siretart`> if we could promote it from multiverse to universe, then vlc and 'ffmpeg' (without -debian) could be promoted as well
[15:02] <cjwatson> multiverse/universe is purely a question of licence, not patents, AFAIK
[15:02] <cjwatson> that can be done with a simple bug, subscribing ubuntu-archive
[15:02] <siretart`> oh, I understand that x264 should be promoted then? - great, I'll file a bug then
[15:02] <siretart`> thanks!
[15:03] <cjwatson> I haven't looked at it, but from your description it sounds OK
[15:03] <cjwatson> I don't think we really discussed this at the last meeting, anyway
[15:03] <cjwatson> it was a carry-over
[15:03] <Keybuk> ok
[15:03] <cjwatson> but if there's nothing urgent we can probably move on ...
[15:04] <Keybuk> siretart`: was that sufficient? or was there anything else on that topic?
[15:05] <Keybuk> guess he's moved on
[15:05] <Keybuk> so we'll do the same
[15:06] <Keybuk> mdz: you've added an agenda item about the ubuntu-drivers team
[15:06] <Keybuk> which is something of a magic glue team for Launchpad privileges
[15:07] <mdz> right
[15:07] <mdz> so this came up as a result of the kernel team having difficulty with bug nominations
[15:07] <mdz> rumour has it that this is controlled by the ubuntu-drivers team
[15:07] <mdz> but I have more or less lost track of what privileges that team actually has
[15:07] <mdz> I'm pretty sure it's a lot more than just bug nominations
[15:07] <Keybuk> we'd probably need a Launchpad coder to confirm
[15:08] <mdz> the description of the team in LP says "This team needs a rethink after a discussion about privilege levels in Launchpad"
[15:08] <mdz> and I agree
[15:08] <cjwatson> I'm reasonably sure that something in blueprints is controlled by ubuntu-drivers too
[15:08] <Keybuk> cjwatson: targeting to sprints got separated out
[15:08] <cjwatson> and I certainly remember that the reason we had such trouble with that team was that the set of people we wanted doing feature planning work wasn't the same as the set we wanted doing bug nomination approval
[15:09] <mdz> so what I think needs to happen is an audit of 1) where ubuntu-drivers is used to fill a role, 2) what privileges are associated with those roles, 3) which role(s) can do what (e.g. nominate bugs)
[15:09] <Keybuk> the sprint Driver is now the team that can approve blueprint proposals for a sprint
[15:09] <mdz> then for us to reorganize how we do it around that
[15:09] <Keybuk> however it may be that the distro Driver is the team that can approve blueprint nominations for a distro release or milesstone
[15:09] <Keybuk> (do we use that?)
[15:09] <mdz> since sabdfl invented ubuntu-drivers, I think, I was hoping we could give this task to him, but he doesn't seem to be attending the meeting
[15:09] <Keybuk> I'm reasonably sure that the distro Driver is the team that can approve bug nominations for a distro release
[15:10] <cjwatson> note that one of the steps on NewReleaseCycleProcess is to set ubuntu-core-dev as the driver for the stable release
[15:10] <Keybuk> there's something to do with drivers in hwdb submissions as well
[15:10] <cjwatson> IOW ubuntu-drivers is the Driver for /ubuntu, and furthermore ubuntu-core-dev is also the Driver for /ubuntu/jaunty et al
[15:10] <cjwatson> (but not /ubuntu/karmic. Don't ask me, I didn't invent this)
[15:11] <Keybuk> EditSpecificationByTargetOwnerOrOwnersOrAdmins
[15:11] <mdz> we seem to agree that this needs clarification
[15:11] <cjwatson> let's delegate to sabdfl by mail? :-)
[15:11] <mdz> cjwatson: yes, but with a backup who will chase it
[15:11] <Keybuk> it seems to make more sense to just talk to the LP people directly?
[15:12] <cjwatson> Keybuk: sprints> oh good
[15:12] <Keybuk> to me, with a quick grep through the source, the distro drivers team is used in lots of surprising places
[15:12] <cjwatson> although I don't think it was just sprints
[15:12] <Keybuk> cjwatson: right, as I said above
[15:12] <Keybuk> sprint driver -> approve proposal for sprint
[15:12] <Keybuk> distro driver -> approve targeting to a release
[15:12] <mdz> Keybuk: if you're willing to take it on, I'd be grateful
[15:13] <mdz> so long as it gets documented somewhere, so we can get out of this paralysis of not knowing what effect our changes would have
[15:13] <Keybuk> I don't mind chasing this
[15:13] <cody-somerville> (Keybuk: its a trap)
[15:13] <mdz> Keybuk: ok, your action & we can move on?
[15:13] <Keybuk> ok
[15:14] <Keybuk> cjwatson: archive reorg
[15:14] <cjwatson> so I have three things here where I'd like TB decisions to be made. I'll take the simplest first
[15:15] <cjwatson> DebianMaintainerField: obviously <ubuntu-motu@lists.ubuntu.com> for universe/multiverse packages no longer makes as much sense in the new world order. Does anyone object to simply setting Maintainer to <ubuntu-devel-discuss@lists.ubuntu.com> across the board?
[15:15] <mdz> sounds appropriate to me
[15:15] <LaserJock> do we have an idea about how many devs are actually subscribed to -devel-discuss?
[15:16] <cjwatson> we copied the subscription db from ubuntu-devel when we created -devel-discuss, IIRC
[15:16] <cjwatson> I've got no problem with advertising it more widely and generally trying to do a better job of it
[15:16] <mdz> I don't even have the moderator password, no idea
[15:17] <LaserJock> ok, I just wondered in terms of the field being used to get in touch with maintainers if we'd lose some people
[15:17] <cjwatson> in practice I think it is not that frequently used as a contact address, but it's a useful general contact mechanism for upstreams who aren't especially well plugged into the Ubuntu community
[15:17] <cjwatson> we won't be changing Maintainer in any event until we do the full component changes anyway
[15:18] <cjwatson> at that point ubuntu-motu is likely to know about it :-)
[15:18] <mdz> cjwatson: we still get the occasional rant from folks who expect it to go to an individual responsible for the package concerned
[15:18] <Keybuk> cjwatson: as a contact address, it makes sense to me
[15:18] <LaserJock> ubuntu-motu currently gets maybe 1-2 "contacting the Maintainer" emails a week
[15:18] <mdz> which unfortunately is in conflict with the resolution with Debian
[15:18] <Keybuk> mdz: in the few cases we have an individual responsible, don't we already set it?
[15:18] <LaserJock> and almost all of them need to be redirected to the bug tracker
[15:18] <cjwatson> mdz: we do often set it to an individual
[15:18] <cjwatson> or a more appropriate list
[15:19] <cjwatson> for example, installer packages are mostly ubuntu-installer@
[15:19] <mdz> Keybuk,cjwatson: yes, the point is that most of the packages in Ubuntu don't have it set to an individual maintainer because there isn't one
[15:19] <persia> http://pileofstuff.org/ubuntu-survey/ is an unscientific summary of some polling about ubuntu-devel-discuss
[15:19] <cjwatson> mdz: right
[15:19] <Keybuk> mdz: most of the people complaining know who to contact anyway ;)
[15:19] <mdz> this concept isn't widely understood among users who are familiar with other distributions with a simpler package maintenance role
[15:19]  * Keybuk suspects you're thinking of one individual, particularly
[15:20] <mdz> Keybuk: not that I know of, I just see comments from time to time
[15:20] <cjwatson> I didn't really want to have a full discussion about the Maintainer field; this is merely evolution of what we have in place right now, and if -devel-discuss is a problem then it's already a problem for main
[15:20] <mdz> they email technical-board@ sometimes too
[15:20] <mdz> cjwatson: fully +1 on ubuntu-motu -> ubuntu-devel-discuss
[15:20] <Keybuk> +1 from me too
[15:20] <cjwatson> what should we do with the broader discussion? action to revisit when we're closer to actually making the change, or something?
[15:21] <Keybuk> "the broader discussion" being?
[15:21] <cjwatson> it's not really a TB matter, but if -devel-discuss isn't being effective as a contact then it's obviously a problem
[15:21] <mdz> I have no data either way
[15:21] <mdz> only anecdotes
[15:22] <mdz> there is very little content which I think is appropriate to send to Maintainer: rather than file as a bug
[15:22] <mdz> LaserJock: what sorts of "contacting the Maintainer" emails does ubuntu-motu get?
[15:22] <cjwatson> LaserJock: do the motu contacts generally end up being answered well?
[15:22] <LaserJock> I wasn't trying to say that -devel-discuss shouldn't be used, I just know of a number of devs you aren't subscribed so I was wondering if it should be promoted more
[15:22] <cjwatson> one thing I often get by various routes is questions about how to make some particular type of enhancement to a package
[15:23] <cjwatson> which often certainly isn't material for a bug report and answers.lp is not really ideal either
[15:23] <LaserJock> mdz: "please update package X" or "here's a fix for bug X" or "please fix bug X"
[15:23] <cjwatson> e-mail is just fine for that, if it actually gets answered
[15:23] <mdz> cjwatson: I'd say a mailing list is miles better than an individual for that
[15:23] <cjwatson> LaserJock: now, *those* are definitely bug tracker material
[15:23] <LaserJock> cjwatson: usually with a redirection to the appropriate place or a clarification of update procedures
[15:23] <LaserJock> occasionally we do have Debian Maintainers using it I think
[15:24] <cjwatson> mdz: right, by "I" I'm thinking of things I read on mailing lists
[15:25] <LaserJock> I would just suggest that maybe -devel-discuss might need some promotion among MOTUs when it's changed over
[15:25] <mdz> cjwatson: I think we can move on to the next topic of yours
[15:25] <LaserJock> but having 1 address for Maintainer contacts would be helpful I think
[15:26] <cjwatson> LaserJock: promotion> I agree; I'll note that in archivereorganisation/components
[15:27] <Keybuk> cjwatson: ok, next? :)
[15:27] <cjwatson> my next "simplest" topic was security support
[15:27] <cjwatson> there is a policy question here
[15:27] <cjwatson> right now our security team concentrates effort on main, and universe is a best-effort kind of thing
[15:27] <cjwatson> I don't think they're going to want to offer full security support for everything, just on workload grounds
[15:28] <cjwatson> what package sets do they offer elevated security support for?
[15:28] <cjwatson> (perhaps in terms of products)
[15:28] <Keybuk> cjwatson: I think that's a decision left to the Security team(s)
[15:28] <mdz> cjwatson: the ones corresponding to the seeds for first-tier products
[15:28] <cjwatson> is it? I thought it was higher-level than that
[15:29] <cjwatson> mdz: specifically? Ubuntu desktop, Ubuntu server, UNR, obviously - how about Kubuntu?
[15:29] <Keybuk> my understanding right now is that the security team use the seeds to decide
[15:29] <mdz> cjwatson: yes (same as they do now)
[15:29] <cjwatson> actually I'm slightly confused about the status of UNR here, since I think some of it is still in universe
[15:30] <jdstrand> not directly, we look at what binaries are in main
[15:30] <mdz> cjwatson: er, it is?
[15:30] <cjwatson>    maximus | 0.4.8-0ubuntu3 | karmic/universe | source, amd64, i386
[15:30] <persia> There's been no specific effort to put UNR in main.
[15:30] <persia> So anything not in main for other reasons is still in universe.
[15:30] <mdz> cjwatson: that's a bug
[15:30] <cjwatson> mdz: all well and good, but leaves me confused about status if the security team is currently working with main
[15:30] <cjwatson> jdstrand: what products do you believe you support?
[15:32] <jdstrand> basically, we'll use rmadison (or our own lpmad) and see if the source is in main. if it is and a vuln affects a binary from that source, we see if it is in main. if the binary is in main, we are responsible, if not, we are not
[15:32] <cjwatson> in the full awareness that this is probably a thorny topic, how about the education edition? bits of that are still in main
[15:32] <LaserJock> cjwatson: it's all in Main, and kees has done some work
[15:32] <cjwatson> so IMO the reorganisation is an opportunity to regularise this and make it easier to say to users that particular Ubuntu-based products/flavours/whatever are supported or they are not
[15:32] <LaserJock> i.e. Moodle
[15:32] <cjwatson> LaserJock: mm, yes
[15:33] <jdstrand> I'm not sure we are the ones to decide, cause 'support' sort is blurred between security support and Canonical support
[15:33] <jdstrand> at least in how I see it discussed
[15:33] <mdz> jdstrand: leave Canonical support out of it; we're talking "maintenance" here
[15:33] <jdstrand> of course, we'll certainly want input! ;)
[15:33]  * jdstrand nods
[15:34] <cjwatson> sorry, yes, I should have said maintained not supported
[15:34] <mdz> cjwatson: if the question is which packages the Canonical security team considers their highest priority, then I think we can make that a Canonical question rather than a TB question
[15:35] <mdz> cjwatson: from a TB perspective, anyone is welcome to provide updates for anything they like
[15:35] <cjwatson> mdz: yes, my question is which packages the Canonical security team considers high-priority
[15:36] <cjwatson> do you want me to raise this with you/somebody-else(who?) by mail?
[15:36] <mdz> cjwatson: ok, let's take that offline then, we should involve some Canonical stakeholders anyway
[15:36] <Keybuk> mdz: indeed, from my POV when I first proposed doing this, the point was to make it easier for community teams to provide support or maintenance to the archive on an equal footing to Canonical
[15:37] <Keybuk> cjwatson: ok, the last item?
[15:37] <jdstrand> mdz: sorry if I am just catching up, but are you saying that whatever packages are considered 'officially maintained' can be updated in a stable release by anyone with upload rights to the package after reorg?
[15:38] <mdz> jdstrand: I think I'm saying that the reorg doesn't change much here; our maintenance policy should be more or less the same on a package-by-package basis
[15:38] <cjwatson> jdstrand: at that level, there is no change to the rules; uploads to -security would still require vetting
[15:38] <mdz> but Colin has pointed out that we haven't defined that very rigorously and need to clean it up
[15:38] <jdstrand> ok
[15:38] <cjwatson> jdstrand: but since we can no longer say "everything in main is maintained" (since post-reorg nearly everything will be in "main"), we need a better definition
[15:38]  * jdstrand nods
[15:39] <cjwatson> my last item is to get general consensus on a process for approving the creation of new package sets, which is a responsibility that will rest with the TB
[15:40] <cjwatson> dholbach made a suggestion, which I'll paste here:
[15:40] <cjwatson> As Package Set creation will result in significant amount of work and organisation, we want to ensure the request is reasonable. All these decisions will be subject to TB approval. Requests for new package sets should be discussed in TB meetings and be accompanied withe following data:
[15:40] <cjwatson>     * Name of the package set
[15:40] <cjwatson>     * Purpose of the package set
[15:40] <cjwatson>     * Expected packages: ... (at least 5)
[15:40] <cjwatson>     * Expected developers working on the set: ... (at least 2(?))
[15:40] <cjwatson>     *
[15:40] <cjwatson>       Canonical Supported (if so, follow new equivalent of MainInclusionProcess)
[15:40] <cjwatson>     * Is the set likely to grow, change?
[15:40] <cjwatson> We want to make sure:
[15:40] <cjwatson>     * The software is well-maintained,
[15:40] <cjwatson>     * There's a clearly defined purpose of the package set and no uncontrolled wild growth,
[15:40] <cjwatson>     * There's no other convenient way of satisfying developers to work on this.
[15:41] <cjwatson> I actually think we can be a little less strict than that, because package sets should be a fairly lightweight thing; for example I see no problem in creating a package set for the printing packages that Till has been approved to work on, even if it's just Till
[15:41] <Keybuk> right, the most obvious thing from my mind was that "Canonical Supported" need not be in that process at all
[15:42] <Keybuk> Canonical should follow its own process for deciding what it will and will not support
[15:42] <Keybuk> which pretty much ties into the answer to the previous question
[15:42] <cjwatson> largely agreed, although I think it is in Canonical's interests to define what it supports in terms of package sets
[15:42] <cjwatson> but there is certainly no need to deal with that at package set creation time
[15:42] <Keybuk> the number of expected developers or packages don't really seem useful, and I'd expect any set to evolve over time
[15:43] <Keybuk> it strikes me that we need a set of bullet points like
[15:43] <Keybuk> https://wiki.ubuntu.com/UbuntuDevelopers#CoreDev
[15:43] <Keybuk> but for package sets
[15:43] <Keybuk> though those bullet points are possibly contentious as well
[15:43] <mdz> cjwatson: it seems logical to deal with it at package set creation time, though the person requesting the new package set shouldn't have to worry about that
[15:43] <cjwatson> in what circumstances would we delegate the authority to manage package sets?
[15:43] <Keybuk> the first one precludes a package set of badly maintained software that a team decides to care for
[15:44] <mdz> cjwatson: I don't think I can answer that question properly until I/we have more experience working with them
[15:44] <cjwatson> by which I mean to add or remove particular packages to or from a set
[15:44] <Keybuk> and the third is a bit odd, since only the way that developers can work on things is through package sets
[15:44] <mdz> I think this is a case where we should have everything come to the TB at first so that we can work out what's appropriate and delegate from there
[15:44] <cjwatson> ok, that's fine by me
[15:44] <mdz> this also means we don't need to decide all of the criteria up front
[15:44] <cjwatson> well
[15:44] <mdz> we should go through a few of these (maybe use our existing package sets to trial the process) and see what matters
[15:45] <cjwatson> I expect that we will want to delegate quite a lot to ubuntu-archive
[15:45] <cjwatson> since people aren't going to stop changing the seeds, or changing dependencies, and operationally life will need to go on
[15:46] <dholbach> the reason I came up with the requirements that cjwatson quoted was to make sure that the need for the package set is evident and will not be dropped and forgotten after the request was granted - but if you think otherwise that's fine with me
[15:46] <mdz> dholbach: I agree it's a good idea to vet new package sets
[15:46] <cjwatson> as I discussed with dholbach last week, to some extent I view package sets as a macro facility
[15:46] <mdz> I'm just unsure that we should block on agreeing how we'll do the vetting
[15:46] <LaserJock> do new packages to a package set need to be approved by the TB? (something along the lines of a MIR)
[15:47] <LaserJock> *to an existing package set
[15:47] <cjwatson> LaserJock: that was where my comment about ubuntu-archive came in
[15:47] <cjwatson> moving packages between package sets is analogous to component moves, IMO
[15:47] <cjwatson> at least to start with
[15:49] <cjwatson> there are two questions about delegating authority for package sets, which need to be thought of separately: one is adding/removing packages to the set; the other is managing the set of people who can upload packages in that set
[15:49] <cjwatson> I think we should delegate the former to ubuntu-archive for the time being; mdz, Keybuk, do you agree?
[15:49] <mdz> cjwatson: yes
[15:49] <Keybuk> yes I agree
[15:49] <cjwatson> the latter is equivalent to granting upload privileges, and that's a more complicated question
[15:49] <cjwatson> rather, granting the ability to grant upload privileges
[15:51] <mdz> cjwatson: so what do you need in order to move forward?
[15:51] <cjwatson> if nobody has any firm ideas there, I'd be happy to say that the TB will continue to be the only body able to grant upload privileges for the time being, and that we will decide on delegation once we have more experience with package sets
[15:52] <cjwatson> knowing that you are not concerned about defining criteria for new package sets up-front is useful information in itself
[15:52] <persia> So, MC should push all applications to TB for final review after collecting the information?
[15:53] <mdz> cjwatson: I have only general ideas; I think the decision should take into account the packages, people and products involved, the upload permission changes which would result, etc.
[15:53] <cjwatson> Keybuk's suggestion of something like UbuntuDevelopment#CoreDev strikes me as a good one
[15:53] <cjwatson> persia: what kind of applications? new developer applications?
[15:53] <persia> Yes.
[15:53] <mdz> the creation of a new package set is essentially delegating upload privileges for a set of packages, right?
[15:54] <cjwatson> mdz: in the general case, yes, but I believe we will start out by having each new package set owned by the TB
[15:54] <mdz> what sort of controls will be in place for adding new packages to a set, to avoid unexpected changes in upload permissions?
[15:54] <cjwatson> hm, or possibly by ubuntu-archive+TB
[15:54] <LaserJock> is there a definition of what a package set should be used for? like, should be it be used to create a product/metapackage or is carving out maintenance teams OK as well?
[15:54] <cjwatson> LaserJock: both
[15:55] <cjwatson> LaserJock: ArchiveReorganisation on the wiki has more details
[15:55] <mdz> LaserJock: basically, any situation where a group of packages should have different governance
[15:55] <dholbach> regarding package set creation: is "add list of initial packages and uploaders to TB agenda" enough for a process right now?
[15:56] <dholbach> mdz: as I see it adding a package set won't change upload permissions of others that can already upload those packages
[15:56] <cjwatson> dholbach: change permissions> that is correct
[15:56] <mdz> dholbach: AFAIC, yes
[15:56] <persia> Well, except in the case of the creation of a restricted package set.
[15:57] <cjwatson> dholbach: process> I think that's what I'm hearing, yes
[15:57] <mdz> dholbach: (that was to your first question...yes that is enough of a process, in my opinion)
[15:57] <cjwatson> and we will deal with anything more that arises case-by-case, for no
[15:57] <cjwatson> w
[15:57] <cjwatson> that concludes my questions
[15:58] <dholbach> OK great, I'll make a note to make sure it's documented somewhere once we move to the new process
[15:58] <mdz> any other business?
[15:58]  * mdz eagerly anticipates an on-time conclusion
[15:58] <cjwatson> dholbach: no need, I'll take an action to do it on archivereorganisation/permissions
[15:58] <Keybuk> mdz: hey, who's chair? :)
[15:58]  * dholbach hugs cjwatson
[15:59] <Keybuk> AOB?
[15:59] <persia> One more note on ArchiveReorg: with karmic underway, is this only waiting process definition, or will it likely be delayed until new archive open to avoid mid-cycle confusion?
[15:59] <Keybuk> no, good
[15:59] <Keybuk> thanks all
[15:59] <cjwatson> persia: the former; since we're only doing permissions this cycle, it doesn't need to be synced
[15:59] <persia> cjwatson, Thanks for the confirmation.
[16:03]  * mathiaz waves
[16:03] <sommer> o//
[16:03]  * pschulz01 waves hello.
[16:03] <ttx> \o
[16:04] <mathiaz> if the Technical Board meeting is over, let's get the Server team started
[16:04] <zul> heylo
[16:04]  * RoAkSoAx saluda :)
[16:05] <kirkland> mathiaz: o/
[16:06] <mathiaz> all right - let's get started
[16:06] <mathiaz> #startmeeting
[16:06] <MootBot> Meeting started at 10:06. The chair is mathiaz.
[16:06] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]

[16:06] <mathiaz> today's agenda: https://wiki.ubuntu.com/ServerTeam/Meeting
[16:06] <mathiaz> last week minutes:
[16:06] <mathiaz> https://wiki.ubuntu.com/MeetingLogs/Server/20090428
[16:07] <mathiaz> [TOPIC] High Availability Team
[16:07] <MootBot> New Topic:  High Availability Team
[16:07] <mathiaz> RoAkSoAx: how is this going?
[16:07] <mathiaz> RoAkSoAx: IIUC the ubuntu-ha team has been created
[16:07] <RoAkSoAx> mathiaz, well the team has been created: https://edge.launchpad.net/~ubuntu-ha
[16:07] <RoAkSoAx> we've setup a wiki: https://wiki.ubuntu.com/UbuntuHighAvailabilityTeam and #ubuntu-ha
[16:08] <nijaba> o/
[16:08] <RoAkSoAx> many people have join, however they seem not to be participating in the mailing list yet
[16:08] <RoAkSoAx> here's a list of packages that we'll work on: https://bugs.edge.launchpad.net/~ubuntu-ha/+packagebugs
[16:09] <mathiaz> RoAkSoAx: great - that seems like a very good start
[16:09] <mathiaz> RoAkSoAx: you may wanna send an email to ubuntu-ha@ to explain what is the goal for the next few weeks
[16:10] <RoAkSoAx> mathiaz, yes, I already send an email for some feedback on clustering tools, but nobody has answered yet, i guess i'll resend it
[16:10] <mathiaz> RoAkSoAx:  ie trying to get a handle on the bugs related to the ubuntu-ha packages
[16:10] <RoAkSoAx> mathiaz, regarding on our goals, we are working on it with ivoks
[16:10] <mathiaz> RoAkSoAx: great - start small
[16:11] <mathiaz> RoAkSoAx: once you get things rolling you can think about greater things
[16:11] <RoAkSoAx> indeed, step by step
[16:12] <mathiaz> RoAkSoAx: great - it seems that you're getting started
[16:12] <mathiaz> RoAkSoAx: and already have the first task (bug triaging) figured out
[16:12] <mathiaz> RoAkSoAx: it seems to be in good hands :)
[16:13] <mathiaz> RoAkSoAx: anything else related to the ubuntu ha team?
[16:13] <RoAkSoAx> mathiaz, yes, and I requested motu mentoring and ivoks is my mentor... so we are gonna work together on packaging
[16:13] <RoAkSoAx> mathiaz, and that's about it
[16:13] <mathiaz> RoAkSoAx: great - once you've get a handle on the bugs, you'll have a better picture of what can be fixed in the packages
[16:14] <mathiaz> RoAkSoAx: ivoks will be able to sponsor most of the fixes in the packages
[16:14] <RoAkSoAx> awesome
[16:14] <mathiaz> great - let's move on
[16:14] <mathiaz> another related item: wiki pages
[16:14] <mathiaz> RoAkSoAx: ^^?
[16:15] <mathiaz> RoAkSoAx: did you get a chance to review the Ubuntu community wiki pages?
[16:15] <RoAkSoAx> mathiaz, yes I've identified some howto's such as setting up HA NFS server, HA Apache servers
[16:15] <RoAkSoAx> I just identified 4 howto's related to HA
[16:16] <mathiaz> RoAkSoAx: great - did you have time to review them?
[16:16] <ivoks> sorry for being late
[16:17] <RoAkSoAx> mathiaz, yes, one is old, the others are kinda good, but personally, if there's a plan to include them in the server guide somday, i think we'll first consider howto's on how to setup the HA tools rather than services
[16:17] <RoAkSoAx> but they look good
[16:18] <mathiaz> RoAkSoAx: ok - seems like this topic could be a discussion for the ubuntu-ha@ mailing list
[16:18] <RoAkSoAx> mathiaz, k
[16:18] <mathiaz> RoAkSoAx: which documentation could be useful and gather the ideas under the Ideas section on the wiki page
[16:19] <mathiaz> RoAkSoAx: may be someone will have time to write a wiki page about it
[16:19] <mathiaz> ok - anything else related to the Ubuntu HA team?
[16:19] <mathiaz> ivoks: ^^?
[16:20] <ivoks> nothing much, we just started
[16:20] <mathiaz> ivoks: agreed - and it seems that there is already a plan in place (bug triaging)
[16:20] <mathiaz> it looks good then :)
[16:20] <mathiaz> let's move on
[16:20] <mathiaz> [TOPIC] Features for karmic
[16:20] <MootBot> New Topic:  Features for karmic
[16:21] <mathiaz> we're in full swing for UDS preparation
[16:21] <mathiaz> if you have ideas that needs to be discussed register a blueprint in LP
[16:21] <mathiaz> Its name should start with server-karmic-
[16:21] <mathiaz> and should be proposed for the Karmic sprint
[16:22] <pschulz01> o/
[16:22] <mathiaz> pschulz01: sure - ?
[16:22] <nealmcb>  I was curious who put up the webmail item in the open discussion item of our agenda.  I tracked it down and added some attributions to the wiki: https://wiki.ubuntu.com/ServerTeam/Meeting  But I guess the poster (mpathy) isn't around....
[16:23] <dendrobates> mathiaz: could we name them server-karmic-community-*
[16:23] <mathiaz> nealmcb: right - it's a leftover from last week
[16:23] <ivoks> er...
[16:23] <ivoks> dendrobates: that sounds... wierd
[16:23] <pschulz01> I'm going through the dovecot-postfix install.. but are there any plans for a postfix-mailman ?
[16:23] <dendrobates> mathiaz: I've alreadyt reviewed the others and don't want to miss any community ones.
[16:24] <mathiaz> dendrobates: ah ok.
[16:24] <ScottK> Last time we looked at webmail in Main (Hardy, IIRC) there wasn't a 'good' webmail package that the security team was willing to have in Main.
[16:24] <pschulz01> (or is there a prefered alternative list management software?)
[16:24] <dendrobates> ivoks: I'm fine with any naming scheme that lets me find them.
[16:24] <ivoks> dendrobates: hehe ok
[16:25] <mathiaz> dendrobates: right - it's hard to figure out the new ones from the one you've already reviewed and rejected?
[16:26] <mathiaz> ScottK: right - IIRC there is a blueprint about that
[16:26] <mathiaz> so the webmail discussion should probably be taking place during UDS
[16:26] <dendrobates> I haven't rejected any.
[16:26] <pschulz01> otherwise I'll put together a blueprint.
[16:26] <dendrobates> mathiaz: and yes.
[16:26] <mathiaz> meanwhile additional research can be done
[16:27] <mathiaz> with the results added to the wiki page
[16:27] <ivoks> i was planing on webmail inside general mail related discussion
[16:27] <mathiaz> pschulz01: ^^ it seems that your proposal would fit in this topic
[16:27] <nealmcb> ScottK: do you recall any specific security feedback on horde ingo that you can pass on to mpathy?
[16:28] <mathiaz> ivoks: right - make sure a blueprint is created for that
[16:28] <ivoks> horde, as squirrelmail are... well, ugly
[16:28] <ivoks> :)
[16:28] <ScottK> nealmcb: I don't recall what packages we discussed.  It was quite a while ago.
[16:28] <pschulz01> mathiaz: Agreed
[16:28] <ivoks> mathiaz: i will
[16:28] <pschulz01> ivoks: +1
[16:28] <zul> whoa...squrrelmail there is a flashback
[16:28] <mathiaz> dendrobates: when will a draft of the schedule be available?
[16:29] <dendrobates> mathiaz: at some point, yes.  I'll find out when.
[16:29] <mathiaz> dendrobates: IIRC last time we got the first draft way too late
[16:29] <mathiaz> and lack time to get prepared
[16:30] <mathiaz> dendrobates: or is there a least of accepted blueprints?
[16:30] <nealmcb> ScottK: do you remember where the hardy webmail conversation took place?
[16:30] <mathiaz> dendrobates: so that the list of topics to be discussed is known (even if we don't know when)?
[16:30] <ScottK> nealmcb: It was in the server team room when we were doing the big discussion about lists of packages to add to Main.
[16:31] <nealmcb> so at uds
[16:31] <ivoks> in boston?
[16:31] <ScottK> Yes
[16:31] <ivoks> yes, we concluded that roundcube was too insecure
[16:31] <ivoks> kees said that :)
[16:31] <ScottK> Recent events have not caused me to revise that opinion.
[16:31] <mathiaz> IIRC there was a wiki page covering this discussion
[16:32] <mathiaz> anyway we can research things in preparation for a UDS discussion
[16:32] <ScottK> Just whoever is researching should have a good argumenat why the security team shouldn't faint at the prosepect.
[16:33]  * jdstrand is poised to faint
[16:34]  * nealmcb gets out the smelling salts
[16:34] <ivoks> all webmails are security problems
[16:34] <mathiaz> allright - anything else related to blueprints and UDS preparation?
[16:34] <ivoks> err... make that 'all php webmails are security problems'
[16:34] <nealmcb> ivoks: is the word "webmail" necessary there?
[16:34] <ivoks> nealmcb: not really
[16:34] <Pres-Gas> alpine web version?
[16:35] <mathiaz> nope - let's move on
[16:35] <mathiaz> and defer the php security discussion to another forum
[16:35] <mathiaz> [TOPIC] Merges
[16:35] <MootBot> New Topic:  Merges
[16:35] <mathiaz> Now that the karmic repostories are open for general consumption, we're focusing on merges
[16:36] <mathiaz> Merge-O-Matic is your friend
[16:36] <mathiaz> https://merges.ubuntu.com/
[16:36] <kirkland> merge, merge, merge if you want to make MOTU ;-)
[16:37] <RoAkSoAx> where can we find a list of merges related only to the server team?
[16:37] <mathiaz> there are lists of outstanding packages for all the components
[16:37] <mathiaz> RoAkSoAx: I'll work on this one again
[16:37] <RoAkSoAx> mathiaz, ok cool :)
[16:37] <ivoks> RoAkSoAx did a good job with drbd merge
[16:37] <mathiaz> If you don't have upload privileges, prepare a merge and use the sponsorship process
[16:37] <kirkland> i owe RoAkSoAx a review of QEMU
[16:38] <mathiaz> https://wiki.ubuntu.com/SponsorshipProcess
[16:38] <RoAkSoAx> indeed
[16:38] <ivoks> kirkland: bug number? i'm his mentor :)
[16:38] <kirkland> ivoks: https://bugs.edge.launchpad.net/ubuntu/+source/qemu/+bug/371879
[16:38] <kirkland> ivoks: be my guest :-)
[16:38] <ivoks> tnx
[16:39] <mathiaz> As kirkland just mentionned, merging is a good way to get packaging experience to get MOTU status
[16:40] <mathiaz> There is also an overview of what merging is about: https://wiki.ubuntu.com/UbuntuDevelopment/Merging
[16:40] <mathiaz> And there should be some wiki pages having practical examples of merging packages
[16:41] <mathiaz> IIRC there were a couple of sessions given about Mergin package during the previous Ubuntu Developers Week.
[16:41] <mathiaz> Any question related to the merging process?
[16:43] <mathiaz> nope - let's move on then
[16:43] <mathiaz> [TOPIC] Open discussion
[16:43] <MootBot> New Topic:  Open discussion
[16:43] <mathiaz> Anything else to add?
[16:44] <Pres-Gas> o/
[16:44] <mathiaz> Pres-Gas: sure - ?
[16:46] <Pres-Gas> I thought I saw meeting minutes regarding the openchange mapi plugins...has then I did not see anything more after release.  Is the server team the go-to on that now or another team?
[16:46] <Pres-Gas> I would love to help out.
[16:46]  * Pres-Gas is quickly looking for those minutes...
[16:46] <mathiaz> Pres-Gas: are you refering to the mapi plugins for evolution?
[16:47] <ivoks> i couldn't test openchange mapi in evolution cause of environment... it was firewalled or something...
[16:47]  * pschulz01 thinks it wass about 6 weeks ago.
[16:47] <Pres-Gas> mathiaz: evolution-mapi
[16:47] <Pres-Gas> http://www.google.com/url?sa=t&source=web&ct=res&cd=3&url=http%3A%2F%2Fubuntuserver.wordpress.com%2F2009%2F03%2F10%2Fserver-team-20090310-meeting-minutes%2F&ei=bF8ASo38C-qElAfbwbDlBw&usg=AFQjCNHXrSllChNHE6y_EDItBnOt-H8RnA
[16:47] <MootBot> LINK received:  http://www.google.com/url?sa=t&source=web&ct=res&cd=3&url=http%3A%2F%2Fubuntuserver.wordpress.com%2F2009%2F03%2F10%2Fserver-team-20090310-meeting-minutes%2F&ei=bF8ASo38C-qElAfbwbDlBw&usg=AFQjCNHXrSllChNHE6y_EDItBnOt-H8RnA
[16:47] <Pres-Gas> ahhhh
[16:47] <Pres-Gas> sorry
[16:48] <Pres-Gas> http://osdir.com/ml/ubuntu-server/2009-03/msg00030.html
[16:48] <MootBot> LINK received:  http://osdir.com/ml/ubuntu-server/2009-03/msg00030.html
[16:48] <Pres-Gas> Better
[16:48] <mathiaz> Pres-Gas: right - we were looking for testers
[16:48] <mathiaz> Pres-Gas: seb128 is looking after the evolution package
[16:49] <Pres-Gas> ivoks, I may have an environment suitable for testing.  Exchange 2007 ADS on server 2008
[16:49] <mathiaz> Pres-Gas: however he doesn't have access to an exchange environement
[16:49] <mathiaz> Pres-Gas: thus we were looking for testers that have access to such an environement
[16:50] <james_w> Pres-Gas: jelmer packages evolution-mapi, samba4, openchange etc., so you could email him if you want to help out on that side
[16:50] <mathiaz> Pres-Gas: If you have access to such an environemnt testing new versions of the plugin would be helpful
[16:51] <Pres-Gas> Hmmm...I think I saw seb128's page in launchpad.  I may be able to get access to a test account in our environment...I will talk to my resources and get with those people.
[16:51] <Pres-Gas> I do support at a University and we have gotten a number of contacts regarding this
[16:51] <mathiaz> Pres-Gas: great - if you can get a test account and conduct some testing of the development version of the plugin that would be helpful
[16:52] <Pres-Gas> I will get with jelmer and seb128
[16:53] <mathiaz> Pres-Gas: great
[16:53] <mathiaz> anything else?
[16:53] <Pres-Gas> Thanks, I was not sure if it was appropriate...it is the server team and I only saw one mention of it in the minutes
[16:56] <mathiaz> all right - if there isn't anything else, time to wrap up
[16:56] <mathiaz> [TOPIC] Agree on next meeting date and time
[16:56] <MootBot> New Topic:  Agree on next meeting date and time
[16:56] <mathiaz> next week, same time, same place?
[16:56] <ivoks> +
[16:56] <sommer> +1 :_)
[16:58] <mathiaz> great - so see you all in one week, same place, same time
[16:59] <mathiaz> in the mean time have fun with merging packages from debian into karmic
[16:59] <mathiaz> see you all
[16:59] <mathiaz> #endmeeting
[16:59] <MootBot> Meeting finished at 10:59.
[17:58] <bradf> YO!
[17:58]  * manjo waves
[17:58] <amitk> sup
[17:58] <cooloney> cooloney stand up
[17:59]  * rtg is here
[18:00]  * cking is here
[18:00] <manjo> #startmeeting
[18:00] <MootBot> Meeting started at 12:00. The chair is manjo.
[18:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:00] <manjo> [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting
[18:00] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/Meeting
[18:00]  * apw phases in
[18:00] <manjo> [TOPIC] New Starters
[18:00] <MootBot> New Topic:  New Starters
[18:01] <manjo> Please welcome John Johansen (jjojansen) to the Ubuntu Kernel Team.
[18:01] <apw> welcome!
[18:01] <cooloney> welcome, jjohansen
[18:01] <jjohansen> thanks good to be here
[18:01] <amitk> welcome jjohansen
[18:02] <manjo> [TOPIC] Open Action Items - ogasawara smb apw to discuss regression lists
[18:02] <MootBot> New Topic:  Open Action Items - ogasawara smb apw to discuss regression lists
[18:02] <smb> Keep us reminding
[18:02] <apw> i think we have basically decided to take this as a UDS action ...
[18:02] <ogasawara> apw, smb: prolly best to just UDS it
[18:02] <apw> ack
[18:02] <rtg> duck and cover :)
[18:02] <smb> Yeah, I think we agreed more or less last week to go for that
[18:03] <manjo> [ACTION] apw smb ogasawara arrange UDS session on regression
[18:03] <MootBot> ACTION received:  apw smb ogasawara arrange UDS session on regression
[18:03] <manjo> [TOPIC] Open Action Items - pgraner to schedule a UDS session for X lockup bug squashing
[18:03] <MootBot> New Topic:  Open Action Items - pgraner to schedule a UDS session for X lockup bug squashing
[18:03] <manjo> pgraner, ?
[18:03] <pgraner> manjo: On the list of BP's I'm doing today and tomorrow
[18:03] <manjo> k. moving on..
[18:04] <manjo> [TOPIC] Open Action Items - manjo to deep dive on suspend/resume bugs to find patterns
[18:04] <MootBot> New Topic:  Open Action Items - manjo to deep dive on suspend/resume bugs to find patterns
[18:04] <manjo> Wrote a script to fetch Lspci.txt and other attachments to suspend/resume bugs, wrote a script to find common HW (Video, Network, SATA/RAID/IDE controllers), looked through the subset of bugs containing most commonly used hardware. Found that 26 bugs use rtl8187 module. This module is found to cause resume problems. If the module is removed before suspend, resume works fine. Need to dup/mass comment these bus. Continuing to look for similar patterns
[18:04] <manjo> during spare cycles.
[18:04] <manjo> any thoughts ?
[18:04] <apw> manjo, thats a good start
[18:04] <amitk> rtl8187 is ethernet?
[18:05] <manjo> yes
[18:05] <manjo> realtech
[18:05] <cooloney> is it wired or wireless?
[18:05] <bradf> manjo, share your scripts :)
[18:05] <rtg> manjo: how nVidia? Any correlation?
[18:05] <manjo> bradf, k
[18:05] <smb> cooloney, I think it is wired
[18:06] <cooloney> bradf, agree,
[18:06] <manjo> rtg, I have a list of most commonly used/reported HW I can post that on a wiki
[18:06] <manjo> with counts
[18:06] <manjo> is there any interest in seeing something like this ?
[18:06] <rtg> manjo: that would be of interest, perhaps blurt it on the k-t list?
[18:06] <ogasawara> manjo: if you have it already, I'd like to see it
[18:07] <manjo> [ACTION] manjo to blurt list of HW On k-t
[18:07] <MootBot> ACTION received:  manjo to blurt list of HW On k-t
[18:07] <manjo> [TOPIC] Security & bugfix kernels - Jaunty
[18:07] <MootBot> New Topic:  Security & bugfix kernels - Jaunty
[18:08] <manjo> smb, apw ?
[18:08] <smb> Jaunty: proposed kernel uploaded
[18:08] <smb> 2.6.28-12.43
[18:08] <smb> waiting the quarantaine time and them move to updates to be ready for the stable update
[18:09] <manjo> [TOPIC] Security & bugfix kernels - Intrepid
[18:09] <MootBot> New Topic:  Security & bugfix kernels - Intrepid
[18:09] <smb> Intrepid: latest proposed has moved to updates
[18:09] <manjo> smb what are you doing with the continuing flood of 2.6.27.y updates?
[18:09] <smb> We have quite some stable updates which wont get into the default kernel now
[18:09] <smb> I have started to have a topic branch for them
[18:10] <smb> I need to test compile and then would push it as is
[18:10] <amitk> so you will still take wholesale .y updates?
[18:10] <smb> amitk, No
[18:10] <smb> Not for Intrepid anymore
[18:10] <smb> This will just be a topic branch for interested parties
[18:11] <smb> If there is a real fix required this has to be picked manually
[18:11] <amitk> aah, so you won't upload it, just maintain it in git
[18:11] <smb> amitk, Correct
[18:11] <rtg> what do you think about building it alongside mainline in the kernel-ppa ?
[18:12] <apw> rtg that would be feasable
[18:12] <smb> I still have to think a bit about the naming scheme for that
[18:12] <smb> probably like the upstream kernels
[18:12] <rtg> k, perhaps a quick chat at UDS.
[18:12] <apw> we would want some kind of tags for those ...
[18:12] <apw> a good idea
[18:12] <bradf> didn't I see there there won't be any further updates to .28 but there will be more for .27?
[18:13] <smb> bradf, Yes, as novel (greg) uses that ...
[18:13] <rtg> manjo: note the action item. schedule a session for end-of-life stable update kernels.
[18:13] <bradf> smb, android also
[18:13] <smb> We had been thinking of stepping up as 2.6.28 but it might be a big leap for a start
[18:13] <manjo> [ACTION] smb schedule a session for end-of-life stable update kernels.
[18:13] <MootBot> ACTION received:  smb schedule a session for end-of-life stable update kernels.
[18:14] <pgraner> bradf: android is already there and I just added the EOL session
[18:14] <smb> pgraner, thanks
[18:15] <manjo> [TOPIC] Security & bugfix kernels - Hardy
[18:15] <MootBot> New Topic:  Security & bugfix kernels - Hardy
[18:15] <manjo> smb, ?
[18:15] <smb> Hardy also has moved to updates now with the latest proposed kenrel
[18:15] <smb> So we are open to start new proposed rounds for hardy and intrepid as things are comming in
[18:15] <manjo> [TOPIC] Karmic Status - Alpha-1 may 14th
[18:15] <MootBot> New Topic:  Karmic Status - Alpha-1 may 14th
[18:16] <manjo> rtg, ?
[18:16] <rtg> Karmic is on track. I've only to upload linux-meta to complete the first upload requirements.
[18:16] <rtg> There is some ongoing discussion re LRM
[18:16] <rtg> I'd like nothing more then to drop it.
[18:17] <rtg> So, its the only outstanding item.
[18:17] <apw> are we going to be able to squash it with netbooks not having tool chains for dkms?
[18:17] <amitk> is broadcom shipped in any of the OEM engagements?
[18:17] <pgraner> rtg: +1 on the LRM dropping
[18:17] <rtg> Broadcom is, of course, the major sticking point.
[18:17] <pgraner> rtg: can we keep LRM for the OEM tree only?
[18:17] <awe> rtg: ;/
[18:18] <rtg> I expect a healthy discussion on the k-t list
[18:18] <rtg> pgraner: that is one possiblitiy
[18:18] <awe> amitk: broadcom is on almost all of the big projects.  ;(
[18:18] <rtg> manjo: thats all I have on Karmic.
[18:18] <pgraner> rtg: we have time in the general kernel discussion track at UDS with this topic
[18:19] <manjo> [TOPIC] ARM Tree - Status ?
[18:19] <MootBot> New Topic:  ARM Tree - Status ?
[18:19] <bradf> nothing new from me
[18:19] <bradf> looking into android
[18:19] <amitk> Just talking to upstream about upstreaming the imx51
[18:20] <manjo> [TOPIC] LPIA Tree - Status ?
[18:20] <MootBot> New Topic:  LPIA Tree - Status ?
[18:20] <rtg> amitk: it build for Karmic, but will it run?
[18:20] <sconklin> new release today incorporating jim and apw's debug changes
[18:20] <amitk> rtg: I'll try it out soonish
[18:20] <cooloney> i'm preparing a babbage demo for ARM seminar next week in Beijing
[18:20] <sconklin> Expect a rebase in the next week to the current distro hardy
[18:21] <manjo> [TOPIC] Incoming Bugs - Regressions ?
[18:21] <MootBot> New Topic:  Incoming Bugs - Regressions ?
[18:21] <ogasawara> I'd gone through the regression-tracker list for unassigned linux bugs but none had been confirmed against Jaunty final so I've asked for testing and feedback.
[18:21] <lieb> is there a need for debug on hardy-lum lpia too?
[18:21] <ogasawara> Other than that I'm still making my way through a backlog of New bugs for regressions, but nothing major so far.
[18:22] <manjo> [TOPIC] Incoming Bugs - Bug day report ?
[18:22] <MootBot> New Topic:  Incoming Bugs - Bug day report ?
[18:22] <ogasawara> manjo: I've also got some stats . . .
[18:22] <ogasawara> Kernel Team (220 total bugs)
[18:22] <ogasawara> [18:22] <ogasawara> Fix Released = 19
[18:22] <ogasawara> Fix Committed = 7
[18:22] <ogasawara> Won't Fix = 52
[18:22] <ogasawara> Invalid = 12
[18:22] <ogasawara> Reassigned = 1
[18:22] <sconklin> lieb: good question, I'll ask smagoun
[18:22] <ogasawara> In Progress = 6
[18:22] <ogasawara> Triaged = 17
[18:22] <ogasawara> Confirmed = 8
[18:22] <ogasawara> Incomplete = 81
[18:22] <ogasawara> New = 17
[18:22] <ogasawara> Community (50 total bugs)
[18:22] <ogasawara> [18:22] <ogasawara> Won't Fix = 16
[18:22] <ogasawara> Invalid = 1
[18:22] <ogasawara> Incomplete = 33
[18:23] <apw> ogasawara, who did the community ones... the ones i peeked at (not all) seemed to be bradf
[18:23] <bradf> apw, me
[18:23] <bradf> apw, i've not made it through all of them though
[18:24] <apw> i'd not have expected you to either!  just wondering if we had had any input outside the team
[18:24] <manjo> ogasawara, anything else ?
[18:24] <ogasawara> manjo: nope
[18:24] <manjo> [TOPIC] Open discussion - Anyone ?
[18:24] <MootBot> New Topic:  Open discussion - Anyone ?
[18:24] <bradf> apw, I didn't see anything happening with them so just went for it
[18:24] <apw> bradf not complaining :)
[18:24] <ogasawara> apw: I'm going to try to ping some individuals personally for the next one
[18:24] <smb> Definitely not :)
[18:25] <cking> ogasawara, great!
[18:25] <manjo> [TOPIC] Next Meeting Chair Selection
[18:25] <MootBot> New Topic:  Next Meeting Chair Selection
[18:26] <rtg> don't everyone speak at once.
[18:26] <apw> we need a rota
[18:26] <rtg> I'm wondering if its worth having these meetings until after UDS?
[18:27] <cooloney> sorry, i will travel to beijing at that time, although i do like to host the meeting
[18:27] <rtg> we've got a lot pending on UDS sessions.
[18:27] <smb> Likely the week after next we are busy with our hands
[18:27] <apw> well we are adding new sessions from this meeting, but we could likely do so elsewhere
[18:27] <manjo> there is just one more Tue in between now and UDS
[18:27] <rtg> ok, lets do next week, then cancel until after UDS?
[18:28] <manjo> I can do next week
[18:28] <apw> deal
[18:28] <rtg> sounds good. lets do that
[18:28] <smb> ack
[18:28] <bradf> +1
[18:28] <cking> +1
[18:28] <lieb> +1
[18:28] <manjo> [ACTION] manjo chairs meeting next week
[18:28] <cooloney> support
[18:28] <MootBot> ACTION received:  manjo chairs meeting next week
[18:29] <rtg> done?
[18:29] <manjo> anyone ?
[18:29] <manjo> anything else ?
[18:29] <apw> done here
[18:29] <manjo> #endmeeting
[18:29] <MootBot> Meeting finished at 12:29.
[18:29] <cking> complete!
[18:29] <smb> \o/
[18:29] <cooloney> great
[18:29] <amitk> bye
[20:19] <knome> i suppose there is still no EMEA regional board meeting?
[20:36] <popey> hi knome
[20:36] <popey> i am trying to clarify this
[20:36] <knome> ok? :)
[20:37]  * popey pokes Seveas Pricey stgraber 
[20:41] <Pricey> Hey
[20:41] <stgraber> hey
[20:41] <popey> look up :)
[20:41] <stgraber> sorry, was with a customer :)
[20:42] <stgraber> well, I thought it was today (reason why I sent a mail to the list) :)
[20:42]  * popey hopes we'll be quorate
[21:02]  * popey pokes Pricey stgraber Seveas 
[21:02] <popey> I've missed someone havent I
[21:03] <knome> https://launchpad.net/~ubuntu-membership-board-emea/+members#active
[21:03] <knome> :P
[21:03] <popey> heh
[21:04] <Pricey> popey: Hey
[21:06] <popey> phanatic markvendenborre forumsmatthew are missing
[21:06] <knome> /nick knomey
[21:07] <popey> not looking promising
[21:12] <knome> never is when i am available
[21:12] <knome> never since december
[21:12] <knome> ...it's like the regional boards wasn't working as good as they should *cough*
[21:12] <czajkowski> hard to find a date and time that is going to suit to get as many people as you need I guess.
[21:12] <popey> :(
[21:13] <popey> sorry guys, i know its frustrating
[21:13] <knome> the board is like 8 guys
[21:13] <popey> well, we dont all need to be here
[21:13] <knome> and you only need quorum which would be, like, 5 people
[21:13] <czajkowski> aye, it's all good, not the end of the world
[21:13]  * popey hugs czajkowski 
[21:13] <knome> and they have had a meeting like once in 6 months
[21:13] <czajkowski> cheers ;)
[21:13] <knome> even if announced to be more often
[21:14] <czajkowski> knome: that would take a long time to get through seeing as someone them take a long time.
[21:14] <Mean-Machine> czajkowski, we'll still be here to cheer for you next time! \o/
[21:14] <czajkowski> would also be very noisey
[21:14] <czajkowski> Mean-Machine: cheers
[21:14] <knome> popey, it's ok, just wanted to let you know also
[21:14] <popey> i understand knome
[21:14] <popey> completely
[21:14] <knome> and it's a problematic situation
[21:15] <knome> for both sides
[21:15]  * ebel puts away his pompoms
[21:15] <popey> haha
[21:15] <popey> they suit you ebel
[21:15] <ebel> *\o/*
[21:16] <knome> i even talked with mdke and he promised even to ask the CC for approve people to members, but haven't heard nothing since
[21:16] <knome> not that i should receive special attention... ;)
[21:16] <czajkowski> ebel: next -ie event you bring them along to cheer at, how's that
[21:16] <popey> i will contact the team and see if we can organise a meeting for one evening next week
[21:17] <Shane_Fagan> So is it definitely not going ahead??
[21:17] <Mean-Machine> czajkowski, ebel will bring them to geeknic :D
[21:17] <popey> and will update the wiki to reflect it
[21:17] <ebel> (note to self: Going to need to get some pompoms by next -ie meeting)
[21:17] <popey> Shane_Fagan: well, we're not enough people unfortunately
[21:17] <knome> i truely hope i can attend it
[21:17] <ebel> Mean-Machine: I'll be in Monte Carlo instead of geeknic, sorry :P
[21:17] <Mean-Machine> ebel, do you still live in EIRE?
[21:18] <Mean-Machine> :P
[21:18] <czajkowski> popey: coolio, and thanks
[21:18] <ebel> Mean-Machine: More than 50% of the time. :P
[21:18] <popey> Really sorry guys.
[21:18] <popey> (and gals)
[21:19] <czajkowski> hehe
[21:19] <czajkowski> thanks
[21:20] <joskulj> it would be really great if the next meetings would be announced on the wiki page since I don't think that I can attend next week. Thanks for this.
[21:21] <popey> yeah, will update it
[21:22]  * czajkowski guesses popey's to do list just got very long this evening 
[21:22] <popey> hah
[21:22] <popey> it happens
[21:23] <joskulj> Great, I'll probably would try to attend in June if there is a meeting
[21:24] <czajkowski> popey: trick is to tick them off the to do list, or even better delegate :D
[21:27] <popey> czajkowski: i have a job for you
[21:27] <czajkowski> oh dear
[21:27] <popey> ;0
[21:27] <czajkowski> how can I help?
[21:27] <popey> J/K
[21:27] <czajkowski> heh ok
[21:28] <cody-somerville> moo
[21:30] <popey> moo indeed
[21:32] <Mean-Machine> oiche mhaith
[22:06] <Technoviking> anyone here for the CC meeting?
[22:06]  * elmo o/
[22:07] <Technoviking> Anyone have any question or comments for us?
[22:10] <cody-somerville> Yes
[22:11] <cody-somerville> "<knome> cody-somerville, the emea regional board meeting cancelled once again as there is not enough people..."
[22:11] <knome> .
[22:11] <cody-somerville> Oh, looks like knome is here to speak for himself :)
[22:12] <knome> i just wanted to raise to your knowledge that the regional board meetings haven't happened as many times as they should have
[22:12] <knome> due to scheduling i haven't been able to be available at all times but whatsoever i have waited my membership approval meeting since december
[22:13] <elmo> knome: have you raised this as a concern with the emea regional board?
[22:13] <knome> and i have even tried the asia/oceania board once, but it was cancelled as well as there was not enough board members available (even if announced on the wiki 2 weeks in advance)
[22:14] <knome> elmo, i have spoken with mdke and also noted this to popey today.
[22:14] <elmo> knome: what did they say?
[22:14] <knome> elmo, mdke said he would investigate, popey was sorry, but couldn't do anything.
[22:14] <popey> i didnt say that
[22:14] <popey> i said i would try to get a meeting organised for 1 week today
[22:15] <popey> which i have already mailed the team about
[22:15] <knome> popey, you said you were sorry. i did not mean you said you could not do anything. sorry for being unclear.
[22:15] <popey> i appreciate this doesn't help you today.
[22:15] <knome> *i said
[22:15] <knome> popey, i understand.
[22:15] <elmo> knome: it sounds like the EMEA board appreciate your concerns and are trying to respond to them?
[22:16] <knome> elmo, after six months, yes.
[22:16] <elmo> knome: did you raise these concerns 6 months ago?
[22:16] <popey> it has not been six months since the last meeting
[22:16] <popey> we had one last month
[22:16] <knome> elmo, my concern is about this happens too much (meetings are scheduled but not enough people turn out)
[22:16] <knome> popey, i know, but due to my personal scheduling i could not attend it.
[22:16] <popey> so you understand the issue occurs on both sides
[22:17] <popey> we all have personal lives
[22:17] <knome> popey, totally.
[22:17] <knome> but once the meeting is announced and the people in the board have agreed on the time, i don't see how this can happen many times in a row.
[22:17] <popey> fact is we did have a meeting last month and rattled through many on the list
[22:17] <popey> it hasnt happened many times in a row
[22:17] <popey> as i said, we had a meeting last month
[22:17] <knome> persia also noted that they have the same problem with the asia/oceania board
[22:18] <Shane_Fagan> Maybe make the boards bigger?
[22:18] <popey> its certainly an issue, and one that perhaps needs to be raised with the cc
[22:18] <knome> popey, i haven't been able to join 2 meetings in 6 monts
[22:18] <popey> you're erroding your own argument knome
[22:18] <popey> by saying that its unacceptable for us to not attend, and then not attend yourself
[22:18] <knome> popey, if the board had met once in a month, i've had 4 possibilities already
[22:19] <knome> popey, as i said, i understand the problem is on both sides
[22:19] <popey> well there's 3 boards, and nothing stopping you adding your name to the other board lists
[22:19] <knome> popey, but i hope it would be possible to do something on the side *who decides the meeting times*
[22:19] <knome> popey, i can't stay awake 24 hours in a day and i have to make my living.
[22:20] <popey> as do members of the boards
[22:20] <elmo> ok, so.
[22:20] <elmo> how about this.
[22:20] <knome> popey, but if i understand correctly, you can decide on the days?
[22:20] <elmo> knome: since you're concerned about this, would you be willing to do either or both of the following:
[22:21] <elmo>  1) come up with a report of the meetings of the membership boards have managed over the last say, 6 months
[22:21] <popey> knome: how else does the date get decided other than by consensus of those on the board?
[22:21] <elmo>  2) start a conversation with the boards, to see if they believe there's a problem in terms of regular meetings and/or ability for people to make meetings (on either side)
[22:21] <popey> I completely agree that there is an issue
[22:21] <popey> not sure what the solution is
[22:21] <elmo> knome: and then feed that info back to the CC list?
[22:21] <knome> popey, no way else. but as you can affect on they days, i suppose you have thought if you can attend the meetings or not and reschedule
[22:22] <popey> knome: well for at least one meeting I was delayed due to train failure
[22:22] <popey> I'm sure other members also have reasons for not attending
[22:22] <knome> popey, i think that was the one i unfortunately missed as well
[22:22] <popey> this is why we have a large team, so we can be quorate without everyone attending
[22:23] <mc44> perhaps the approvals could be made asynchronous, the majority of substantiation/support seems to happen on the wiki page anyway
[22:23] <knome> popey, maybe then update the wiki before the date?
[22:23] <popey> knome: i will
[22:23] <popey> knome: thanks for your feedback, its appreciated
[22:23] <czajkowski> knome: you ahve to admit/understand dates clash, and even if there is a set date, things come up. Also the reason I would assume that there is 8 on the board is to allow for not having to have all 8 there, maybe a solution (i dont know if this has come up) would be to increase that number. but popey has said he'd look into it
[22:23] <knome> czajkowski, of course i admit it.
[22:23] <czajkowski> and elmo has offered you a construcrive route to take
[22:24] <czajkowski> so why not try that in the mean time
[22:24] <knome> czajkowski, making the board bigger would only lead to more people having to be there to be the quorum.
[22:24] <czajkowski> knome: that is a downside, but you cant have it every way,
[22:25] <knome> elmo, well i definitely have done 2 already, but if i have time i can also do 1.
[22:25] <popey> I'd be happy if this issue was taken to teh cc
[22:25] <popey> to allow us to get some idea of the problem globally
[22:25] <Shane_Fagan> How about making like substitutes? You know like in football
[22:25] <mc44> I'm not sure a quorum is actually intended to be a majority of each board.
[22:25] <knome> so if that is the case, we might have had the meeting today.
[22:26] <knome> i think we had 3 of 7 board members.
[22:26] <knome> popey, are you willing to raise the issue up?
[22:27] <popey> i am happy to raise the issue within the emea board
[22:27] <elmo> knome: as somone who's concerned about the issue, I was hoping you'd be willing to escalate it
[22:28] <knome> elmo, sure, but i have had the impression that there is not going to happen a lot of things if it's somebody from "outside" raising things up. i'd be happy to do that, though.
[22:28] <knome> elmo, (didn't i already do that?)
[22:28] <knome> :P
[22:28] <elmo> knome: sure, you started.  I'm suggesting a way of moving it forward, that I think will be constructive
[22:29] <popey> knome: the cc listen very carefully to issues like this, whether it's from someone "inside" or "outside" (whatever that means)
[22:29] <elmo> popey++
[22:29] <knome> popey, "A quorum of 3 or 4 people will be sufficient to hear a membership application."
[22:30] <popey> yeah, we (emea board) have talked about that issue specifically
[22:30] <popey> we've decided that 3 isnt enough
[22:30] <knome> what is the outcome?
[22:30] <knome> right. what's the rationale? (just curious)
[22:30] <popey> but if we had a mandate that said we should go ahead with 3, possibly with email based confirmation from non-attendees then so be it
[22:31] <popey> well, how low do you go?
[22:31] <popey> is 1 enough?
[22:31] <knome> totally not.
[22:31] <popey> so why 3?
[22:32] <popey> why not 2?
[22:32] <knome> with 3 you can't go on a draw situation.
[22:32] <knome> and it's almost half, as the board is 7 members.
[22:32] <knome> 4 seems to be very difficult to gather anyways.
[22:32] <popey> most quorates that I
[22:32] <popey> gah, eee keyboard
[22:32] <popey> most quorates that I'm aware of are more than 50%
[22:33] <knome> me too, but 3/4 is what the original spec (by cc?) says
[22:33] <knome> https://wiki.ubuntu.com/StreamlineMembershipApproval
[22:33] <popey> true
[22:34] <knome> the idea about non-attendees voting by email afterwards actually sounds quite good.
[22:34] <knome> then at least things would go forward
[22:34] <popey> unfortunately you lose the Q&A
[22:35] <knome> as the attendee board members would (hopefully) to be able to ask such questions that tells about the guy approving for membership
[22:35] <knome> -to
[22:36] <knome> that way the non-attendee members could decide by the log, or in some cases, ask for review in the next meeting.
[22:37] <elmo> knome: in any event, I think we should take this discussion to email
[22:37] <elmo> knome: there's only 2 CC and 1 EMEA member here tonight
[22:37] <knome> elmo, ...exactly.
[22:37] <elmo> knome: so will you do (1)/(2) above?  if not, that's fine, but it'd be nice to know, because if not, I'll see if someone else can
[22:38] <elmo> if you will do (1)/(2) above, I'd suggest we'd leave further discussion to the resulting conversation from that
[22:39] <knome> subjectively i have done enough of (2), i will mail the cc-list now.
[22:39] <knome> (1)
[22:40] <elmo> (2) did you speak to anyone besides the EMEA board?
[22:40] <knome> elmo, i have spoken with mdke and persia.
[22:40] <elmo> mk
[22:40] <elmo> knome: thanks for raising the issue, I'll look forward to your email
[22:41] <elmo> anything else from anyone else?
[22:41] <knome> np.
[22:41] <popey> thanks for the feedback knome
[22:41] <knome> when can i have my membership? :P
[22:42] <elmo> ok, if there's nothing else, I guess we'll call this meeting
[22:42] <popey> thanks elmo
[22:42] <knome> thanks
[22:45] <nhandler> MOTU meeting is in 15 minutes
[23:00] <nhandler> james_w: ping
[23:00]  * james_w waves
[23:00] <james_w> hey nhandler
[23:01] <yvan300> hey all
[23:02] <james_w> hi yvan300
[23:02] <james_w> let's get this show on the road
[23:02] <james_w> who is here?
[23:02] <nhandler> james_w: Are we using MootBot? If so, do you want to chair?
[23:02] <yvan300> has the meeting finished
[23:02] <james_w> we could do
[23:02] <james_w> yvan300: which one?
[23:02]  * ajmitch is here
[23:02] <yvan300> beginners
[23:03] <james_w> yvan300: that's in an hour
[23:03] <yvan300> oh ic
[23:03] <james_w> hi ajmitch
[23:03] <james_w> #startmeeting
[23:03] <MootBot> Meeting started at 17:03. The chair is james_w.
[23:03] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[23:03]  * yvan300 takes a seat in the back
[23:03] <james_w> yay, it worked
[23:03] <ajmitch> now to see if there are enough people present
[23:03] <james_w> ajmitch, nhandler: what did you think of the Jaunty cycle?
[23:04]  * ajmitch had very little involvement with the jaunty cycle
[23:04] <nhandler> james_w: Any apsect of it in particular?
[23:04] <ajmitch> from what I could see at a distance it went without too many problems
[23:05] <james_w> nhandler: what was your overall impression?
[23:05] <james_w> is there anything in particular you would like to discuss?
[23:05] <nhandler> james_w: I think one of the biggest issues was the whole notification system
[23:05] <nhandler> However, I think most of that has been discussed elseware
[23:05] <james_w> [TOPIC] notification system
[23:05] <MootBot> New Topic:  notification system
[23:06] <james_w> is there anything related to MOTU that we should discuss about that do you think?
[23:06] <nhandler> james_w: Not really. Most of the issues regarding the lack of discussion/communication have already been discussed
[23:07] <james_w> so you don't think it was really a MOTU issue?
[23:07] <nhandler> james_w: It wasn't the MOTU team that initiated the notification changes. It was a Canonical team
[23:07] <ajmitch> not unless it involved changing packages in universe to suit
[23:07] <ScottK> I'm not sure it was significantly worse for MOTU than anyone else.
[23:07] <ScottK> ajmitch: It did.
[23:08] <ajmitch> ScottK: I wasn't sure how much of that was being done, from what I could see those changes were being deferred
[23:08] <ScottK> There were a few packages that got patched.  I didn't count how many.
[23:08] <james_w> maybe a dozen or so
[23:09] <ScottK> I sponsored a few, but only with either a commitment to maintain the patch until it was upstream or that the patch came from upstream.
[23:10] <james_w> In reltation to these changes, I wasn't particularly happy when I felt you were obstructing my work on them ScottK.
[23:10] <ScottK> james_w: I can understand that.
[23:10] <james_w> though it didn't last long in the end, so I don't think it's a big issue
[23:11] <james_w> ScottK: you don't understand when I think you were blocking me?
[23:11] <pochu> he's said he can
[23:11] <ScottK> james_w: I was trying to say that I understand why you weren't happy about it.
[23:11]  * ajmitch sees a "can", not "can't"
[23:11] <james_w> ah, sorry
[23:12] <ScottK> No problem.
[23:12] <james_w> I shouldn't schedule meetings that are this late in my own timezone :-)
[23:12] <james_w> ScottK: do you think there is anything that we should examine there, or just chalk it up to a one-off that probably won't occur again?
[23:13] <ScottK> james_w: I'm reasonably certain stuff like this will happen again, but that it's out of our hands.
[23:13] <ScottK> I think most of the problems with it were much broader than MOTU and there isn't a lot we could have done better.
[23:13] <james_w> and do you think you would take the same actions again?
[23:14] <ScottK> Probably not.
[23:14] <ScottK> I think that once it happens again the odds of my having any significant involvment in Ubuntu development are quite low.
[23:14] <james_w> I think we should work to avoid those in the small critical teams are blocking people in general, even though it is sometimes required
[23:14] <ScottK> So the particular issue that came up between you and I is very unlikely to repeat.
[23:14] <james_w> ok, that would be a great shame
[23:15] <james_w> does anyone else have anything for this topic?
[23:15] <ScottK> That particular case of me being a blocking force wasn't so great, but in other circumstances we've got ubuntu-mozillateam to agree to maintain their Universe firefox packages and they didn't before.
[23:17] <ScottK> Nothing else here.
[23:17] <james_w> in this case I felt there was not an issue of maintenance of the changes, so it was different for me
[23:17] <ScottK> Agreed.
[23:17] <ScottK> My only point is that sometimes a block is useful.
[23:17] <james_w> sure, and I would agree
[23:18] <james_w> as I said, it only amounted to about 2 hours frustration, so we shouldn't dwell on it
[23:18] <james_w> any other topics to discuss?
[23:18] <ScottK> How about Python transition.
[23:18] <james_w> REVU? QA? transitions? motu-release? co-ordination? communication?
[23:18] <ajmitch> only other thing that was sprung on MOTU late in the cycle was the python transition
[23:18] <james_w> [TOPIC] python transition
[23:18] <MootBot> New Topic:  python transition
[23:18] <james_w> ok, what went well here?
[23:18] <ScottK> That one we actually knew was coming as it was a spec item from UDS.
[23:19] <ScottK> What I didn't expect was that it would get uploaded so late.
[23:19] <james_w> I think we released with nothing uninstallable?
[23:19] <james_w> (because of python default changing at least)
[23:19] <ScottK> Yes, we got to installable, but only started to scratch the surface of 'works with Python 2.6'
[23:19] <ajmitch> I've heard that there were still packages that needed fixed at least
[23:19] <ajmitch> SRU candidates, perhaps
[23:20] <ScottK> Yes, there are ones not working.
[23:20] <james_w> yeah, I think we're going to be seeing python2.6 issues for a while
[23:20] <james_w> could we improve on this somehow?
[23:20] <ajmitch> and some of those that were fixed early on will need to be updated again to work with some changes to --prefix, etc
[23:21] <james_w> more testsuites during build springs to mind
[23:21] <ScottK> I think it would be a good idea to not make a new Python version the default in the release it's introduced.
[23:21] <james_w> communication about the testing needs with the userbase, and feedback by filing bugs with a specific tag or something
[23:21] <ScottK> Obviously that's bigger than MOTU, but we can take that to the lessons learned session at UDS.
[23:22] <james_w> yeah. some of the things are "outside MOTU", but our experiences would certainly be valued
[23:22] <ScottK> Personally, I found the Python transition frustrating as it took time away from stuff I wanted to get done for the release.
[23:23] <james_w> I felt that it was also no co-ordinated that well
[23:23] <james_w> regardless of the timing issue
[23:23] <ScottK> Yes.
[23:23] <james_w> we had to work out the way to find broken packages, share common fixes
[23:23] <ScottK> I think maybe next time there needs to be a companion spec for getting the modules/applications transitioned.
[23:24] <james_w> and the "correct" way to do some things was only revealed later
[23:24] <ScottK> Yep.
[23:24] <james_w> obviously we need to do some of this, but providing a starting point would have led to a better feeling I think
[23:24] <james_w> I guess this goes beyond python
[23:25] <james_w> but it is the most obvious because ironically it is actually the one best set up to handle these transitions
[23:25] <james_w> so, what would be a good way to present the feedback?
[23:25] <ScottK> Part of the complexity was we had two transitions here.
[23:26] <ScottK> 1. Python 2.5 -> 2.6
[23:26] <james_w> you mean 2.6 available and 2.6 by default?
[23:26] <james_w> ah
[23:26] <james_w> gotcha
[23:26] <ScottK> 2. Build system changes (dist-packages/usr/local by default)
[23:26] <james_w> I can see why they were done together, but it did make it trickier
[23:26] <ScottK> The 2.6 part would have been pretty easy without the build system changes.
[23:27] <ScottK> So when we focus on 'it was painful' we need to communicate about what caused the pain.
[23:27] <james_w> should we just wait for the "3.0 by default" session at UDS and try and remember this stuff?
[23:27] <ScottK> Also since we were ahead of Debian, that made it hard too.
[23:27] <ScottK> 2.7 first.
[23:27] <ScottK> 3.x is a long way off.
[23:28]  * ajmitch can't see ubuntu moving to 3.0 by default until around or after the next LTS
[23:28] <ScottK> Agreed.
[23:28] <ScottK> Probably after.
[23:28] <ajmitch> depending on how long upstream will want to support 2.x
[23:29] <james_w> perhaps we could create an "informational blueprint" out of this?
[23:29] <james_w> (basically a wiki page)
[23:29] <ScottK> It appears they understand 3.x will take a long time and are continuing development of 2.x at a low rate.
[23:29] <james_w> "best practices for a python transition"?
[23:29] <james_w> and "best practices for a transition" I guess
[23:29] <ScottK> 1.  Go after Debian.  2.  Done.
[23:29] <ScottK> ;-)
[23:30] <james_w> heh
[23:30] <james_w> 1b. make sure Debian starts after DIF and finishes before it
[23:30] <ajmitch> python teams in debian are fairly decent
[23:30] <james_w> indeed
[23:30] <ScottK> Yep and gave us some help.
[23:31] <james_w> if python2.6 had been available in Debian at the same time it would have been easier to work together
[23:31] <RainCT_> (hi)
[23:31] <james_w> hi RainCT_
[23:31] <ajmitch> nothing we could do directly to change that
[23:31] <ScottK> james_w: Yes.   Absolutely.  And that's something that is in doko's control to provide (modulo Debian release freezes)
[23:31] <james_w> (and NEW)
[23:31] <ScottK> Yes, and New.
[23:32] <james_w> we can't put this all at his feet however
[23:32] <ScottK> No.
[23:32] <ScottK> He's the only one that can manage the timing.  Due to the release freeze in Debian, it really wasn't possible this time.
[23:32] <ajmitch> no, but noone else would really have been able to update it in debian
[23:32] <james_w> yeah
[23:33] <ajmitch> syncing 2 release cycles & approvals from various people wouldn't be easy
[23:33] <ScottK> Yes, although there's a spec about that for discussion at UDS.
[23:33] <james_w> plus being the main python maintainer, plus dealing with all of the toolchain and java and ...
[23:33] <ScottK> Trying to sync up squeeze and Ubuntu's next LTS.
[23:34] <ajmitch> ScottK: great, put forward our concerns & suggestions then :)
[23:34] <james_w> ok, I think we've done on this topic, agreed?
[23:34] <ScottK> Agreed.
[23:34] <ajmitch> sure
[23:34] <james_w> any other topic suggestions?
[23:35] <ScottK> Yes
[23:35] <ajmitch> REVU & new packages?
[23:35] <ScottK> I think we need to work with main to define targets for other multiple versionsed libs
[23:35] <ajmitch> though it's not something in my area
[23:35] <james_w> ScottK: libdb etc?
[23:35] <ScottK> e.g. boost1.35 for Jaunty.  What's the target for Karmic
[23:35] <ScottK> libdb too
[23:35] <ScottK> james_w: Yes.
[23:35] <james_w> [TOPIC] multiply versioned libs
[23:35] <MootBot> New Topic:  multiply versioned libs
[23:36] <james_w> if they're even real things :-)
[23:36] <ScottK> We need to define the targets early and communicate them.
[23:36] <james_w> you said "work with main", is there someone you have in mind?
[23:36] <ScottK> We also need a cleanup plan for pushing the old stuff out.
[23:36] <ajmitch> ScottK: how much coordination with main is needed given that archive reorganisation?
[23:36] <james_w> or is it just a "look at the whole" distro thing?
[23:36] <ScottK> james_w: I think most of this falls under Foundations.
[23:37] <ajmitch> I'm guessing it'll tend towards 'look at everything'
[23:37] <james_w> probably :-)
[23:37] <ScottK> I think it's a look at the whole distro, make a plan, communicate it.
[23:37] <james_w> everything seems to...
[23:37] <james_w> yeah
[23:37] <james_w> I guess the first thing I would ask is: "Do we have a list of all of these?"
[23:37] <ScottK> No.
[23:37] <ScottK> I know boost and libdb.
[23:37] <james_w> if not, then lets start one, so we at least know what to look at
[23:37] <ScottK> I'm sure there are others.
[23:37] <james_w> yeah
[23:38] <ScottK> I need to leave for $WORK (working 7PM to 3AM this week).
[23:38] <james_w> once we have that we can have a meeting at the start of the cycle (UDS or otherwise)
[23:38] <james_w> ScottK: ah, ok, have fun!
[23:38] <ScottK> I'm curious for feedback on how people felt about motu-release and exception processing.
[23:38] <ScottK> I'll read the scrollback.
[23:38] <james_w> I'll try and gather some
[23:39] <ScottK> I'll also toss in that we could have had final freeze much later.
[23:39] <ScottK> I intend to take that up at UDS with ubuntu-release.
[23:39] <james_w> yeah, I remember you saying that now
[23:39] <james_w> oh, good, I was just going to say that you know the issues much better than us :-)
[23:39] <ScottK> Security-in-soyuz really altered the release critical path in a way we didn't anticipate.
[23:39] <ScottK> Later
[23:39] <james_w> bye
[23:40] <james_w> all those in favour of actioning ScottK to do the rest of the work say "Aye" ;-)
[23:40] <nhandler> Aye ;)
[23:40] <RainCT> Aye :)
[23:40] <james_w> motion carried :-)
[23:40]  * ScottK is very good at ignoring actions he doesn't feel like doing ....
[23:41] <james_w> is anyone else familiar with the multiple versioned libraries issue?
[23:41] <nhandler> Not really
[23:41]  * RainCT doesn't even know what it is :(
[23:41] <ajmitch> not with any intimacy
[23:41] <ajmitch> RainCT: carrying multiple versions of the same library
[23:42] <james_w> I suggest we take it to the mailing list then, as we will be able to have a more useful discussion
[23:42] <RainCT> ajmitch: there are lots of those, or not?
[23:42] <ajmitch> eg how many should be carried across releases, transitioning packages from one set to another
[23:42] <ajmitch> RainCT: not a huge number
[23:42] <pochu> e.g wxwidgets2.[468] ? :-)
[23:42] <RainCT> or is it just that aptitude shows me the old ones which have already been deleted? :P
[23:42] <yvan300> has the meeting brgun
[23:42] <james_w> RainCT: they just aren't caught by the usual soname change -> NBS route, so they can pile up and become a pain
[23:43] <ajmitch> it shows up more when there are multiple sets of headers that can be installed at once
[23:43] <RainCT> +1 to killing wxwidgets packages! :P
[23:43] <james_w> yvan300: still 20 minutes :-)
[23:43] <nhandler> yvan300: BT meeting in ~15 minutes
[23:43] <james_w> ok
[23:43] <james_w> [TOPIC] REVU and new packages
[23:43] <MootBot> New Topic:  REVU and new packages
[23:43] <yvan300> james_w: ok
[23:43] <james_w> who here was involved in this last cycle?
[23:43] <nhandler> o/
[23:44] <RainCT> \o
[23:44] <nhandler> Near the end of the last cycle, persia, mok0, and myself started discussing possiblely moving to a new REVU interface
[23:44] <nhandler> (and RainCT )
[23:44] <yvan300> james_w: what are we gonna basically discuss
[23:44] <james_w> yvan300: no idea, sorry, I'm not on that team
[23:44] <ajmitch> nhandler: what problems would that solve?
[23:44] <yvan300> nhandler: u know
[23:45] <nhandler> ajmitch: It would create separate lists instead of the two main ones we have now
[23:45] <st33med_> know wat?
[23:45] <nhandler> Let me try and find the wiki page
[23:45] <james_w> nhandler: yeah, can we start with an overview of what improved last cycle, and what is still a problem?
[23:45] <nhandler> https://wiki.ubuntu.com/REVUWorkflowProposal
[23:46] <nhandler> Last cycle, RainCT implemented weekly REVU days which IMO caused a lot more Developers to devote time to reviewing packages on REVU
[23:46] <nhandler> I am hoping to continue to hold these days (first one is Friday)
[23:46] <ajmitch> nhandler: currently I see a breakdown of new/archived/updated, etc
[23:47] <nhandler> ajmitch: One of the biggest issues with the current layout is for packages that receive one advocation. After that, many developers are hesitant to comment on the package because a non-advocating comment will send it to the needs work list
[23:47] <nhandler> That was one thing that mok0's layout would solve
[23:47] <ajmitch> ok
[23:48] <james_w> a quick look suggests to me that the proposed interface would be an improvement
[23:48] <nhandler> A demo can be seen here: http://dmz-212.daimi.au.dk/~mok/revu/
[23:48] <james_w> were there any concerns expressed about it?
[23:48] <ajmitch> nhandler: I guess anything that helps get through the list of packages that are 6+ months old on there would be good
[23:48] <ajmitch> some of those being just uploaded, commented on, & forgotten
[23:48] <james_w> and there's code!?
[23:48] <nhandler> ajmitch: In the end, it simply boils down to the fact that we have lots of packages being uploaded, but very few developers devoting time to REVU
[23:49] <RainCT> iirc (that was quite some time ago :P) persia wasn't really happy with it but didn't want to block the change if he was the only one feeling so
[23:49] <james_w> that looks great, though I would change the default page shown to MOTUs
[23:49] <ajmitch> nhandler: it cuts 2 ways - not enough people reviewing, and uploaders not making changes after getting comments
[23:49] <nhandler> RainCT: I think I had some concerns as well, but I need to look at it again (it was a while ago)
[23:49] <james_w> it seems like we could move this to a mailing list discussion to try and get the change approved, am I wrong?
[23:50] <nhandler> james_w: This was discussed at a previous MOTU meeting and on the list. I'll try to coordinate to get the ball rolling again
[23:51] <james_w> nhandler: thanks
[23:51] <james_w> is there anything else to discuss about REVU?
[23:51] <RainCT> Uhm yes I got a question
[23:51] <nhandler> Go ahead RainCT
[23:53] <RainCT> Not a really important one, but well. I have plans for making processing of packages start as soon as the upload finished (using inotify), but now I'm wondering whether this will bring any benefit considering I already have a cronjob processing everything at 3 minute intervals. Do you think this would be useful, or is there something else you'd like to see improved soon?
[23:53] <ajmitch> RainCT: I think 3 minutes is fine
[23:53] <nhandler> RainCT: I think 3 minutes is frequent enough. Most people are not sitting at their computer refreshing REVU waiting to review a pacakge
[23:54] <ajmitch> RainCT: I think logging of rejects & possibly mailing that to be more important :)
[23:55] <nhandler> I also would like to move towards having REVU build packages in a LP PPA (or in some other fashion)
[23:55] <nhandler> 5 minute warning
[23:55] <bodhi_zazen> :)
[23:55] <Hellow> heh
[23:55] <bodhi_zazen> The Borg are coming
[23:56] <jamesrfla> Borg?
[23:56] <thewrath> star trek
[23:56] <nhandler> Please let us finish the meeting
[23:56] <ajmitch> nhandler: getting things into a PPA would require re-signing things, or having a team PPA for the revu uploaders
[23:56] <RainCT> ajmitch: OK, I think I'll tackle this after finishing exams (in two weeks).
[23:56] <st33med> bodhi_zazen, I don't want to die!
[23:57] <ajmitch> RainCT: I can take a look at it, I should have a branch of it somewhere
[23:57] <RainCT> For PPA integration, there is currently a "Import from PPA" feature which I need to make visibule on the GUI
[23:57] <james_w> nhandler: there is a difficulty that you can'r re-upload with the same number, which may not make it possible
[23:57] <nhandler> ajmitch: Since the packages need to be resigned before being uploaded to Ubuntu, I don't think resigning for the PPA would be an issue
[23:57] <james_w> another method would obviously work, but require more resources for REVU
[23:57] <bodhi_zazen> shh ... BT do not interrupt, sorry MOTU
[23:57] <james_w> worth looking at though I think
[23:57] <ajmitch> nhandler: automated or otherwise?
[23:57] <ajmitch> it's something that was looked at quite awhile ago, before PPAs were around
[23:57] <nhandler> ajmitch: I would prefer automated, but manual (at MOTU request) would work too
[23:58] <ajmitch> and there just weren't the resources on the REVU server to autobuild there
[23:58] <ajmitch> plus security concerns, etc
[23:58]  * ajmitch thinks we'll need to finish up & discuss later/elsewhere
[23:58] <RainCT> Personally I don't see the need for automated package builds
[23:59] <nhandler> RainCT: I don't have strong feelings towards automated builds, but I think a manual copy-to-ppa option would be nice
[23:59] <RainCT> It isn't that difficult to build the package yourself, and if for some reason it is it's still possible to upload it to a PPA. But if you want this I don't disagree why having it neither
[23:59] <nhandler> Ok, we are about out of time