[09:02] <TheMuso> amachu: Hey there.
[09:06] <amachu> hi
[09:07] <amachu> TheMuso:
[09:07] <amachu> elky: Hi
[09:07] <elky> amachu, hi
[09:07] <amachu> persia: elky: TheMuso: Hi
[09:07] <TheMuso> Hey elky.
[09:07] <amachu> long since we met
[09:07] <elky> w00t. quorum
[09:07] <amachu> persia: are you there?
[09:08] <amachu> we need persia
[09:08] <amachu> lifeless: Hi
[09:08] <elky> i mistook you addressing him as him being here, sorry
[09:08] <amachu> either lifeless or persia
[09:09] <lifeless> hi
[09:09] <lifeless> I forgot about the precise time; I need to go eat or I won't get dinner at all :(
[09:10] <amachu> Ooof
[09:10] <amachu> lifeless: lets check candidates' presence
[09:10] <amachu> MaWaLe: Hi
[09:10] <MaWaLe> hi all
[09:11] <amachu> MaWaLe: alone appear to be here
[09:11] <MaWaLe> i think so
[09:11] <amachu> lifeless: Will you be available or going out for dinner
[09:11] <amachu> elky: ok
[09:12] <amachu> elky: TheMuso: lifeless: Shall we start
[09:12] <TheMuso> sre
[09:12] <amachu> how about lifeless?
[09:12] <elky> amachu, i suspect he's off getting food
[09:13] <lifeless> amachu: I'm not at home, I'm at a colleagues; the only food is take out, so I need to walk out the door in the next 10 minutes tops
[09:13] <lifeless> or things are shut == no food
[09:13] <amachu> okie
[09:14] <lifeless> sorry :(
[09:14] <amachu> then persia?
[09:14] <lifeless> totally my fault
[09:14]  * lifeless waves bye
[09:14] <amachu> or can you be back by 30 min
[09:14] <amachu> I am Ok with it
[09:14] <amachu> how about elky and TheMuso
[09:14] <TheMuso> I'm here.
[09:14] <lifeless> I will be back in nearly an hour
[09:14]  * lifeless is really gone
[09:14] <elky> amachu, we still lack quorum until we have a fourth
[09:14] <amachu> an hour is too long
[09:15] <amachu> elky: Yes
[09:15] <elky> we dont have a choice.
[09:15] <amachu> i am looking for persia to wake up :-(
[09:15] <amachu> MaWaLe: Tought times for you!
[09:15] <TheMuso> Idle for over 4 days
[09:15] <TheMuso> He keeps odd hours as well, and is not always on IRC at regular times.
[09:19] <amachu> ok
[09:21] <amachu> TheMuso: elky: I suppose better luck next week..
[09:21] <TheMuso> Yeah, lets hope so.
[09:21] <elky> amachu, yep, see you then
[09:22] <amachu> elky: wait, you have any nominations for the board
[09:22] <amachu> TheMuso: you?
[09:22] <amachu> I do not have as of now
[09:22] <elky> ajmitch, none that i've spoken to, unfortunately
[09:22] <TheMuso> amachu: no
[09:22] <elky> er, amachu
[09:22] <amachu> okie
[09:22] <elky> although, ajmitch would be a perfect victim :P
[09:23] <elky> he qualifies by being in the right part of the globe anyway
[09:23] <amachu> elky: wiki of ajmitch?
[09:23] <elky> amachu, dunno. maybe we should ask him privately first
[09:23] <amachu> may be you can narrate about your nomination to the mailing list
[09:24] <amachu> so that we all can look at it
[09:24] <elky> amachu, how about we ask him first.
[09:24] <amachu> when others aren't aware, how can we?
[09:25] <amachu> may be he is here now
[09:25] <amachu> We can do so ;-)
[09:25] <elky> amachu, since it was not a planned nomination on my behalf, i've not had the chance to ask him myself. which i would do for anyone before putting forth to the council.
[09:26] <ajmitch> elky: whosit what?
[09:28] <elky> ajmitch, see PM
[09:28] <amachu> elky: ok
[09:29] <amachu> elky: you can elaborate to everyone on the list
[09:29] <amachu> fine
[09:29] <amachu> we will wind up then for this week..
[09:29]  * elky headdesks
[09:30] <amachu> If there isn't any clash, we will likely have our next meeting on March 3 at 1500 UTC
[09:30] <amachu> elky: TheMuso: bye bye
[09:30] <elky> amachu, cya
[09:31] <TheMuso> bye, and damn, I won't be at that one, too late for me.
[09:33] <elky> yeah, that's too late for all the aussies
[14:59] <dholbach> hey robbiew
[14:59] <robbiew> howdy :)
[15:00] <Keybuk> mdz, cjwatson: ping?
[15:00] <cjwatson> yo
[15:01] <cjwatson> are we expecting sabdfl?
[15:01] <Keybuk> he's a little like the Spanish Inquisition
[15:01] <robbiew> ?
[15:01] <Keybuk> robbiew: NOBODY EXPECTS THE SPANISH INQUISITION
[15:02] <dholbach> NOBODY EXPECTS THE SPANISH INQUISITION!
[15:02] <cjwatson> robbiew: please tell me you've seen monty python
[15:02] <mdz> Keybuk: hi
[15:02] <cjwatson> http://en.wikipedia.org/wiki/The_Spanish_Inquisition_(Monty_Python)
[15:02] <robbiew> heh
[15:02] <mdz> I passed sabdfl in a meeting room on the way here, he didn't look finished
[15:02] <robbiew> cjwatson: yes..I have
[15:02] <mdz> clan says he's coming though
[15:03] <mdz> cjwatson,Keybuk: randa is helping to manage the agenda, it should be up to date on the wiki now
[15:03] <mdz> what I would like is to have the agenda always reflect everything which is outstanding for the TB
[15:03] <mdz> and at each meeting we will checkpoint status on everything and close out items which are complete
[15:03] <cjwatson> wfm
[15:03] <mdz> does that sound reasonable to you?
[15:03] <Keybuk> it dods
[15:03] <Keybuk> does too
[15:04] <mdz> #startmeeting
[15:04] <MootBot> Meeting started at 09:04. The chair is mdz.
[15:04] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:04] <mdz> [LINK] https://wiki.ubuntu.com/TechnicalBoardAgenda
[15:04] <MootBot> LINK received:  https://wiki.ubuntu.com/TechnicalBoardAgenda
[15:05] <cjwatson> is the mailing list question an old one? I hadn't encountered it before
[15:05] <mdz> agenda is now up to date
[15:05] <cjwatson> although I remember that we discussed the same question on the Community Council some time back
[15:05] <mdz> cjwatson: it's a new one
[15:06] <Keybuk> I thought the reason we had it private was it allowed us to discuss developer applications without them being Google fodder for their future job applications?
[15:06] <cjwatson> that was the same kind of reason that we determined community-council@ should be private, yes
[15:06] <mdz> Keybuk: was that it?  I couldn't remember and it's come up again, so I added it to the agenda
[15:06] <Keybuk> mdz: I certainly remember that discussion in Oxford
[15:07] <mdz> it may have been long enough to revisit it :-)
[15:07] <cjwatson> what are the arguments for making it public?
[15:07] <cjwatson> just that we should have arguments for keeping it private? :-)
[15:07] <Keybuk> and where is the proposal to make it public?
[15:08] <mdz> right here :-)
[15:08] <dholbach> In the case of the CC there are a few cases where conflict resolution happens before it gets discussed in a public meeting. Not sure how relevant that is in the case of the TB.
[15:08] <mdz> [TOPIC] Should technical-board@lists.ubuntu.com be public?
[15:08] <MootBot> New Topic:  Should technical-board@lists.ubuntu.com be public?
[15:08] <sabdfl> -1
[15:09] <mdz> not calling for a vote, I'm looking for input
[15:09] <cjwatson> I would at minimum be concerned of the need to review existing content before blatting it into public view, since people were expecting privacy
[15:09] <Keybuk> we should iterate the reasons for making it public
[15:09] <Keybuk> and the reasons for keeping it private
[15:09] <mdz> motu-council@ serves many similar purposes and is public
[15:09] <cjwatson> I'm not sure that I've been on the board long enough to have a feel for the sorts of things typically posted there at the moment
[15:09] <sabdfl> i bet they have conversations off-list
[15:09] <mdz> cjwatson: I can send you the archives if it would help
[15:09] <Keybuk> on the private side is the desire that developer application discussions not be archived by google forever
[15:10] <cjwatson> I have the archives, I just haven't had time to read them all :-)
[15:10] <Keybuk> (we do cc the developer involved, so they're not private to them)
[15:10] <mdz> technical-board@ serves two purposes
[15:10] <mdz> 1. a contact address to reach the TB (and only the TB)
[15:10] <cjwatson> I actually have a specific concern about motu-council@ based on recent conversations I've had elsewhere
[15:10] <mdz> 2. a mailing list to discuss TB matters
[15:10] <mdz> for 1., private is appropriate, but for 2., it is not really
[15:10] <cjwatson> I'm concerned that there is *not enough* negative discussion of applications, because people are concerned about "being mean"
[15:10] <cjwatson> and I don't think that's appropriate for a neutral applications committeee
[15:10] <cjwatson> -e
[15:10] <sabdfl> +1
[15:11] <mdz> one reason this has come up (this time) is that there are various people who are helping out the TB
[15:11] <sabdfl> then cc them
[15:11] <mdz> we can't control who is CCed when people mail technical-board@
[15:11] <mdz> and for my part, I can't always keep up with the mail to forward things
[15:11] <Keybuk> are you thinking specifically of randa here
[15:11] <mdz> there's also the general principle of transparency
[15:11] <mdz> Keybuk: also jono
[15:11] <mdz> and dholbach
[15:12] <Keybuk> my concern is that I think that people should expect privacy when they mail TB
[15:12] <cjwatson> I would be happy with specific extra people being subscribed to technical-board@, personally
[15:12] <sabdfl> i agree that transparency has value, so would be +1 on a public list and private list, if folks didn't object to the irritation of having two lists
[15:12] <mdz> [LINK] http://www.ubuntu.com/community/processes/techboard
[15:12] <MootBot> LINK received:  http://www.ubuntu.com/community/processes/techboard
[15:12] <sabdfl> there needs to be a quick, easy and memorable way to talk privately to or among the TB
[15:13] <Keybuk> while the nature of such mails is probably less problematic than CC (we don't tend to tender "blah sucks and hates me" type mails), I don't think it's quite zero
[15:13] <sabdfl> i don't know if LP supports private mailing lists
[15:13] <mdz> The Technical Board is responsible for the following documents and processes: 1. The Ubuntu Package Policy, 2. Ubuntu Release Feature Goals, 3. Ubuntu Package Selection
[15:13] <mdz> none of that stuff should be private
[15:13] <cjwatson> the CC certainly gets private discussion of major social blow-ups, or used to, which isn't the case for us
[15:13] <mdz> the page doesn't talk about developer applications, though I agree with the arguments to keep those more confidential
[15:13] <cjwatson> there is a separate website bug about the out-of-date-ness of that web page :-)
[15:14] <mdz> cjwatson: ye
[15:14] <mdz> s
[15:14] <mdz> an old one
[15:14] <dholbach> in case you're not aware of it: everything related to developer applications (in the case of the MC) is public
[15:14] <mdz> [LINK] http://launchpad.net/bugs/248729
[15:14] <MootBot> LINK received:  http://launchpad.net/bugs/248729
[15:14] <cjwatson> dholbach: have you considered whether this is in fact desirable?
[15:14] <dholbach> cjwatson: we did not get any complaints or concerns about it yet
[15:15] <cjwatson> I heard a specific concern recently that somebody wanted to express negative feedback, and was told not to be mean
[15:15] <Keybuk> dholbach: have you considered that you won't get complaints or concerns if the compaints and concerns are public too?
[15:15] <mdz> perhaps the question I've asked is too broad; for my purposes it would be sufficient if TB delegates could be subscribed to the list
[15:15] <cjwatson> now, I haven't gone and looked into the history, but this is something that concerns me deeply
[15:15] <mdz> cjwatson: could we handle the question about motu-council as a separate agenda item?
[15:15] <cjwatson> certainly
[15:15] <dholbach> there's surely a middle ground of expressing concern or advising to "reapply again in a few weeks" without being mean
[15:15] <cjwatson> although I think it's germane to this point
[15:15] <mdz> cjwatson: agreed, just trying to steer to a conclusion
[15:16] <cjwatson> dholbach: there is, but in some cases the response simply ought to be negative
[15:16] <cjwatson> I realise that both of us tend towards the state of being nice to people where possible :-)
[15:16] <mdz> are there any objections to subscribing select people to the TB list who are participating but not actually on the TB?
[15:16] <cjwatson> I have no objection to that
[15:16] <Keybuk> I have no objections either
[15:17] <mdz> sabdfl: thoughts on that option?
[15:17] <sabdfl> +1
[15:17] <sabdfl> that should be transparent, though :-)
[15:17] <mdz> ok
[15:17] <mdz> thanks
[15:17] <mdz> separately, I'd like to reaffirm that where possible, we should shift discussion of public matters from t-b@ onto ubuntu-devel@
[15:18] <mdz> e.g. policy discussions
[15:18] <sabdfl> mdz, i think we could include delegates in private issues explicitly by cc
[15:18] <sabdfl> for example, jono or dholbach or jorge
[15:18] <sabdfl> or randa
[15:18] <sabdfl> where appropriate
[15:18] <cjwatson> on general principles we have usually said that anything in Ubuntu that can be public should be public, so that seems a reasonable statement to me
[15:18] <sabdfl> i think the majority of TB discussions could be public, which lends support to the idea that tb@ be public
[15:19] <cjwatson> by comparison we encourage discussion to move from #distro (irc.canonical.com) to #ubuntu-devel
[15:19] <mdz> I'm happy for it to stay private so long as we only use it for discussions which ought to be private, and nothing else
[15:19] <mdz> e.g. if someone emails technical-board@ and raises a technical concern, we must redirect that to ubuntu-devel@
[15:19] <sabdfl> fine by me
[15:20] <mdz> this is easy to forget to do, etc., but if we agree we can try to make the best of it
[15:20] <mdz> ok to move on?
[15:20] <mdz> [TOPIC] MOTU Council nominations (dholbach)
[15:20] <MootBot> New Topic:  MOTU Council nominations (dholbach)
[15:21] <mdz> dholbach: I put your name on this but just noticed it was persia who emailed t-b@
[15:21] <sabdfl> i propose we nominate dholbach, and two non-canonical candidates
[15:21] <Keybuk> this is a re-nomination of dholbach, right?
[15:21] <mdz> dholbach: can you represent MC here?
[15:21] <sabdfl> yes
[15:21] <dholbach> mdz: technically... I'm not on the MC right now :)
[15:22] <sabdfl> dholbach has expired
[15:22] <dholbach> soren, nixternal, persia: here? :)
[15:22] <sabdfl> (from the MC ;-))
[15:22] <soren> hm?
[15:22] <dholbach> I think it's a good idea to have more members on the MC
[15:22] <Keybuk> who are the proposed other nominees?
[15:24] <mdz> Keybuk: I don't think that's been publicly discussed, it's on t-b@ though
[15:24] <mdz> Subject: MOTU Council list of nominees for MOTU Council Election
[15:25] <Keybuk> are we not discussing them now?
[15:25] <Keybuk> I understood this agenda item to be "nominate people to the MOTU Council"
[15:25] <mdz> I just want to move the process forward; what's the next step?
[15:25] <mdz> is there an agreed process for how council nominations work?
[15:26] <mdz> (apart from TB and CC)?
[15:26] <Keybuk> there seems to be two obvious choices
[15:26] <Keybuk> the TB decides
[15:26] <Keybuk> the Developers decide
[15:26] <Keybuk> the latter seems more desirable to me
[15:26] <mdz> for the TB, it is "Appointments to the board are made by Mark Shuttleworth subject to confirmation by a vote amongst the maintainers"
[15:27] <dholbach> there's https://wiki.ubuntu.com/CommunityCouncil/Delegation and we made use of it in the past
[15:27] <mdz> dholbach: ah, that's useful, thanks
[15:27] <mdz> the CC has done a lot more official delegation than we have
[15:27] <sabdfl> i thought we were following https://wiki.ubuntu.com/CommunityCouncil/Delegation
[15:27] <mdz>     *
[15:27] <mdz>       The CC (and TB) will determine a shortlist of candidates and set up Launchpad polls accordingly so team members can vote.
[15:27] <mdz>     * The polls might take the form of confirmation votes or of a race between more candidates than the available seats on the Team Council.
[15:27] <sabdfl> and were already at the point of having proposed nominees, from the MC
[15:28] <sabdfl> i was suggesting that the TB put up three candidates for confirmation vote
[15:28] <mdz> so the questions are:
[15:28] <mdz> 1. how many slots do we need to fill?
[15:28] <mdz> 2. who are the nominees?
[15:28] <Keybuk> sabdfl: three candidates for how many seats?
[15:28] <sabdfl> three for three, confirmation not a race
[15:28] <sabdfl> dholbach asked that we have an odd number of seats
[15:28] <mdz> there is only one seat opening up, but it's been suggested that the council should be expanded
[15:29] <sabdfl> for quorum / voting reasons
[15:29] <mdz> I'm OK with three seats. keybuk? cjwatson?
[15:29] <Keybuk> +1
[15:29] <mdz> that's replacing the one which expired, and adding two
[15:29] <cjwatson> that would result in an even number of seats
[15:30] <cjwatson> oh, no it wouldn't
[15:30] <sabdfl> MC has been well organised, growing it gives an opportunity to develop more leadership talent
[15:30] <cjwatson> +1
[15:30] <mdz> sabdfl: I have some open questions about how the role of MC will change with ArchiveReorganisation
[15:30] <sabdfl> me too
[15:30] <cjwatson> so does CommunityCouncil/Delegation mean that this needs to be run past the CC too?
[15:31] <sabdfl> no
[15:31] <mdz> agreed, no
[15:31] <mdz> ok, so we're agreed on 3 seats
[15:31] <sabdfl> CC has already delegated this to TB, it's fine to redelegate
[15:31] <sabdfl> (wearing my CC hat)
[15:31] <Keybuk> did CC delegate this?
[15:31] <Keybuk> I thought this was a TB duty that the TB decided to delegate all on its own ;)
[15:31] <Keybuk> the CC delegates membership assignment to the TB
[15:32] <Keybuk> but that's orthogonal
[15:32] <dholbach> I was under the impression that because of the power to grant ubuntumembers membership the MC would report to CC and TB?
[15:32] <sabdfl> Keybuk: reference appointment process to the TB, i guess
[15:32]  * Keybuk makes delegation pancakes
[15:32] <sabdfl> nevertheless, i can say this is up to the TB
[15:32] <sabdfl> we can do it however the TB wants
[15:32] <dholbach> in any case there were no objections raised in the CC when the topic was brought up
[15:33] <sabdfl> this is entirely about how the ubuntu development team picks and organises itself
[15:33] <mdz> dholbach: right, so I think we're free to proceed
[15:33] <dholbach> I'd think so :)
[15:33] <mdz> so we have a list of suggestions from the MC itself, and need to decide on nominees
[15:33] <mdz> I'm happy with the suggestions sabdfl made on t-b@
[15:33] <sabdfl> my recommendation to exlcude one candidate is based purely on the fact that he now works for canonical
[15:33] <sabdfl> and we want to broaden representation outside canonical
[15:34] <mdz> in <4993CCBA.5000202@ubuntu.com>
[15:34] <sabdfl> that may be unfair on the individual
[15:34] <sabdfl> i'm loosely attached to the idea
[15:34] <Keybuk> mdz: I agree, +1 on sabdfl's proposed list
[15:34] <mdz> cjwatson: ?
[15:34] <sabdfl> dholbach of course works for canonical, but i feel he's been *fantastic* in this role
[15:34] <dholbach> sabdfl: thanks a lot for the flowers
[15:34] <sabdfl> and so it's worthwhile to me to maintain the continuity, since dholbach nominated himself and says he enjoys it
[15:34] <cjwatson> I don't have any problem with the specific three people proposed
[15:35] <cjwatson> I don't know Nathan very well myself
[15:35] <mdz> I'm supportive of Canonical participating in the council, but agree we should aim to keep the ratio low
[15:35] <sabdfl> a run-off would be a more interesting poll
[15:35] <cjwatson> but he seems to have been effective in the limited interactions I've had with him
[15:35] <mdz> will the confirmation vote be among MOTU or all developers?
[15:35] <mdz> I suggest all developers
[15:35] <sabdfl> i'm easy
[15:35] <dholbach> me too
[15:35] <ScottK> All developers are MOTU.
[15:35] <cjwatson> ... I just made the MOTU team include ubuntu-core-dev ;-)
[15:36] <cjwatson> (as discussed on ubuntu-devel@)
[15:36] <sabdfl> well that solves that
[15:37] <mdz> ok
[15:37] <mdz> that sounds like consensus on the three nominees
[15:38] <mdz> they are: Daniel Holbach, Nathan Handler, and Jonathan Davies
[15:38] <mdz> sabdfl: will you set up the polls?
[15:38] <sabdfl> sure
[15:38] <mdz> [ACTION] sabdfl to set up Launchpad polls for MC nominee confirmations
[15:38] <MootBot> ACTION received:  sabdfl to set up Launchpad polls for MC nominee confirmations
[15:38] <mdz> [TOPIC] SRU guidelines for Landscape (robbiew)
[15:38] <MootBot> New Topic:  SRU guidelines for Landscape (robbiew)
[15:38] <cjwatson> so a poll of all developers will now include per-package uploaders (of whom the only current example is Stefan Bader)
[15:38] <cjwatson> just for the record
[15:38] <mdz> robbiew: are you here?
[15:38] <sabdfl> cjwatson: ~ubuntu-dev right?
[15:38] <cjwatson> assuming you use ~ubuntu-dev
[15:38] <robbiew> mdz: yes
[15:39] <robbiew> I placed the link to the LandscapeSRU process in the agenda.
[15:39] <mdz> so the decision at hand is whether to confirm an exception to the SRU process based on that document
[15:39] <robbiew> From what I understand, sometimes the Landscape client code must be updated to take advantage of improvements/updates to the Landscape server...and this is their reasoning for the need to be part of an SRU.
[15:40] <mdz> I understand from robbiew that the SRU team is OK with it and would like for the TB to make the final decision, is that correct?
[15:40] <ScottK> We have a lot of packages in the archive for which that is true.
[15:40] <cjwatson> we've been back-and-forwarding on this in ~ubuntu-sru for months
[15:40] <mdz> robbiew: right, that was the reason for asking
[15:40] <cjwatson> and feel we have finally reached agreement, after a lot of extra commitments made by the Landscape team
[15:40] <mdz> we asked that they provide an explanation of what processes they will follow in order to ensure their updates are free of  regressions
[15:40] <mdz> which is the purpose of the SRU process
[15:40] <cjwatson> I think those commitments could serve as a template for other projects, at least in principle
[15:41] <robbiew> +1
[15:41] <cjwatson> I absolutely do not want to make an exception for Landscape just because it's Landscape
[15:41] <mdz> cjwatson: agreed, though I also don't want to block it on generalizing the policy
[15:41] <cjwatson> I want it to be generalisable, not necessarily generalised
[15:41] <mdz> I'd like to propose we consider an exception for Landscape based on what has been provided, and then use that as a precedent when this comes up next
[15:42] <cjwatson> so the reasons why I think Landscape is suitable, given the negotiations to date, are:
[15:42] <mdz> if another project can meet the standard we set, then we should consider that as well
[15:42] <cjwatson>  * it has an extensive test suite (yes, like other packages in the archive)
[15:42] <cjwatson>  * its developers have committed to doing specific QA on a variety of upgrade and fresh-install combinations
[15:43] <cjwatson>  * it has very limited interactions with the rest of Ubuntu, that are straightforward to enumerate so that we can have a clear idea of regression potential
[15:43] <cjwatson>  * those interactions have been specifically called out in the mandatory QA process that each upgrade must go through
[15:43] <sabdfl> we must surely have a couple of other upstreams that meet any reasonable such standard
[15:43] <sabdfl> i would like to go out with a document that references more than just landscape
[15:43] <cjwatson>  * its developers have agreed to work within the Ubuntu update process
[15:43] <mdz> impact on non-Landscape users is pretty tightly constrained, and I think Landscape should be able to take responsibility for the impact on their own users
[15:44] <mdz> sabdfl: I fear that will delay what has already been a very drawn out process
[15:44] <ScottK> Landscape client is included by default on Server installs.
[15:44] <cjwatson> sabdfl: we already have a couple of other examples where we do micro-updates; I agree with mdz that I'd like to avoid blocking on having a general policy as long as we're broadly agreed that the principles are general
[15:44] <sabdfl> ok
[15:44] <cjwatson> ScottK: yes, this is true, and this is part of why it has taken so long to come to an agreement
[15:45] <mdz> this was originally raised by the Landscape developers in https://bugs.edge.launchpad.net/ubuntu/+source/landscape-client/+bug/306360
[15:45] <cjwatson> ScottK: however, it has rather limited actual functions for users who don't sign up for server access, which are called out in LandscapeUpdates (basically, update-motd)
[15:45] <mdz> which was filed 2008-12-08
[15:45] <cjwatson> this has been discussed for a lot longer than that
[15:46] <mdz> cjwatson: true
[15:46] <cjwatson> although, yes, I think that was probably the first public mention
[15:46] <ScottK> Which is fine, just that the potential impacts involve essentially all server installs.
[15:46] <ScottK> even if the risk is low
[15:46] <sabdfl> could we at least invite upstreams of other projects that want this to approach the TB?
[15:47] <mdz> ScottK: so we want assurance that the potential impact is limited, and that the testing conducted is sufficient to provide the level of assurance we expect for stable updates
[15:47] <ScottK> Yes.
[15:47] <cjwatson> ScottK: yes. It does concern me, but less than it might due to it being fairly self-contained
[15:47] <mdz> sabdfl: I suggest that we decide for Landscape initially, with a sufficiently detailed rationale that it can be generalized in the future
[15:47] <cjwatson> which is why the QA process suggested is a lot more stringent, and will be a lot more time-consuming for the Landscape team frankly, than most other SRU work
[15:48] <mdz> rather than require a general policy in order to decide on Landscape
[15:48] <mdz> we have made exceptions for several other packages already without a general policy
[15:48] <cjwatson> sabdfl: I'm concerned about inviting upstreams in general
[15:48] <cjwatson> sabdfl: every upstream, without exception to my knowledge, wants distributions to ship the newest available version
[15:48] <mdz> (kernel, app-install-data-commercial, tzdata, hal-info and mobile-broadband-provider-info, FYI)
[15:49] <cjwatson> sabdfl: I think we only have bandwidth to do this for limited high-quality high-value cases)
[15:49] <cjwatson> s/)$//
[15:49] <sabdfl> i think a landscape-only policy that doesn't convey our openness to doing this more generally would be send the wrong message and be poorly received
[15:49] <sabdfl> we are definitely *open* to doing this more generally, so we can say that
[15:49] <sabdfl> and i agree with cjwatson on bandwidth
[15:49] <cjwatson> yes, I think there's middle ground between "we're open to discussions" and "please come and bang down our door"
[15:50] <sabdfl> ok
[15:50] <cjwatson> so stepping back just a moment, if I have time
[15:50] <mdz> we have 10 minutes
[15:50] <cjwatson> kernel, hal-info, mobile-broadband-provider-info come under general category of hardware support (often due to new hardware being introduced)
[15:50] <cjwatson> app-install-data-commercial comes under the general category of enabling something outside the primary archive
[15:51] <cjwatson> tzdata comes under the general category of coping with external events that we can't ignore
[15:51] <cjwatson> (i.e. legislative environment)
[15:51] <cjwatson> landscape is approximately under the same category as app-install-data-commercial, to me
[15:52] <cjwatson> and in general, all of these could be grouped as "updates necessary to deal with changes outside the Ubuntu archive"
[15:52] <cjwatson> external events that we can't necessarily encapsulate in one nice stable release
[15:52] <mdz> it's similar to the various packages (mostly in universe) which are using web APIs or screen-scraping, and occasionally get broken by server-side changes
[15:52] <cjwatson> MSN, ICQ come to mind too
[15:52] <mdz> cjwatson: right
[15:53] <cjwatson> where everything is internal to the operating system (in the wide sense) that we release, I don't think that we should generally contemplate updates of this nature
[15:53] <sabdfl> anything which talks to unversioned web api's is going to get this problem
[15:53] <mdz> to try to move things ahead, it sounds like the main question is the extent to which this decision should be specific to Landscape vs. setting a general policy
[15:53] <sabdfl> liblaunchpad.py
[15:53] <mdz> are there any other concerns with the proposal?
[15:53] <mdz> we'll need to take this offline it looks like
[15:54] <Keybuk> I don't have any particular concerns
[15:54] <mdz> but I'd like to do so with a clear agenda so we can drive to a decision
[15:54] <cjwatson> ScottK raised a QA concern which is basically similar to what the SRU team raised when approached with this
[15:54] <sabdfl> i'm +1 on an a policy for landscape that outlines the criteria we used to make the decision and includes the sentence ("the TB will consider additional applications in due course following similar criteria")
[15:54] <sabdfl> or thereabouts
[15:54] <cjwatson> I'm happy to elaborate on that if requested, perhaps by mail
[15:54] <mdz> we've entrusted the SRU team to assess the QA aspect and will review that ourselves as well based on the document
[15:54] <cjwatson> but the body responsible for stable QA has now signed off
[15:55] <mdz> based on sabdfl's input, I think this requires more than a simple vote
[15:55] <mdz> we'll need to write up a formal decision with rationale which can be referred back to as precedent
[15:55] <mdz> cjwatson: new guy, want to take the action for that? ;-)
[15:55] <robbiew> ouch
[15:55] <cjwatson> yeah, I can do that
[15:56] <mdz> thank you
[15:56] <mdz> [ACTION] cjwatson to write up decision which we can then vote on
[15:56] <MootBot> ACTION received:  cjwatson to write up decision which we can then vote on
[15:56] <cjwatson> (or try, anyway)
[15:56] <mdz> [TOPIC] Upload permission for Romain Francoise for 'emacs-snapshot'
[15:56] <MootBot> New Topic:  Upload permission for Romain Francoise for 'emacs-snapshot'
[15:56] <mdz> I don't have any news here, but this remains open
[15:56] <mdz> Jono has been in touch with Romain
[15:57] <sabdfl> https://wiki.ubuntu.com/UbuntuDevelopers/PerPackageUploaders
[15:57] <sabdfl> do we have anything in writing to support him against those criteria?
[15:58] <dholbach> sabdfl: I did not roll it into UbuntuDevelopers yet - do you think we can make the "process" section a bit more explicit?
[15:58] <sabdfl> dholbach: sure
[15:59] <mdz> he is @gnu.org and @debian.org
[15:59] <Keybuk> sabdfl: my objection remains a simple one
[15:59] <dholbach> it'd be nice if they'd just use https://wiki.ubuntu.com/UbuntuDevelopment/DeveloperApplicationTemplate as normal and either let MC or the TB (you decide) know about it
[15:59] <Keybuk> Romain has only ever had one sponsored upload to Ubuntu
[15:59] <mdz> sabdfl: for my part, the simple (but unfortunate) answer is "I don't know"
[15:59] <sabdfl> https://edge.launchpad.net/ubuntu/+source/emacs-snapshot
[16:01] <ttx> o/
[16:01] <ttx> ^ Koon
[16:01] <cjwatson> ttx: sorry, TB meeting still underway
[16:01] <mdz> we have to wrap up and clear the channel for the next meeting
[16:01] <cjwatson> mdke's application was dealt with by mail
[16:01] <mdz> I'm behind on email, haven't even read it
[16:02] <mdz> but if the three of you agree I'm fine
[16:02] <cjwatson> Mark and I +1ed, I actioned
[16:02] <dholbach> mdz, sabdfl: shall I send you a proposal for the clarification of the per-package-uploader process by mail?
[16:02] <cjwatson> oh, which reminds me, better add mdke to ~ubuntu-dev then
[16:02] <mdz> codecs in ffmpeg, jono is working on
[16:02] <mdz> archive reorg governance I'm not sure of the status
[16:02] <mdz> is it blocked on the technical proposal?
[16:02] <sabdfl> implementation of
[16:02] <cjwatson> still on me to rework proposal following Berlin I think
[16:02] <cjwatson> (sorry)
[16:03] <mdz> sabdfl: I think we can decide the governance model before it's implemented, and should do so to avoid a chaotic transition
[16:03] <mdz> sounds like it's blocked on Colin
[16:03] <mdz> we need to wrap, I'll update the agenda
[16:03] <cjwatson> Daniel asked me for a call this week, will probably manage that a bit later
[16:03] <sabdfl> soyuz team is just laying the foundations, we can use them as we wish
[16:03] <mdz> [ACTION] cjwatson to rework archive reorg proposal to unblock governance work
[16:03] <MootBot> ACTION received:  cjwatson to rework archive reorg proposal to unblock governance work
[16:03] <mdz> #endmeeting
[16:03] <MootBot> Meeting finished at 10:03.
[16:03] <mdz> ttx: all yours
[16:04] <ivoks> \o/
[16:04] <zul> heylo
[16:04] <ttx> mdz: sorry for interrupting :)
[16:05] <mdz> ttx: no worries
[16:05]  * sommer is sortof here :)
[16:05] <ScottK> o/
[16:05] <dendrobates> o/
[16:05] <zul> \0
[16:05] <ttx> zul: "mine is bigger" ?
[16:06] <zul> ttx: yes it is
[16:06] <nealmcb> o/
[16:06] <ttx> mathiaz isn't available so I'll try to replace him
[16:06]  * ttx <-- the hacker formerly known as koon
[16:07] <ttx> #startmeeting
[16:07] <MootBot> Meeting started at 10:07. The chair is ttx.
[16:07] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:07] <ttx> Today's agenda: https://wiki.ubuntu.com/ServerTeam/Meeting
[16:07] <ttx> Last week minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20090217
[16:08] <ttx> [TOPIC] Review ACTION points from previous meeting
[16:08] <MootBot> New Topic:  Review ACTION points from previous meeting
[16:08]  * ttx frantically reads up last meeting minutes
[16:09] <ttx> Postfix and Dovecot integration: ivoks to create a wiki page for ideas about improving the mail server task post-jaunty
[16:09] <ivoks> here
[16:09] <ttx> ivoks: ?
[16:09] <ivoks> well, i've set up a wiki
[16:09] <ivoks> small, but a start
[16:09] <ivoks> https://wiki.ubuntu.com/ServerTeam/MailServer
[16:09] <ivoks> which is for karmic, so no much point in discussing now
[16:10] <soren> ivoks: cjwatson had concerns about the approach used in the dovecot/postfix integration. Were they adressed?
[16:10] <ivoks> soren: when? 2 weeks ago?
[16:10] <soren> ivoks: Think so, yes.
[16:10] <ivoks> soren: we've solved the whole thing according to his advice
[16:10] <dendrobates> we can address them at UDS, if not.
[16:11] <ivoks> unless there are some new
[16:11] <ivoks> which i'm unaware of :)
[16:11] <ttx> sounds good
[16:11] <soren> ivoks: No, nothing new.
[16:11] <ivoks> ok
[16:11] <ttx> Power management: kirkland to blog about using suspend/resume for servers.
[16:12] <dendrobates> ttx: he is not here, but is blocked on me.
[16:12] <soren> I was just checking. I haven't had a time to review it myself.
[16:12] <soren> ivoks: ^
[16:12] <dendrobates> I will give him approval as soon as I manage to talk to him.
[16:12] <ttx> ok.
[16:12] <ttx> [TOPIC] Roadmap review
[16:12] <MootBot> New Topic:  Roadmap review
[16:12] <ivoks> soren: test it, should be fully functional and i don't think there'll be anything else for jaunty
[16:13] <dendrobates> or if he reads these minutes, go ahead.
[16:13] <ttx> Anyone has a status report on part of the roadmap that would be assigned to himself ?
[16:14] <sommer> the doc.u.c site is updated and ready for reviews :)
[16:14] <ScottK> vorian has been doing some good work on the libdb consolidation.
[16:15] <ttx> The roadmap page looks a little... oudated
[16:15] <vorian> yes, slight snag with libdb4.4 though
[16:15] <ttx> outdated, even.
[16:16] <vorian> ldiskfsprogs seems to only want to build/work with libdb4.4
[16:17] <ttx> ok. Soren, want to do an update on the virtualization front ?
[16:17] <soren> I could. :)
[16:17] <soren> So, since we last saw each other, Eucalyptus entered the archive.
[16:18] <soren> This gives us a free implementation of EC2 and S3 that you can deploy on your own infrastructure.
[16:18] <soren> This is convenient for testing things before pushing them to the real EC2 or if you want to offer computing ressources internal in your organisation, but policies forbids putting data or code on something as public as EC2.
[16:19] <soren> Alpha testers are very welcome.
[16:20] <sommer> soren: what's need to test?
[16:20] <ttx> soren: is there any start page / instructions for first-time testers ?
[16:20] <soren> ttx: No, not yet. There's still some things that needs fixing before it's ready for mass testing.
[16:20] <ivoks> i might test that :)
[16:20] <soren> Once they're sorted out, I'll post a call for testing.
[16:21] <ttx> ok.
[16:21] <ivoks> soren: if i got you right, one can't offer S3 like service
[16:22] <ivoks> soren: but can use it inside it's own web project?
[16:22] <ivoks> s/it's/its/
[16:22] <soren> ivoks: Yes, you can offer this to other people as well.
[16:23] <ivoks> oh
[16:24] <ttx> soren: anything else ?
[16:24] <soren> No, I'm good.
[16:24] <ttx> ok. We are missing a lot of people, anyone else has a roadmap item he wants to give an update on, now that feature freeze is in effect ?
[16:25] <ScottK> I'll just toss out that clamav 0.95 is imminent.
[16:25] <ScottK> I expect an RC this week or next.
[16:25] <ScottK> It's known to break all the libclamav rdepends.
[16:25] <sommer> the last thing for the serverguide is the cloud stuff, can you ping me when it's ready to test soren?
[16:26] <ttx> ScottK: i suppose it was accepted as a FFe ?
[16:27] <ScottK> If we can get the rdepends working, I'm sure it will be.
[16:27] <ScottK> We'd really rather not release with an obsolete clamav.
[16:27] <soren> sommer: Yes, I will.
[16:27] <ttx> I agree with that.
[16:27] <sommer> soren: awesome, thanks :)
[16:27] <ivoks> +1 for clamav
[16:28] <ttx> ok, then lets' move on to:
[16:28] <ttx> [TOPIC] Open Discussion
[16:28] <MootBot> New Topic:  Open Discussion
[16:28] <ivoks> i have one thing...
[16:28] <ttx> Good.
[16:28] <ivoks> there are some users that complaing on our effort on supporting LTS
[16:29] <ttx> ivoks: as in: not SRUing enough ?
[16:29]  * kirkland is here now
[16:29] <ivoks> if we could give more love to LTS somehow, that would be great
[16:29] <ivoks> ttx: well, they do have a point with on thing
[16:29] <ttx> most complains I've seen are for backports
[16:29] <ScottK> As in wanting more?
[16:29] <ivoks> if we fix a bug in lts+ release, we don't backport that fix
[16:30] <ivoks> and we just mark bug as fixed
[16:30] <ivoks> while, in LTS it's not
[16:30] <ttx> ScottK: as in "please ship that new version, it's so good the LTS needs it"
[16:30] <ScottK> Well we do have backports for this.
[16:30] <ivoks> no, i'm against new versions
[16:30] <ttx> ScottK: that's my usual answer, but they usually don't like it.
[16:31] <ivoks> i'm for fixing bug in current and lts release, not just declaring it fixed since it is fixed in, for example, intrepid or jaunty
[16:31] <zul> yes well if thats the case then the backports need more testing that backports dont break things
[16:31] <ScottK> Which is why backports is great.  You don't have to have them.
[16:31] <ScottK> zul: backports very rarely break things.
[16:31] <dendrobates> and we don't have to include them in the point releases.
[16:31] <ScottK> Yes.
[16:32] <ivoks> (fwiw, i didn't talk about backports)
[16:32] <ScottK> OK
[16:32] <ttx> ivoks: so your point is that we lose sight of valid SRU bugs because their development-release task is Fix Released ?
[16:32] <ivoks> ttx: correct
[16:32] <ScottK> If any of you are MOTU and interested in getting involved in the backports process, we need more people to review backports requests.  Please contact me.
[16:33] <ivoks> i'm just saying, maybe we should pay more attention on these things
[16:34] <ttx> We could have a review of fixed bugs and decide if they make likely/badly-wanted/not wanted candidates for the SRU process
[16:34] <sommer> ivoks: is there a list of such bugs?  I can probably help with them
[16:34] <ivoks> or ask users what they think about LTS releases?
[16:34] <sommer> err help test anyway
[16:34] <ScottK> ivoks: Users generally don't find it OK to leave any bugs unfixed.
[16:34] <ivoks> sommer: i don't have a list, these were complaints on #ubuntu-server 2 days ago
[16:35] <ivoks> sommer: from couple of users
[16:35] <sommer> ivoks: okay, I may have missed them, I'll try and find them
[16:35] <ttx> I agree we tend to lose sight of the fixed-in-development-release bugs. And the nomination process doesn't really help.
[16:35] <ivoks> sommer: check sunday
[16:37] <ttx> any suggestion on a process we could use to better track that ?
[16:38] <sommer> could we add tags like hardy-needed, intrepid-needed, etc then remove them when the fix is committed?
[16:38] <ttx> like systematically nominating for relevant releases, and have a session where we look at them and accept/deny them ?
[16:38] <sommer> not sure if that fits, but just a suggestion
[16:38] <ttx> sommer: theorically that's what nominations are for
[16:39] <sommer> ttx: yep, that's better than :)
[16:39] <ivoks> right, nominations should be fine for that
[16:39] <ivoks> if bug is reported in LTS, then fix it in LTS and development-release
[16:39] <ivoks> not just development-release
[16:40] <ivoks> i'm just acting on users feedback :)
[16:40]  * ttx misses the LP-foo required to not losing sight of fixed-in-development-release bugs. Any way to get a list of "nominated for hardy" bugs ?
[16:41] <soren> ttx: Yes. Hang on.
[16:41] <ttx> hm.
[16:42] <ttx> we can't really nominate all relevant bugs and then jave a session of acceptance/denial
[16:42] <ttx> s/jave/have/
[16:42] <soren> https://bugs.edge.launchpad.net/ubuntu/hardy/+nominations I think.
[16:42] <ttx> since for people with superpowers, nominating also does accept the nomination.
[16:42] <soren> s/edge// if you're not cool enough for that.
[16:43] <ttx> :P
[16:43] <dendrobates> I can approve nonimations.
[16:43] <soren> It seems I can, too.
[16:43] <ivoks> i can too :)
[16:44] <dendrobates> soren: really?
[16:44] <dendrobates> hmm.
[16:44] <ivoks> wow, i have superpowers!
[16:44] <ttx> dendrobates: the problem is not really approving. Suppose a core-dev wants to say "this one affects hardy" but not really say "this is a good SRU candidate".
[16:44] <dendrobates> I thought it was restircted to drivers.
[16:44] <ivoks> :)
[16:44] <soren> dendrobates: That page I just linked to shows radio buttons that I can click on. I haven't tried it, but LP usually only shows you these things if you can actually change thenm.
[16:44] <ttx> if the core-dev nominates, it will be automatically accepted, no ?
[16:45] <soren> dendrobates: ubuntu-core-dev is listed as driver as well.
[16:45] <soren> dendrobates: https://edge.launchpad.net/ubuntu/hardy
[16:45] <dendrobates> ahh, I think that is new.
[16:45] <ttx> so you can't really say "affects hardy" and let the bug-reviewing department decide on SRU potential
[16:45] <soren> I do, too.
[16:46] <ttx> ivoks: that's a good point, I propose you add it as a proper agenda item for next week session.
[16:46] <ivoks> ok
[16:46] <ttx> and we can brainstorm during the week.
[16:46] <soren> ivoks: I'm curious why you can, though. You're not core-dev, are you?
[16:46] <ivoks> soren: i'm not
[16:46] <ttx> We could have some QA people joining us
[16:47] <soren> ivoks: *shrug*
[16:47] <ivoks> ttx: imho, we should reach to our users and ask them what they want; push brainstorm.u.c a bit more
[16:47] <ivoks> that's the easiest and best way to world domination :)
[16:47] <dendrobates> ivoks: but only if we are going to take the suggestions seriously.
[16:48] <ivoks> dendrobates: right
[16:48] <ttx> ACTION: ivoks to add to next week agenda an item about better SRU bugtracking
[16:48] <ttx> [ACTION] ivoks to add to next week agenda an item about better SRU bugtracking
[16:48] <MootBot> ACTION received:  ivoks to add to next week agenda an item about better SRU bugtracking
[16:49] <ttx> bah bot
[16:49] <ScottK> I'm somewhat reluctant to do this, but I'm going to bring up Bug 268447 - I think it makes a poor initial impression for new Ubuntu Server users.
[16:49] <ScottK> I'm not arguing what's there isn't allowable, just I don't think it's a good idea for Ubuntu.
[16:50] <ttx> ivoks: if you'er MOTU you can apparently accept nominations for universe packages.
[16:50] <ivoks> ttx: right
[16:51] <ivoks> ScottK: i understand you, and from community point of view, that might not be best thing to pop onto new users; but i personaly don't have anything against that line :|
[16:51] <ttx> ScottK: if it's not a bug, then that should be raised in more "discussion" channels, I guess
[16:51]  * ScottK didn't file it as a bug.
[16:52] <ttx> ScottK: I did ;)
[16:52] <ScottK> This would be doing that (raising it in discussion channels).
[16:52] <nealmcb> I agree with ScottK.
[16:53] <ScottK> Just consider if we want every package that writes to stdout to include links to proprietary add-ons?
[16:53] <ScottK> I'm pretty sure we don't, but as long as that's there, it's very hard to argue against it.
[16:53] <ivoks> like firefox on BBC?
[16:53] <ivoks> you have a link to launchpad inside every app on desktop
[16:53]  * ScottK gets his BBC news via email, so dunno.
[16:54] <ScottK> But Launchpad is used by Ubuntu for stuff.
[16:54] <ScottK> Landscape is a seprate product.
[16:55] <ScottK> At least for me the only Launchpad stuff I find in apps is about filing bugs.
[16:55] <dendrobates> This is outside of our realm of control.  But your opinion will be noted and report up.
[16:55] <nealmcb> What would be more appropraite for the MOTD would be a link to server documentation either on the web or via a local help application - I forget where that discussion ended up
[16:55] <dendrobates> We did our best to make it as innocous as possible, but I understand your concern.
[16:56] <ScottK> dendrobates: If it's in an Ubuntu Server package, I disagree.
[16:56] <ScottK> It is exactly in our realm of control.
[16:56] <ivoks> would 'Find out how to manager your server on http://www.ubuntu.com/manager' be better?
[16:56] <ivoks> and from there, offer canonical and 'community' solutions?
[16:56] <ScottK> Yes, I think it would if it offered both.
[16:57] <ivoks> but, we don't have community way of doing this :(
[16:57] <nealmcb> and launchpad doesn't cost money and will be open source within 6 months
[16:57] <dendrobates> ivoks: I agree, I will try and push that. We should discuss it briefly at UDS.
[16:57] <ivoks> s/manager/manage/ lol
[16:58] <ivoks> dendrobates: web site could provde more information about landscape, so should be even better for canonical
[16:58] <ttx> ok, let's wrap up
[16:58] <ScottK> If you scroll up to the tech board meeting just before us sabdfl made it clear when discussing Landscape that he didn't want it to get special priviledges because it was Landscape (and a Canonical product), but that it might be an example of more general cases.
[16:58] <ScottK> dendrobates: I'd like to see this resovled before release, so UDS is a bit late.
[16:58]  * ScottK stops
[16:59] <nealmcb> ivoks: good idea - it could combine my "help" idea and the more active management that motd readers might want
[16:59] <ttx> it's a complex subject for an open discussion item, I guess
[16:59] <ttx> [TOPIC] Agree on next meeting date and time
[16:59] <MootBot> New Topic:  Agree on next meeting date and time
[16:59] <ttx> next week, same time, same place ?
[16:59] <ivoks> +1
[16:59] <ttx> hopefully mathiaz won't lose network connection 5 minutes before the meeting starts.
[17:00] <ttx> and the meeting will look better prepared :)
[17:00] <ivoks> escuses :)
[17:00] <ivoks> excuses
[17:00] <ttx> #endmeeting
[17:00] <MootBot> Meeting finished at 11:00.
[17:01] <apw> #startmeeting
[17:01] <MootBot> Meeting started at 11:01. The chair is apw.
[17:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:01] <apw> This is the weekly kernel team meeting
[17:01]  * smb_tp waves
[17:01]  * apw looks important on his chair
[17:01]  * cking is here
[17:02] <apw> we seem to be pretty light on people generally, so probabally this will be a short one
[17:02] <apw> [TOPIC] Security & bugfix kernels
[17:02] <MootBot> New Topic:  Security & bugfix kernels
[17:02] <smb_tp> Yeah
[17:02] <apw> how is Intrepid?
[17:02] <smb_tp> Also not much new. I am klicking Hardy and Intrepid proposed through
[17:03] <apw> kicking?  as in kicking the tyres of ?
[17:03] <smb_tp> klicking a mixture between kicking and ... licking...
[17:03] <apw> nnngggg
[17:03] <apw> not a pleasant picture
[17:03] <apw> when are we likely to promote our -proposed candiated?
[17:04] <smb_tp> The Intrepid proposed is in the accept queue. I have to get it further
[17:04] <apw> anything else security related?
[17:05] <apw> rtg reported earlier that the LPIA Jaunty tree was now merged into our main tree
[17:05] <smb_tp> It will take some time. The buildds are just finishing off some packages for hardy. After thatI have to push linux-meta and after that maybe two to three weeks there
[17:05] <apw> and that the old trees are now archived
[17:05] <smb_tp> Nothing security related for now but this is comming soon
[17:06] <jro> Hi, I am worried about the old version of aufs under kernel/ubuntu/ dir. It may contain problems.
[17:06] <apw> jro can we hold that thought for a bit
[17:06] <jro> sure
[17:06] <apw> which release are you talking there?
[17:07] <apw> jro, ?
[17:07] <jro> jaunty
[17:07] <apw> anything else for older kernels?
[17:07] <smb_tp> Nothing. next week hopefully more
[17:07] <apw> [TOPIC] Jaunty Status
[17:07] <MootBot> New Topic:  Jaunty Status
[17:08] <jro> i guess all of them contain old aufs version
[17:08] <apw> ok ... jaunty is now feature frozen, so our tree is now in SRU mode
[17:08] <apw> remember you need more acks to get things in from here on in
[17:08] <cking> how many is "more"?
[17:09] <cking> 2, 3?
[17:09] <apw> i beleieve you need two acks other than yourself for SRU level stuff
[17:09] <amitk> two devs
[17:09] <smb_tp> more than 0?
[17:09] <apw> but we should confirm that with rtg and get him to mail that out
[17:09] <cking> good idea
[17:10] <apw> [ACTION] apw to confirm the ack requirements for jaunty
[17:10] <MootBot> ACTION received:  apw to confirm the ack requirements for jaunty
[17:10] <smb_tp> Generally in maintenance at least one other beside yourself.
[17:10] <apw> we also have Jaunty ALPHA-5 due the 26th (thursday)
[17:10] <apw> anything pending for that, that is not going to make it?
[17:11] <amitk> I have config changes for ixp4xx
[17:11] <apw> is that the changes to get the kernel smaller?  how scarey are they?
[17:11] <amitk> is there going to be another upload? rtg mentioned one yesterday.
[17:12] <amitk> yes, and scarey is relative since currently the device OOMs without the changes
[17:12] <apw> amitk, i would think if there was going to be an uplaod it would be today, i did
[17:12] <amitk> did what?
[17:13] <apw> think that the kernel was basically there, we would need to take action
[17:13] <apw> to get another one if its needed
[17:13] <apw> (typing indicators would be handy in this meeting)
[17:13] <amitk> ok
[17:13] <apw> amitk, can they wait till after the alpha or do we need to jump up and down
[17:14] <apw> smb_tp, presumably you could push the requisite buttons if we need to
[17:14] <amitk> mobile team really wants it for A5
[17:14] <apw> so we need to approach the release team and find out if its even possible at this stage
[17:14] <smb_tp> apw, I probably should be able
[17:14] <apw> [ACTION] amitk to find out if we can slip in another kernel with arm changes
[17:14] <MootBot> ACTION received:  amitk to find out if we can slip in another kernel with arm changes
[17:15] <amitk> ack
[17:15] <apw> the deadline is almost cirtainly basically now
[17:15] <apw> ok jro, aufs?  whats up with that?
[17:15] <amitk> yes, this final kernel test should tell us if it all works now
[17:15] <apw> amitk, cool
[17:16] <jro> old aufs version is known to have some problems
[17:16] <jro> can ubuntu kernel be ok with them?
[17:16] <apw> what are the nature of those problems.  it is unlikely we can get a new version into alpha-5
[17:17] <apw> but after that we could consider it.  we would need a patch against jaunty (i guess) and some
[17:17] <apw> information on what is broken, so we can make an informed decision
[17:17] <amitk> jro: is there a patch available against the version in ubuntu?
[17:17] <apw> jro would you be able to summarise the issues in an email to the kernel-team list perhaps?
[17:17] <jro> i will try developing a patch and send another mail, ok?
[17:17] <apw> and link us to any patches you think are applicable there
[17:18] <apw> jro sounds excellent
[17:18] <amitk> jro: thanks
[17:18] <apw> [ACTION] jro to summarise aufs issues and possible patches
[17:18] <MootBot> ACTION received:  jro to summarise aufs issues and possible patches
[17:18] <jro> ack
[17:18] <apw> anything else Jaunty?
[17:18] <apw> TOPIC] Suspend/Resume
[17:19] <apw> [TOPIC] Suspend/Resume
[17:19] <MootBot> New Topic:  Suspend/Resume
[17:19] <apw> ok we have done some new work on the suspend resume scirpting for server use
[17:19] <apw> ogasawara, i assume we will be pushing out a request for testing with Alpha-5
[17:20] <ogasawara> apw: yup, was just thinking that
[17:20] <apw> ogasawara, will get with you on/before thursday as there may be some instruction changes
[17:20] <ogasawara> apw: ok, sounds good
[17:20] <apw> perhaps to get people to try on servers for instance, kirkland may have some input there
[17:21] <ogasawara> apw: we should definitely make a note of it so people are at least aware
[17:21] <apw> on the incoming bugs side, we are seeing about 7 bugs a day reported by apport nwo
[17:21] <apw> seems pretty steady at the moment.  still no real feel for any patterns in them
[17:21]  * kirkland reads some scrollback
[17:21] <apw> ogasawara, ack
[17:21] <cking> apw: any bugs related to the extended suspend/resume bugs?
[17:21] <cking> s/bugs?/tests?/
[17:21] <IntuitiveNipple> Bug #331415 could bite us; I'm trying to analyse which devices/drivers are affected
[17:21] <kirkland> apw: cool, okay, yeah, so i have a blog entry drafted, with instructions and a call for testing
[17:21] <apw> [ACTION] apw ogasawara to revisit suspend/resume testing instructions
[17:21] <kirkland> apw: i'll publish that today
[17:21] <MootBot> ACTION received:  apw ogasawara to revisit suspend/resume testing instructions
[17:22] <apw> kirkland, ok cool
[17:22] <kirkland> apw:  it was embargoed on review of my manager ;-)
[17:22] <kirkland> apw: dendrobates approved it earlier this morning for publication
[17:22] <apw> cking, only seen one from extended testing and that was a first pass failure
[17:22] <ogasawara> IntuitiveNipple: I can help you scan through bug reports
[17:22] <apw> ok ... cool
[17:23] <apw> IntuitiveNipple, that souds like it needs investigating for sure
[17:23] <apw> let us know if you need any help on the kernel channels
[17:24] <IntuitiveNipple> ogasawara: Thanks. If it turns out to be responsible for resume delays/apparent failures, it looks like it could be a hard one to patch.
[17:24] <apw> yeah a tricky one if we are still in the fridge
[17:24] <apw> anything else suspend/resume?
[17:24] <IntuitiveNipple> I think the main thing is, when reviewing bugs for suspend/resume have it in mind, because it isn't obvious when someone reports "failed to resume" because they rebooted before the 60 second time-out.
[17:25] <apw> IntuitiveNipple, fair point
[17:25] <apw> [TOPIC] Vanilla Kernel Builds
[17:25] <MootBot> New Topic:  Vanilla Kernel Builds
[17:25] <apw> ok ... on the mainline builds these are now progressing nearly automatically
[17:26] <amitk> apw: any statistics on the uptake?
[17:26] <apw> hopefully by next week cron will be taking the strain and we will be off the hook
[17:26] <apw> nothing numerical.  i habe been thanked for them by a number of people who are
[17:26] <apw> using them for all sorts of unexpected things
[17:26] <IntuitiveNipple> They're coming out faster than I have chance to test them:)
[17:26] <apw> so i think generally they are a good thing.  now that they only take space and no people time
[17:26] <apw> still not had any time to try and PPA them, not a priority at this time
[17:27] <amitk> apw: I think we should mention this in some debian channels too
[17:27] <apw> yeah thats a good point.  i wonder if they would install on any debian based system.  presumably yes
[17:27] <ogasawara> apw: if and when they're ready for wider consumption, the community has offered to help advertise
[17:27] <ogasawara> s/community/community team/
[17:27] <apw> ogasawara, i think we are at the point where they are as good as they are going to get
[17:28] <apw> so we should be considering an annoucnement.  are you in the frame for that :)
[17:28] <ogasawara> apw: ok cool.  I'll write up a wiki too then.
[17:28] <apw> there are some wiki pages on it already
[17:28] <apw> https://wiki.ubuntu.com/KernelMainlineBuilds
[17:28] <apw> is a good starting point on consumption of the builds
[17:28] <ogasawara> apw: even better then.  I'll whip up an announcement.
[17:29] <apw> [ACTION] ogasawara to prepare annoucement for mainline builds
[17:29] <MootBot> ACTION received:  ogasawara to prepare annoucement for mainline builds
[17:29] <apw> ...
[17:29] <apw> any other projects anyone needs to report on?
[17:29] <apw> [TOPIC] ARM Tree
[17:29] <MootBot> New Topic:  ARM Tree
[17:30] <apw> amitk, anything other than the arm config changes you want in?
[17:30] <amitk> not for A5
[17:31] <apw> cool
[17:31] <apw> [TOPIC] LPIA Tree
[17:31] <MootBot> New Topic:  LPIA Tree
[17:31] <apw> the only thing i know of here is that the Jaunty tree is now officially merged
[17:31] <apw> sconklin, anything from you?
[17:32] <sconklin> not at the moment
[17:32] <apw> cool
[17:32] <sconklin> I'm looking at LPIA again
[17:32] <apw> [TOPIC] Incoming Bugs
[17:32] <MootBot> New Topic:  Incoming Bugs
[17:32] <apw> ogasawara, any horrors for us to run away from?
[17:33] <ogasawara> apw: nothing critical.  IntuitiveNipple already mentioned bug 331415
[17:33] <ogasawara> there's another regression, bug 327431
[17:34] <apw> smb_tp, ^
[17:34] <IntuitiveNipple> I was about to mention that one, as well
[17:34] <ogasawara> I'm just finishing up adding a regressions section to the bug list
[17:34] <smb_tp> apw, Not looked at this I think
[17:34] <apw> they both on our critical list
[17:35] <apw> ogasawara, thanks, we will find someone to look at those two then
[17:35] <smb_tp> apw, We might need to walk over the critical list and see whether we need to spit up between the two of us
[17:35] <apw> smb_tp, yeah lets get together after and review things, as reviewing the new ones is working well but the old ones are "in the past"
[17:36] <apw> [ACTION] smb_tp apw to review the critical bugs
[17:36] <MootBot> ACTION received:  smb_tp apw to review the critical bugs
[17:36] <ogasawara> smb_tp, apw:  some might be a bit stale (ie not tested with jaunty yet) so I'll sweep through and triage
[17:36] <IntuitiveNipple> I am in the process of setting up a test-bench here to review the WPA Enterprise issues. There have been several around the same basic scenario.
[17:36] <apw> IntuitiveNipple, sounds good.  keep us informed :)
[17:36] <apw> ogasawara, sounds like a plan, thanks
[17:37] <apw> [TOPIC] Open discussion
[17:37] <MootBot> New Topic:  Open discussion
[17:37] <apw> anything else?
[17:37] <IntuitiveNipple> I have a couple of things to mention, when everyone else is done :)
[17:37] <apw> it sounds pretty quiet out there, so go ahead
[17:38] <apw> IntuitiveNipple, ?
[17:38] <IntuitiveNipple> OK. quick backgrounder. I've been messing with kernel/ACPI for a while. Emailed Pete last week saying I'd like to get more involved in kernel-team proper. He thought I was after a job. Not. However, I want to spend full-time working on kernel. So, if there are issues that need looking at, let me know.
[17:39] <IntuitiveNipple> Second: ...
[17:40] <IntuitiveNipple> ... I've been working on a new PCI IOMEM allocation scheme for mainline, which will go to Jesse Barne's PCI tree soonish. After Jaunty is out, I'd welcome some local review before it goes to linux-pci
[17:40] <IntuitiveNipple> It'll make Linux's IOMEM allocation on a par with Windows
[17:40] <apw> IntuitiveNipple, always good to have people helping us out ... #ubuntu-kernel is our home, hastle us
[17:40] <apw> IntuitiveNipple, sounds interesting, cirtainly i would be happy to review
[17:41] <amitk> and kernel-team list is available for patch review discussions
[17:41] <IntuitiveNipple> I'm always there - and when I'm on IRC I am available. I don't leave the client logged in.
[17:41] <IntuitiveNipple> amitk: Yes, thanks. I don't want to drop anything until Jaunty is done and dusted
[17:41] <apw> we are never done and dusted, just on another release
[17:42] <IntuitiveNipple> relatively speaking
[17:42] <apw> ok ... anyone else got anything?
[17:42] <apw> else thats a wrap
[17:42] <apw> thanks to IntuitiveNipple and jro for your input ... come again!
[17:43] <apw> #endmeeting
[17:43] <MootBot> Meeting finished at 11:43.
[19:44] <Veselushko>  :D