=== nhandler_ is now known as nhandler
=== boffire is now known as ButterflyOfFire
TheMusoamachu: Hey there.09:02
amachuelky: Hi09:07
=== mvo__ is now known as mvo
elkyamachu, hi09:07
amachupersia: elky: TheMuso: Hi09:07
TheMusoHey elky.09:07
amachulong since we met09:07
elkyw00t. quorum09:07
amachupersia: are you there?09:07
amachuwe need persia09:08
amachulifeless: Hi09:08
elkyi mistook you addressing him as him being here, sorry09:08
amachueither lifeless or persia09:08
lifelessI forgot about the precise time; I need to go eat or I won't get dinner at all :(09:09
amachulifeless: lets check candidates' presence09:10
amachuMaWaLe: Hi09:10
MaWaLehi all09:10
amachuMaWaLe: alone appear to be here09:11
MaWaLei think so09:11
amachulifeless: Will you be available or going out for dinner09:11
amachuelky: ok09:11
amachuelky: TheMuso: lifeless: Shall we start09:12
amachuhow about lifeless?09:12
elkyamachu, i suspect he's off getting food09:12
lifelessamachu: 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 tops09:13
lifelessor things are shut == no food09:13
lifelesssorry :(09:14
amachuthen persia?09:14
lifelesstotally my fault09:14
* lifeless waves bye09:14
amachuor can you be back by 30 min09:14
amachuI am Ok with it09:14
amachuhow about elky and TheMuso09:14
TheMusoI'm here.09:14
lifelessI will be back in nearly an hour09:14
* lifeless is really gone09:14
elkyamachu, we still lack quorum until we have a fourth09:14
amachuan hour is too long09:14
amachuelky: Yes09:15
elkywe dont have a choice.09:15
amachui am looking for persia to wake up :-(09:15
amachuMaWaLe: Tought times for you!09:15
TheMusoIdle for over 4 days09:15
TheMusoHe keeps odd hours as well, and is not always on IRC at regular times.09:15
amachuTheMuso: elky: I suppose better luck next week..09:21
TheMusoYeah, lets hope so.09:21
elkyamachu, yep, see you then09:21
amachuelky: wait, you have any nominations for the board09:22
amachuTheMuso: you?09:22
amachuI do not have as of now09:22
elkyajmitch, none that i've spoken to, unfortunately09:22
TheMusoamachu: no09:22
elkyer, amachu09:22
elkyalthough, ajmitch would be a perfect victim :P09:22
elkyhe qualifies by being in the right part of the globe anyway09:23
amachuelky: wiki of ajmitch?09:23
elkyamachu, dunno. maybe we should ask him privately first09:23
amachumay be you can narrate about your nomination to the mailing list09:23
amachuso that we all can look at it09:24
elkyamachu, how about we ask him first.09:24
amachuwhen others aren't aware, how can we?09:24
amachumay be he is here now09:25
amachuWe can do so ;-)09:25
elkyamachu, 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:25
ajmitchelky: whosit what?09:26
elkyajmitch, see PM09:28
amachuelky: ok09:28
amachuelky: you can elaborate to everyone on the list09:29
amachuwe will wind up then for this week..09:29
* elky headdesks09:29
amachuIf there isn't any clash, we will likely have our next meeting on March 3 at 1500 UTC09:30
amachuelky: TheMuso: bye bye09:30
elkyamachu, cya09:30
TheMusobye, and damn, I won't be at that one, too late for me.09:31
elkyyeah, that's too late for all the aussies09:33
=== mvo__ is now known as mvo
=== boffire is now known as ButterfltOfFire
=== ButterfltOfFire is now known as ButterflyOfFire
=== JanC_ is now known as JanC
=== thunderstruck is now known as gnomefreak
=== thunderstruck is now known as gnomefreak
dholbachhey robbiew14:59
robbiewhowdy :)14:59
Keybukmdz, cjwatson: ping?15:00
cjwatsonare we expecting sabdfl?15:01
Keybukhe's a little like the Spanish Inquisition15:01
cjwatsonrobbiew: please tell me you've seen monty python15:02
mdzKeybuk: hi15:02
mdzI passed sabdfl in a meeting room on the way here, he didn't look finished15:02
robbiewcjwatson: yes..I have15:02
mdzclan says he's coming though15:02
mdzcjwatson,Keybuk: randa is helping to manage the agenda, it should be up to date on the wiki now15:03
mdzwhat I would like is to have the agenda always reflect everything which is outstanding for the TB15:03
mdzand at each meeting we will checkpoint status on everything and close out items which are complete15:03
mdzdoes that sound reasonable to you?15:03
Keybukit dods15:03
Keybukdoes too15:03
MootBotMeeting started at 09:04. The chair is mdz.15:04
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]15:04
mdz[LINK] https://wiki.ubuntu.com/TechnicalBoardAgenda15:04
MootBotLINK received:  https://wiki.ubuntu.com/TechnicalBoardAgenda15:04
cjwatsonis the mailing list question an old one? I hadn't encountered it before15:05
mdzagenda is now up to date15:05
cjwatsonalthough I remember that we discussed the same question on the Community Council some time back15:05
mdzcjwatson: it's a new one15:05
KeybukI 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
cjwatsonthat was the same kind of reason that we determined community-council@ should be private, yes15:06
mdzKeybuk: was that it?  I couldn't remember and it's come up again, so I added it to the agenda15:06
Keybukmdz: I certainly remember that discussion in Oxford15:06
mdzit may have been long enough to revisit it :-)15:07
cjwatsonwhat are the arguments for making it public?15:07
cjwatsonjust that we should have arguments for keeping it private? :-)15:07
Keybukand where is the proposal to make it public?15:07
mdzright here :-)15:08
dholbachIn 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
MootBotNew Topic:  Should technical-board@lists.ubuntu.com be public?15:08
mdznot calling for a vote, I'm looking for input15:09
cjwatsonI would at minimum be concerned of the need to review existing content before blatting it into public view, since people were expecting privacy15:09
Keybukwe should iterate the reasons for making it public15:09
Keybukand the reasons for keeping it private15:09
mdzmotu-council@ serves many similar purposes and is public15:09
cjwatsonI'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 moment15:09
sabdfli bet they have conversations off-list15:09
mdzcjwatson: I can send you the archives if it would help15:09
Keybukon the private side is the desire that developer application discussions not be archived by google forever15:09
cjwatsonI 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
mdztechnical-board@ serves two purposes15:10
mdz1. a contact address to reach the TB (and only the TB)15:10
cjwatsonI actually have a specific concern about motu-council@ based on recent conversations I've had elsewhere15:10
mdz2. a mailing list to discuss TB matters15:10
mdzfor 1., private is appropriate, but for 2., it is not really15:10
cjwatsonI'm concerned that there is *not enough* negative discussion of applications, because people are concerned about "being mean"15:10
cjwatsonand I don't think that's appropriate for a neutral applications committeee15:10
mdzone reason this has come up (this time) is that there are various people who are helping out the TB15:11
sabdflthen cc them15:11
mdzwe can't control who is CCed when people mail technical-board@15:11
mdzand for my part, I can't always keep up with the mail to forward things15:11
Keybukare you thinking specifically of randa here15:11
mdzthere's also the general principle of transparency15:11
mdzKeybuk: also jono15:11
mdzand dholbach15:11
Keybukmy concern is that I think that people should expect privacy when they mail TB15:12
cjwatsonI would be happy with specific extra people being subscribed to technical-board@, personally15:12
sabdfli 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 lists15:12
mdz[LINK] http://www.ubuntu.com/community/processes/techboard15:12
MootBotLINK received:  http://www.ubuntu.com/community/processes/techboard15:12
sabdflthere needs to be a quick, easy and memorable way to talk privately to or among the TB15:12
Keybukwhile 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 zero15:13
sabdfli don't know if LP supports private mailing lists15:13
mdzThe Technical Board is responsible for the following documents and processes: 1. The Ubuntu Package Policy, 2. Ubuntu Release Feature Goals, 3. Ubuntu Package Selection15:13
mdznone of that stuff should be private15:13
cjwatsonthe CC certainly gets private discussion of major social blow-ups, or used to, which isn't the case for us15:13
mdzthe page doesn't talk about developer applications, though I agree with the arguments to keep those more confidential15:13
cjwatsonthere is a separate website bug about the out-of-date-ness of that web page :-)15:13
mdzcjwatson: ye15:14
mdzan old one15:14
dholbachin case you're not aware of it: everything related to developer applications (in the case of the MC) is public15:14
mdz[LINK] http://launchpad.net/bugs/24872915:14
MootBotLINK received:  http://launchpad.net/bugs/24872915:14
ubottuUbuntu bug 248729 in ubuntu-website "/processes/techboard out of date" [Undecided,Confirmed]15:14
cjwatsondholbach: have you considered whether this is in fact desirable?15:14
dholbachcjwatson: we did not get any complaints or concerns about it yet15:14
cjwatsonI heard a specific concern recently that somebody wanted to express negative feedback, and was told not to be mean15:15
Keybukdholbach: have you considered that you won't get complaints or concerns if the compaints and concerns are public too?15:15
mdzperhaps the question I've asked is too broad; for my purposes it would be sufficient if TB delegates could be subscribed to the list15:15
cjwatsonnow, I haven't gone and looked into the history, but this is something that concerns me deeply15:15
mdzcjwatson: could we handle the question about motu-council as a separate agenda item?15:15
dholbachthere's surely a middle ground of expressing concern or advising to "reapply again in a few weeks" without being mean15:15
cjwatsonalthough I think it's germane to this point15:15
mdzcjwatson: agreed, just trying to steer to a conclusion15:15
cjwatsondholbach: there is, but in some cases the response simply ought to be negative15:16
cjwatsonI realise that both of us tend towards the state of being nice to people where possible :-)15:16
mdzare there any objections to subscribing select people to the TB list who are participating but not actually on the TB?15:16
cjwatsonI have no objection to that15:16
KeybukI have no objections either15:16
mdzsabdfl: thoughts on that option?15:17
sabdflthat should be transparent, though :-)15:17
mdzseparately, I'd like to reaffirm that where possible, we should shift discussion of public matters from t-b@ onto ubuntu-devel@15:17
mdze.g. policy discussions15:18
sabdflmdz, i think we could include delegates in private issues explicitly by cc15:18
sabdflfor example, jono or dholbach or jorge15:18
sabdflor randa15:18
sabdflwhere appropriate15:18
cjwatsonon general principles we have usually said that anything in Ubuntu that can be public should be public, so that seems a reasonable statement to me15:18
sabdfli think the majority of TB discussions could be public, which lends support to the idea that tb@ be public15:18
cjwatsonby comparison we encourage discussion to move from #distro (irc.canonical.com) to #ubuntu-devel15:19
mdzI'm happy for it to stay private so long as we only use it for discussions which ought to be private, and nothing else15:19
mdze.g. if someone emails technical-board@ and raises a technical concern, we must redirect that to ubuntu-devel@15:19
sabdflfine by me15:19
mdzthis is easy to forget to do, etc., but if we agree we can try to make the best of it15:20
mdzok to move on?15:20
mdz[TOPIC] MOTU Council nominations (dholbach)15:20
MootBotNew Topic:  MOTU Council nominations (dholbach)15:20
mdzdholbach: I put your name on this but just noticed it was persia who emailed t-b@15:21
sabdfli propose we nominate dholbach, and two non-canonical candidates15:21
Keybukthis is a re-nomination of dholbach, right?15:21
mdzdholbach: can you represent MC here?15:21
dholbachmdz: technically... I'm not on the MC right now :)15:21
sabdfldholbach has expired15:22
dholbachsoren, nixternal, persia: here? :)15:22
sabdfl(from the MC ;-))15:22
dholbachI think it's a good idea to have more members on the MC15:22
Keybukwho are the proposed other nominees?15:22
mdzKeybuk: I don't think that's been publicly discussed, it's on t-b@ though15:24
mdzSubject: MOTU Council list of nominees for MOTU Council Election15:24
Keybukare we not discussing them now?15:25
KeybukI understood this agenda item to be "nominate people to the MOTU Council"15:25
mdzI just want to move the process forward; what's the next step?15:25
mdzis there an agreed process for how council nominations work?15:25
mdz(apart from TB and CC)?15:26
Keybukthere seems to be two obvious choices15:26
Keybukthe TB decides15:26
Keybukthe Developers decide15:26
Keybukthe latter seems more desirable to me15:26
mdzfor the TB, it is "Appointments to the board are made by Mark Shuttleworth subject to confirmation by a vote amongst the maintainers"15:26
dholbachthere's https://wiki.ubuntu.com/CommunityCouncil/Delegation and we made use of it in the past15:27
mdzdholbach: ah, that's useful, thanks15:27
mdzthe CC has done a lot more official delegation than we have15:27
sabdfli thought we were following https://wiki.ubuntu.com/CommunityCouncil/Delegation15: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
sabdfland were already at the point of having proposed nominees, from the MC15:27
sabdfli was suggesting that the TB put up three candidates for confirmation vote15:28
mdzso the questions are:15:28
mdz1. how many slots do we need to fill?15:28
mdz2. who are the nominees?15:28
Keybuksabdfl: three candidates for how many seats?15:28
sabdflthree for three, confirmation not a race15:28
sabdfldholbach asked that we have an odd number of seats15:28
mdzthere is only one seat opening up, but it's been suggested that the council should be expanded15:28
sabdflfor quorum / voting reasons15:29
mdzI'm OK with three seats. keybuk? cjwatson?15:29
mdzthat's replacing the one which expired, and adding two15:29
cjwatsonthat would result in an even number of seats15:29
cjwatsonoh, no it wouldn't15:30
sabdflMC has been well organised, growing it gives an opportunity to develop more leadership talent15:30
mdzsabdfl: I have some open questions about how the role of MC will change with ArchiveReorganisation15:30
sabdflme too15:30
cjwatsonso does CommunityCouncil/Delegation mean that this needs to be run past the CC too?15:30
mdzagreed, no15:31
mdzok, so we're agreed on 3 seats15:31
sabdflCC has already delegated this to TB, it's fine to redelegate15:31
sabdfl(wearing my CC hat)15:31
Keybukdid CC delegate this?15:31
KeybukI thought this was a TB duty that the TB decided to delegate all on its own ;)15:31
Keybukthe CC delegates membership assignment to the TB15:31
Keybukbut that's orthogonal15:32
dholbachI was under the impression that because of the power to grant ubuntumembers membership the MC would report to CC and TB?15:32
sabdflKeybuk: reference appointment process to the TB, i guess15:32
* Keybuk makes delegation pancakes15:32
sabdflnevertheless, i can say this is up to the TB15:32
sabdflwe can do it however the TB wants15:32
dholbachin any case there were no objections raised in the CC when the topic was brought up15:32
sabdflthis is entirely about how the ubuntu development team picks and organises itself15:33
mdzdholbach: right, so I think we're free to proceed15:33
dholbachI'd think so :)15:33
mdzso we have a list of suggestions from the MC itself, and need to decide on nominees15:33
mdzI'm happy with the suggestions sabdfl made on t-b@15:33
sabdflmy recommendation to exlcude one candidate is based purely on the fact that he now works for canonical15:33
sabdfland we want to broaden representation outside canonical15:33
mdzin <4993CCBA.5000202@ubuntu.com>15:34
sabdflthat may be unfair on the individual15:34
sabdfli'm loosely attached to the idea15:34
Keybukmdz: I agree, +1 on sabdfl's proposed list15:34
mdzcjwatson: ?15:34
sabdfldholbach of course works for canonical, but i feel he's been *fantastic* in this role15:34
dholbachsabdfl: thanks a lot for the flowers15:34
sabdfland so it's worthwhile to me to maintain the continuity, since dholbach nominated himself and says he enjoys it15:34
cjwatsonI don't have any problem with the specific three people proposed15:34
cjwatsonI don't know Nathan very well myself15:35
mdzI'm supportive of Canonical participating in the council, but agree we should aim to keep the ratio low15:35
sabdfla run-off would be a more interesting poll15:35
cjwatsonbut he seems to have been effective in the limited interactions I've had with him15:35
mdzwill the confirmation vote be among MOTU or all developers?15:35
mdzI suggest all developers15:35
sabdfli'm easy15:35
dholbachme too15:35
ScottKAll developers are MOTU.15:35
cjwatson... I just made the MOTU team include ubuntu-core-dev ;-)15:35
cjwatson(as discussed on ubuntu-devel@)15:36
sabdflwell that solves that15:36
mdzthat sounds like consensus on the three nominees15:37
mdzthey are: Daniel Holbach, Nathan Handler, and Jonathan Davies15:38
mdzsabdfl: will you set up the polls?15:38
mdz[ACTION] sabdfl to set up Launchpad polls for MC nominee confirmations15:38
MootBotACTION received:  sabdfl to set up Launchpad polls for MC nominee confirmations15:38
mdz[TOPIC] SRU guidelines for Landscape (robbiew)15:38
MootBotNew Topic:  SRU guidelines for Landscape (robbiew)15:38
cjwatsonso a poll of all developers will now include per-package uploaders (of whom the only current example is Stefan Bader)15:38
cjwatsonjust for the record15:38
mdzrobbiew: are you here?15:38
sabdflcjwatson: ~ubuntu-dev right?15:38
cjwatsonassuming you use ~ubuntu-dev15:38
robbiewmdz: yes15:38
robbiewI placed the link to the LandscapeSRU process in the agenda.15:39
mdzso the decision at hand is whether to confirm an exception to the SRU process based on that document15:39
robbiewFrom 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:39
mdzI 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
ScottKWe have a lot of packages in the archive for which that is true.15:40
cjwatsonwe've been back-and-forwarding on this in ~ubuntu-sru for months15:40
mdzrobbiew: right, that was the reason for asking15:40
cjwatsonand feel we have finally reached agreement, after a lot of extra commitments made by the Landscape team15:40
mdzwe asked that they provide an explanation of what processes they will follow in order to ensure their updates are free of  regressions15:40
mdzwhich is the purpose of the SRU process15:40
cjwatsonI think those commitments could serve as a template for other projects, at least in principle15:40
cjwatsonI absolutely do not want to make an exception for Landscape just because it's Landscape15:41
mdzcjwatson: agreed, though I also don't want to block it on generalizing the policy15:41
cjwatsonI want it to be generalisable, not necessarily generalised15:41
mdzI'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 next15:41
cjwatsonso the reasons why I think Landscape is suitable, given the negotiations to date, are:15:42
mdzif another project can meet the standard we set, then we should consider that as well15: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 combinations15:42
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 potential15:43
cjwatson * those interactions have been specifically called out in the mandatory QA process that each upgrade must go through15:43
sabdflwe must surely have a couple of other upstreams that meet any reasonable such standard15:43
sabdfli would like to go out with a document that references more than just landscape15:43
cjwatson * its developers have agreed to work within the Ubuntu update process15:43
mdzimpact on non-Landscape users is pretty tightly constrained, and I think Landscape should be able to take responsibility for the impact on their own users15:43
mdzsabdfl: I fear that will delay what has already been a very drawn out process15:44
ScottKLandscape client is included by default on Server installs.15:44
cjwatsonsabdfl: 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 general15:44
cjwatsonScottK: yes, this is true, and this is part of why it has taken so long to come to an agreement15:44
mdzthis was originally raised by the Landscape developers in https://bugs.edge.launchpad.net/ubuntu/+source/landscape-client/+bug/30636015:45
ubottuUbuntu bug 306360 in landscape-client "Update landscape-client package to 1.0.25" [Undecided,In progress]15:45
cjwatsonScottK: 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
mdzwhich was filed 2008-12-0815:45
cjwatsonthis has been discussed for a lot longer than that15:45
mdzcjwatson: true15:46
cjwatsonalthough, yes, I think that was probably the first public mention15:46
ScottKWhich is fine, just that the potential impacts involve essentially all server installs.15:46
ScottKeven if the risk is low15:46
sabdflcould we at least invite upstreams of other projects that want this to approach the TB?15:46
mdzScottK: 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 updates15:47
cjwatsonScottK: yes. It does concern me, but less than it might due to it being fairly self-contained15:47
mdzsabdfl: I suggest that we decide for Landscape initially, with a sufficiently detailed rationale that it can be generalized in the future15:47
cjwatsonwhich 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 work15:47
mdzrather than require a general policy in order to decide on Landscape15:48
mdzwe have made exceptions for several other packages already without a general policy15:48
cjwatsonsabdfl: I'm concerned about inviting upstreams in general15:48
cjwatsonsabdfl: every upstream, without exception to my knowledge, wants distributions to ship the newest available version15:48
mdz(kernel, app-install-data-commercial, tzdata, hal-info and mobile-broadband-provider-info, FYI)15:48
cjwatsonsabdfl: I think we only have bandwidth to do this for limited high-quality high-value cases)15:49
sabdfli 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 received15:49
sabdflwe are definitely *open* to doing this more generally, so we can say that15:49
sabdfland i agree with cjwatson on bandwidth15:49
cjwatsonyes, I think there's middle ground between "we're open to discussions" and "please come and bang down our door"15:49
cjwatsonso stepping back just a moment, if I have time15:50
mdzwe have 10 minutes15:50
cjwatsonkernel, hal-info, mobile-broadband-provider-info come under general category of hardware support (often due to new hardware being introduced)15:50
cjwatsonapp-install-data-commercial comes under the general category of enabling something outside the primary archive15:50
cjwatsontzdata comes under the general category of coping with external events that we can't ignore15:51
cjwatson(i.e. legislative environment)15:51
cjwatsonlandscape is approximately under the same category as app-install-data-commercial, to me15:51
cjwatsonand in general, all of these could be grouped as "updates necessary to deal with changes outside the Ubuntu archive"15:52
cjwatsonexternal events that we can't necessarily encapsulate in one nice stable release15:52
mdzit's similar to the various packages (mostly in universe) which are using web APIs or screen-scraping, and occasionally get broken by server-side changes15:52
cjwatsonMSN, ICQ come to mind too15:52
mdzcjwatson: right15:52
cjwatsonwhere 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 nature15:53
sabdflanything which talks to unversioned web api's is going to get this problem15:53
mdzto 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 policy15:53
mdzare there any other concerns with the proposal?15:53
mdzwe'll need to take this offline it looks like15:53
KeybukI don't have any particular concerns15:54
mdzbut I'd like to do so with a clear agenda so we can drive to a decision15:54
cjwatsonScottK raised a QA concern which is basically similar to what the SRU team raised when approached with this15:54
sabdfli'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
sabdflor thereabouts15:54
cjwatsonI'm happy to elaborate on that if requested, perhaps by mail15:54
mdzwe've entrusted the SRU team to assess the QA aspect and will review that ourselves as well based on the document15:54
cjwatsonbut the body responsible for stable QA has now signed off15:54
mdzbased on sabdfl's input, I think this requires more than a simple vote15:55
mdzwe'll need to write up a formal decision with rationale which can be referred back to as precedent15:55
mdzcjwatson: new guy, want to take the action for that? ;-)15:55
cjwatsonyeah, I can do that15:55
mdzthank you15:56
mdz[ACTION] cjwatson to write up decision which we can then vote on15:56
MootBotACTION received:  cjwatson to write up decision which we can then vote on15:56
cjwatson(or try, anyway)15:56
mdz[TOPIC] Upload permission for Romain Francoise for 'emacs-snapshot'15:56
MootBotNew Topic:  Upload permission for Romain Francoise for 'emacs-snapshot'15:56
mdzI don't have any news here, but this remains open15:56
mdzJono has been in touch with Romain15:56
sabdfldo we have anything in writing to support him against those criteria?15:57
dholbachsabdfl: I did not roll it into UbuntuDevelopers yet - do you think we can make the "process" section a bit more explicit?15:58
sabdfldholbach: sure15:58
mdzhe is @gnu.org and @debian.org15:59
Keybuksabdfl: my objection remains a simple one15:59
dholbachit'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 it15:59
KeybukRomain has only ever had one sponsored upload to Ubuntu15:59
mdzsabdfl: for my part, the simple (but unfortunate) answer is "I don't know"15:59
ttx^ Koon16:01
cjwatsonttx: sorry, TB meeting still underway16:01
mdzwe have to wrap up and clear the channel for the next meeting16:01
cjwatsonmdke's application was dealt with by mail16:01
mdzI'm behind on email, haven't even read it16:01
mdzbut if the three of you agree I'm fine16:02
cjwatsonMark and I +1ed, I actioned16:02
dholbachmdz, sabdfl: shall I send you a proposal for the clarification of the per-package-uploader process by mail?16:02
cjwatsonoh, which reminds me, better add mdke to ~ubuntu-dev then16:02
mdzcodecs in ffmpeg, jono is working on16:02
mdzarchive reorg governance I'm not sure of the status16:02
mdzis it blocked on the technical proposal?16:02
sabdflimplementation of16:02
cjwatsonstill on me to rework proposal following Berlin I think16:02
mdzsabdfl: I think we can decide the governance model before it's implemented, and should do so to avoid a chaotic transition16:03
mdzsounds like it's blocked on Colin16:03
mdzwe need to wrap, I'll update the agenda16:03
cjwatsonDaniel asked me for a call this week, will probably manage that a bit later16:03
sabdflsoyuz team is just laying the foundations, we can use them as we wish16:03
mdz[ACTION] cjwatson to rework archive reorg proposal to unblock governance work16:03
MootBotACTION received:  cjwatson to rework archive reorg proposal to unblock governance work16:03
MootBotMeeting finished at 10:03.16:03
mdzttx: all yours16:03
ttxmdz: sorry for interrupting :)16:04
mdzttx: no worries16:05
* sommer is sortof here :)16:05
ttxzul: "mine is bigger" ?16:05
zulttx: yes it is16:06
ttxmathiaz isn't available so I'll try to replace him16:06
* ttx <-- the hacker formerly known as koon16:06
MootBotMeeting started at 10:07. The chair is ttx.16:07
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]16:07
ttxToday's agenda: https://wiki.ubuntu.com/ServerTeam/Meeting16:07
ttxLast week minutes: https://wiki.ubuntu.com/MeetingLogs/Server/2009021716:07
ttx[TOPIC] Review ACTION points from previous meeting16:08
MootBotNew Topic:  Review ACTION points from previous meeting16:08
* ttx frantically reads up last meeting minutes16:08
ttxPostfix and Dovecot integration: ivoks to create a wiki page for ideas about improving the mail server task post-jaunty16:09
ttxivoks: ?16:09
ivokswell, i've set up a wiki16:09
ivokssmall, but a start16:09
ivokswhich is for karmic, so no much point in discussing now16:09
sorenivoks: cjwatson had concerns about the approach used in the dovecot/postfix integration. Were they adressed?16:10
ivokssoren: when? 2 weeks ago?16:10
sorenivoks: Think so, yes.16:10
ivokssoren: we've solved the whole thing according to his advice16:10
dendrobateswe can address them at UDS, if not.16:10
ivoksunless there are some new16:11
ivokswhich i'm unaware of :)16:11
ttxsounds good16:11
sorenivoks: No, nothing new.16:11
ttxPower management: kirkland to blog about using suspend/resume for servers.16:11
dendrobatesttx: he is not here, but is blocked on me.16:12
sorenI was just checking. I haven't had a time to review it myself.16:12
sorenivoks: ^16:12
dendrobatesI will give him approval as soon as I manage to talk to him.16:12
ttx[TOPIC] Roadmap review16:12
MootBotNew Topic:  Roadmap review16:12
ivokssoren: test it, should be fully functional and i don't think there'll be anything else for jaunty16:12
dendrobatesor if he reads these minutes, go ahead.16:13
ttxAnyone has a status report on part of the roadmap that would be assigned to himself ?16:13
sommerthe doc.u.c site is updated and ready for reviews :)16:14
ScottKvorian has been doing some good work on the libdb consolidation.16:14
ttxThe roadmap page looks a little... oudated16:15
vorianyes, slight snag with libdb4.4 though16:15
ttxoutdated, even.16:15
vorianldiskfsprogs seems to only want to build/work with libdb4.416:16
ttxok. Soren, want to do an update on the virtualization front ?16:17
sorenI could. :)16:17
sorenSo, since we last saw each other, Eucalyptus entered the archive.16:17
sorenThis gives us a free implementation of EC2 and S3 that you can deploy on your own infrastructure.16:18
sorenThis 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:18
sorenAlpha testers are very welcome.16:19
sommersoren: what's need to test?16:20
ttxsoren: is there any start page / instructions for first-time testers ?16:20
sorenttx: No, not yet. There's still some things that needs fixing before it's ready for mass testing.16:20
ivoksi might test that :)16:20
sorenOnce they're sorted out, I'll post a call for testing.16:20
ivokssoren: if i got you right, one can't offer S3 like service16:21
ivokssoren: but can use it inside it's own web project?16:22
sorenivoks: Yes, you can offer this to other people as well.16:22
ttxsoren: anything else ?16:24
sorenNo, I'm good.16:24
ttxok. 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:24
ScottKI'll just toss out that clamav 0.95 is imminent.16:25
ScottKI expect an RC this week or next.16:25
ScottKIt's known to break all the libclamav rdepends.16:25
sommerthe last thing for the serverguide is the cloud stuff, can you ping me when it's ready to test soren?16:25
ttxScottK: i suppose it was accepted as a FFe ?16:26
ScottKIf we can get the rdepends working, I'm sure it will be.16:27
ScottKWe'd really rather not release with an obsolete clamav.16:27
sorensommer: Yes, I will.16:27
ttxI agree with that.16:27
sommersoren: awesome, thanks :)16:27
ivoks+1 for clamav16:27
ttxok, then lets' move on to:16:28
ttx[TOPIC] Open Discussion16:28
MootBotNew Topic:  Open Discussion16:28
ivoksi have one thing...16:28
ivoksthere are some users that complaing on our effort on supporting LTS16:28
ttxivoks: as in: not SRUing enough ?16:29
* kirkland is here now16:29
ivoksif we could give more love to LTS somehow, that would be great16:29
ivoksttx: well, they do have a point with on thing16:29
ttxmost complains I've seen are for backports16:29
ScottKAs in wanting more?16:29
ivoksif we fix a bug in lts+ release, we don't backport that fix16:29
ivoksand we just mark bug as fixed16:30
ivokswhile, in LTS it's not16:30
ttxScottK: as in "please ship that new version, it's so good the LTS needs it"16:30
ScottKWell we do have backports for this.16:30
ivoksno, i'm against new versions16:30
ttxScottK: that's my usual answer, but they usually don't like it.16:30
ivoksi'm for fixing bug in current and lts release, not just declaring it fixed since it is fixed in, for example, intrepid or jaunty16:31
zulyes well if thats the case then the backports need more testing that backports dont break things16:31
ScottKWhich is why backports is great.  You don't have to have them.16:31
ScottKzul: backports very rarely break things.16:31
dendrobatesand we don't have to include them in the point releases.16:31
ivoks(fwiw, i didn't talk about backports)16:32
ttxivoks: so your point is that we lose sight of valid SRU bugs because their development-release task is Fix Released ?16:32
ivoksttx: correct16:32
ScottKIf 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:32
ivoksi'm just saying, maybe we should pay more attention on these things16:33
ttxWe could have a review of fixed bugs and decide if they make likely/badly-wanted/not wanted candidates for the SRU process16:34
sommerivoks: is there a list of such bugs?  I can probably help with them16:34
ivoksor ask users what they think about LTS releases?16:34
sommererr help test anyway16:34
ScottKivoks: Users generally don't find it OK to leave any bugs unfixed.16:34
ivokssommer: i don't have a list, these were complaints on #ubuntu-server 2 days ago16:34
ivokssommer: from couple of users16:35
=== dholbach_ is now known as dholbach
sommerivoks: okay, I may have missed them, I'll try and find them16:35
ttxI agree we tend to lose sight of the fixed-in-development-release bugs. And the nomination process doesn't really help.16:35
ivokssommer: check sunday16:35
ttxany suggestion on a process we could use to better track that ?16:37
sommercould we add tags like hardy-needed, intrepid-needed, etc then remove them when the fix is committed?16:38
ttxlike systematically nominating for relevant releases, and have a session where we look at them and accept/deny them ?16:38
sommernot sure if that fits, but just a suggestion16:38
ttxsommer: theorically that's what nominations are for16:38
sommerttx: yep, that's better than :)16:39
ivoksright, nominations should be fine for that16:39
ivoksif bug is reported in LTS, then fix it in LTS and development-release16:39
ivoksnot just development-release16:39
ivoksi'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:40
sorenttx: Yes. Hang on.16:41
ttxwe can't really nominate all relevant bugs and then jave a session of acceptance/denial16:42
sorenhttps://bugs.edge.launchpad.net/ubuntu/hardy/+nominations I think.16:42
ttxsince for people with superpowers, nominating also does accept the nomination.16:42
sorens/edge// if you're not cool enough for that.16:42
dendrobatesI can approve nonimations.16:43
sorenIt seems I can, too.16:43
ivoksi can too :)16:43
dendrobatessoren: really?16:44
ivokswow, i have superpowers!16:44
ttxdendrobates: 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
dendrobatesI thought it was restircted to drivers.16:44
sorendendrobates: 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
ttxif the core-dev nominates, it will be automatically accepted, no ?16:44
sorendendrobates: ubuntu-core-dev is listed as driver as well.16:45
sorendendrobates: https://edge.launchpad.net/ubuntu/hardy16:45
dendrobatesahh, I think that is new.16:45
ttxso you can't really say "affects hardy" and let the bug-reviewing department decide on SRU potential16:45
sorenI do, too.16:45
ttxivoks: that's a good point, I propose you add it as a proper agenda item for next week session.16:46
ttxand we can brainstorm during the week.16:46
sorenivoks: I'm curious why you can, though. You're not core-dev, are you?16:46
ivokssoren: i'm not16:46
ttxWe could have some QA people joining us16:46
sorenivoks: *shrug*16:47
ivoksttx: imho, we should reach to our users and ask them what they want; push brainstorm.u.c a bit more16:47
ivoksthat's the easiest and best way to world domination :)16:47
dendrobatesivoks: but only if we are going to take the suggestions seriously.16:47
ivoksdendrobates: right16:48
ttxACTION: ivoks to add to next week agenda an item about better SRU bugtracking16:48
ttx[ACTION] ivoks to add to next week agenda an item about better SRU bugtracking16:48
MootBotACTION received:  ivoks to add to next week agenda an item about better SRU bugtracking16:48
ttxbah bot16:49
ScottKI'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
ubottuLaunchpad bug 268447 in landscape-client "MOTD should not point to https://landscape.canonical.com if you are not a customer" [Undecided,Confirmed] https://launchpad.net/bugs/26844716:49
ScottKI'm not arguing what's there isn't allowable, just I don't think it's a good idea for Ubuntu.16:49
ttxivoks: if you'er MOTU you can apparently accept nominations for universe packages.16:50
ivoksttx: right16:50
ivoksScottK: 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
ttxScottK: if it's not a bug, then that should be raised in more "discussion" channels, I guess16:51
* ScottK didn't file it as a bug.16:51
ttxScottK: I did ;)16:52
ScottKThis would be doing that (raising it in discussion channels).16:52
nealmcbI agree with ScottK.16:52
ScottKJust consider if we want every package that writes to stdout to include links to proprietary add-ons?16:53
ScottKI'm pretty sure we don't, but as long as that's there, it's very hard to argue against it.16:53
ivokslike firefox on BBC?16:53
=== zaafouri is now known as zaafouri`
ivoksyou have a link to launchpad inside every app on desktop16:53
* ScottK gets his BBC news via email, so dunno.16:53
ScottKBut Launchpad is used by Ubuntu for stuff.16:54
ScottKLandscape is a seprate product.16:54
ScottKAt least for me the only Launchpad stuff I find in apps is about filing bugs.16:55
dendrobatesThis is outside of our realm of control.  But your opinion will be noted and report up.16:55
nealmcbWhat 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 up16:55
dendrobatesWe did our best to make it as innocous as possible, but I understand your concern.16:55
ScottKdendrobates: If it's in an Ubuntu Server package, I disagree.16:56
ScottKIt is exactly in our realm of control.16:56
ivokswould 'Find out how to manager your server on http://www.ubuntu.com/manager' be better?16:56
ivoksand from there, offer canonical and 'community' solutions?16:56
ScottKYes, I think it would if it offered both.16:56
ivoksbut, we don't have community way of doing this :(16:57
nealmcband launchpad doesn't cost money and will be open source within 6 months16:57
dendrobatesivoks: I agree, I will try and push that. We should discuss it briefly at UDS.16:57
ivokss/manager/manage/ lol16:57
ivoksdendrobates: web site could provde more information about landscape, so should be even better for canonical16:58
ttxok, let's wrap up16:58
ScottKIf 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
ScottKdendrobates: I'd like to see this resovled before release, so UDS is a bit late.16:58
* ScottK stops16:58
=== fader_ is now known as fader
nealmcbivoks: good idea - it could combine my "help" idea and the more active management that motd readers might want16:59
ttxit's a complex subject for an open discussion item, I guess16:59
ttx[TOPIC] Agree on next meeting date and time16:59
MootBotNew Topic:  Agree on next meeting date and time16:59
ttxnext week, same time, same place ?16:59
ttxhopefully mathiaz won't lose network connection 5 minutes before the meeting starts.16:59
ttxand the meeting will look better prepared :)17:00
ivoksescuses :)17:00
MootBotMeeting finished at 11:00.17:00
MootBotMeeting started at 11:01. The chair is apw.17:01
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]17:01
apwThis is the weekly kernel team meeting17:01
* smb_tp waves17:01
* apw looks important on his chair17:01
* cking is here17:01
apwwe seem to be pretty light on people generally, so probabally this will be a short one17:02
apw[TOPIC] Security & bugfix kernels17:02
MootBotNew Topic:  Security & bugfix kernels17:02
apwhow is Intrepid?17:02
smb_tpAlso not much new. I am klicking Hardy and Intrepid proposed through17:02
apwkicking?  as in kicking the tyres of ?17:03
smb_tpklicking a mixture between kicking and ... licking...17:03
apwnot a pleasant picture17:03
apwwhen are we likely to promote our -proposed candiated?17:03
smb_tpThe Intrepid proposed is in the accept queue. I have to get it further17:04
=== beuno_ is now known as beuno
apwanything else security related?17:04
apwrtg reported earlier that the LPIA Jaunty tree was now merged into our main tree17:05
smb_tpIt 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 there17:05
apwand that the old trees are now archived17:05
smb_tpNothing security related for now but this is comming soon17:05
jroHi, I am worried about the old version of aufs under kernel/ubuntu/ dir. It may contain problems.17:06
apwjro can we hold that thought for a bit17:06
apwwhich release are you talking there?17:06
apwjro, ?17:07
apwanything else for older kernels?17:07
smb_tpNothing. next week hopefully more17:07
apw[TOPIC] Jaunty Status17:07
MootBotNew Topic:  Jaunty Status17:07
jroi guess all of them contain old aufs version17:08
apwok ... jaunty is now feature frozen, so our tree is now in SRU mode17:08
apwremember you need more acks to get things in from here on in17:08
ckinghow many is "more"?17:08
cking2, 3?17:09
apwi beleieve you need two acks other than yourself for SRU level stuff17:09
amitktwo devs17:09
smb_tpmore than 0?17:09
apwbut we should confirm that with rtg and get him to mail that out17:09
ckinggood idea17:09
apw[ACTION] apw to confirm the ack requirements for jaunty17:10
MootBotACTION received:  apw to confirm the ack requirements for jaunty17:10
smb_tpGenerally in maintenance at least one other beside yourself.17:10
apwwe also have Jaunty ALPHA-5 due the 26th (thursday)17:10
apwanything pending for that, that is not going to make it?17:10
amitkI have config changes for ixp4xx17:11
apwis that the changes to get the kernel smaller?  how scarey are they?17:11
amitkis there going to be another upload? rtg mentioned one yesterday.17:11
amitkyes, and scarey is relative since currently the device OOMs without the changes17:12
apwamitk, i would think if there was going to be an uplaod it would be today, i did17:12
amitkdid what?17:12
apwthink that the kernel was basically there, we would need to take action17:13
apwto get another one if its needed17:13
apw(typing indicators would be handy in this meeting)17:13
apwamitk, can they wait till after the alpha or do we need to jump up and down17:13
apwsmb_tp, presumably you could push the requisite buttons if we need to17:14
amitkmobile team really wants it for A517:14
apwso we need to approach the release team and find out if its even possible at this stage17:14
smb_tpapw, I probably should be able17:14
apw[ACTION] amitk to find out if we can slip in another kernel with arm changes17:14
MootBotACTION received:  amitk to find out if we can slip in another kernel with arm changes17:14
apwthe deadline is almost cirtainly basically now17:15
apwok jro, aufs?  whats up with that?17:15
amitkyes, this final kernel test should tell us if it all works now17:15
apwamitk, cool17:15
jroold aufs version is known to have some problems17:16
jrocan ubuntu kernel be ok with them?17:16
apwwhat are the nature of those problems.  it is unlikely we can get a new version into alpha-517:16
apwbut after that we could consider it.  we would need a patch against jaunty (i guess) and some17:17
apwinformation on what is broken, so we can make an informed decision17:17
amitkjro: is there a patch available against the version in ubuntu?17:17
apwjro would you be able to summarise the issues in an email to the kernel-team list perhaps?17:17
jroi will try developing a patch and send another mail, ok?17:17
apwand link us to any patches you think are applicable there17:17
apwjro sounds excellent17:18
amitkjro: thanks17:18
apw[ACTION] jro to summarise aufs issues and possible patches17:18
MootBotACTION received:  jro to summarise aufs issues and possible patches17:18
apwanything else Jaunty?17:18
apwTOPIC] Suspend/Resume17:18
apw[TOPIC] Suspend/Resume17:19
MootBotNew Topic:  Suspend/Resume17:19
apwok we have done some new work on the suspend resume scirpting for server use17:19
apwogasawara, i assume we will be pushing out a request for testing with Alpha-517:19
ogasawaraapw: yup, was just thinking that17:20
apwogasawara, will get with you on/before thursday as there may be some instruction changes17:20
ogasawaraapw: ok, sounds good17:20
apwperhaps to get people to try on servers for instance, kirkland may have some input there17:20
ogasawaraapw: we should definitely make a note of it so people are at least aware17:21
apwon the incoming bugs side, we are seeing about 7 bugs a day reported by apport nwo17:21
apwseems pretty steady at the moment.  still no real feel for any patterns in them17:21
* kirkland reads some scrollback17:21
apwogasawara, ack17:21
ckingapw: any bugs related to the extended suspend/resume bugs?17:21
IntuitiveNippleBug #331415 could bite us; I'm trying to analyse which devices/drivers are affected17:21
ubottuLaunchpad bug 331415 in linux "request_firmware() fails on resume from suspend" [Medium,Triaged] https://launchpad.net/bugs/33141517:21
kirklandapw: cool, okay, yeah, so i have a blog entry drafted, with instructions and a call for testing17:21
apw[ACTION] apw ogasawara to revisit suspend/resume testing instructions17:21
kirklandapw: i'll publish that today17:21
MootBotACTION received:  apw ogasawara to revisit suspend/resume testing instructions17:21
apwkirkland, ok cool17:22
kirklandapw:  it was embargoed on review of my manager ;-)17:22
kirklandapw: dendrobates approved it earlier this morning for publication17:22
apwcking, only seen one from extended testing and that was a first pass failure17:22
ogasawaraIntuitiveNipple: I can help you scan through bug reports17:22
apwok ... cool17:22
apwIntuitiveNipple, that souds like it needs investigating for sure17:23
apwlet us know if you need any help on the kernel channels17:23
IntuitiveNippleogasawara: 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
apwyeah a tricky one if we are still in the fridge17:24
apwanything else suspend/resume?17:24
IntuitiveNippleI 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:24
apwIntuitiveNipple, fair point17:25
apw[TOPIC] Vanilla Kernel Builds17:25
MootBotNew Topic:  Vanilla Kernel Builds17:25
apwok ... on the mainline builds these are now progressing nearly automatically17:25
amitkapw: any statistics on the uptake?17:26
apwhopefully by next week cron will be taking the strain and we will be off the hook17:26
apwnothing numerical.  i habe been thanked for them by a number of people who are17:26
apwusing them for all sorts of unexpected things17:26
IntuitiveNippleThey're coming out faster than I have chance to test them:)17:26
apwso i think generally they are a good thing.  now that they only take space and no people time17:26
apwstill not had any time to try and PPA them, not a priority at this time17:26
amitkapw: I think we should mention this in some debian channels too17:27
apwyeah thats a good point.  i wonder if they would install on any debian based system.  presumably yes17:27
ogasawaraapw: if and when they're ready for wider consumption, the community has offered to help advertise17:27
ogasawaras/community/community team/17:27
apwogasawara, i think we are at the point where they are as good as they are going to get17:27
apwso we should be considering an annoucnement.  are you in the frame for that :)17:28
ogasawaraapw: ok cool.  I'll write up a wiki too then.17:28
apwthere are some wiki pages on it already17:28
apwis a good starting point on consumption of the builds17:28
ogasawaraapw: even better then.  I'll whip up an announcement.17:28
apw[ACTION] ogasawara to prepare annoucement for mainline builds17:29
MootBotACTION received:  ogasawara to prepare annoucement for mainline builds17:29
apwany other projects anyone needs to report on?17:29
apw[TOPIC] ARM Tree17:29
MootBotNew Topic:  ARM Tree17:29
apwamitk, anything other than the arm config changes you want in?17:30
amitknot for A517:30
apw[TOPIC] LPIA Tree17:31
MootBotNew Topic:  LPIA Tree17:31
apwthe only thing i know of here is that the Jaunty tree is now officially merged17:31
apwsconklin, anything from you?17:31
sconklinnot at the moment17:32
sconklinI'm looking at LPIA again17:32
apw[TOPIC] Incoming Bugs17:32
MootBotNew Topic:  Incoming Bugs17:32
apwogasawara, any horrors for us to run away from?17:32
ogasawaraapw: nothing critical.  IntuitiveNipple already mentioned bug 33141517:33
ubottuLaunchpad bug 331415 in linux "request_firmware() fails on resume from suspend" [Medium,Triaged] https://launchpad.net/bugs/33141517:33
ogasawarathere's another regression, bug 32743117:33
ubottuLaunchpad bug 327431 in linux "iwl3945 cannot connect to hidden ssid WPA enterprise with Hardy 2.6.24-23 - Regression" [High,Triaged] https://launchpad.net/bugs/32743117:33
apwsmb_tp, ^17:34
IntuitiveNippleI was about to mention that one, as well17:34
ogasawaraI'm just finishing up adding a regressions section to the bug list17:34
smb_tpapw, Not looked at this I think17:34
apwthey both on our critical list17:34
apwogasawara, thanks, we will find someone to look at those two then17:35
smb_tpapw, We might need to walk over the critical list and see whether we need to spit up between the two of us17:35
apwsmb_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:35
apw[ACTION] smb_tp apw to review the critical bugs17:36
MootBotACTION received:  smb_tp apw to review the critical bugs17:36
ogasawarasmb_tp, apw:  some might be a bit stale (ie not tested with jaunty yet) so I'll sweep through and triage17:36
IntuitiveNippleI 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
apwIntuitiveNipple, sounds good.  keep us informed :)17:36
apwogasawara, sounds like a plan, thanks17:36
apw[TOPIC] Open discussion17:37
MootBotNew Topic:  Open discussion17:37
apwanything else?17:37
IntuitiveNippleI have a couple of things to mention, when everyone else is done :)17:37
apwit sounds pretty quiet out there, so go ahead17:37
apwIntuitiveNipple, ?17:38
IntuitiveNippleOK. 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:38
IntuitiveNippleSecond: ...17:39
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-pci17:40
IntuitiveNippleIt'll make Linux's IOMEM allocation on a par with Windows17:40
apwIntuitiveNipple, always good to have people helping us out ... #ubuntu-kernel is our home, hastle us17:40
apwIntuitiveNipple, sounds interesting, cirtainly i would be happy to review17:40
amitkand kernel-team list is available for patch review discussions17:41
IntuitiveNippleI'm always there - and when I'm on IRC I am available. I don't leave the client logged in.17:41
IntuitiveNippleamitk: Yes, thanks. I don't want to drop anything until Jaunty is done and dusted17:41
apwwe are never done and dusted, just on another release17:41
IntuitiveNipplerelatively speaking17:42
apwok ... anyone else got anything?17:42
apwelse thats a wrap17:42
apwthanks to IntuitiveNipple and jro for your input ... come again!17:42
MootBotMeeting finished at 11:43.17:43
=== fader is now known as fader|lunch
=== RainCT_ is now known as RainCT
=== fader|lunch is now known as fader
Veselushko :D19:44
=== RainCT_ is now known as RainCT
=== asac_ is now known as asac
=== WaVeR` is now known as WaVeR

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!