Call for Votes: Nomination of Matthew Garrett to Ubuntu Technical Board

[Matt Zimmerman]

At today's meeting of the Technical Board, the floor was opened for
questions for Matthew regarding his nomination for a position on the Board.
What follows is an unedited log of this portion of the meeting, for the
benefit of those who could not attend, but will participate in the vote.

* ogra waits for the canvassing
* sabdfl waits for the curve balls
* bddebian waits for a beer
<mjg59> Oh, come on. /Someone/ must have something to ask me :)
* Loiosh joins bd.
<mdz> mjg59: what do you see as the most important responsibility of the technical board?
<sabdfl>  /invite godot
<ogra> lol
<pitti> mjg59: do you closely follow MOTU development to be able to judge new candidates?
<sabdfl> mjg59: can you think of areas of the technical infrastructure of ubuntu that need serious cleaning up?
<mjg59> mdz: Ensuring that we don't accidently do something *really stupid*
<sabdfl> i.e. "staring down the sabdfl"
<zenrox> mjg59 follow up question how your you inforce the  most important responsibility?
<zenrox> your=would
<ogra> mjg59, how do you plan to relate your work for dccalliance to the work on ubuntu ?
<mjg59> pitti: I don't have enough time to follow every MOTU in detail. However, it's easy enough to check how candidates are doing
<mdz> mjg59: for example? (something stupid, and how the board would prevent it)
<pitti> mjg59: I for my part find it nontrivial
<mjg59> (I'm giving short answers here because of the number of sudden questions - please ask if you'd like any elucidation)
<zenrox> elucidation??
<mjg59> ogra: You're joking, right?
<ogra> sure
<mjg59> Haha
<sabdfl> mjg59: can you think of ways we COULD work constructively with the DCCA?
<mjg59> mdz: We don't have the same sort of personal responsibility for packages as Debian has. It's possible for someone to alter a set of packages in a way that they believe solves a real problem - if someone else disagrees, there's not necessarily a good claim of authority in one case over the other
<mjg59> In general, one of these opinions will be more technically correct than the other, and that's the sort of decision the tech board ought to be making
<sabdfl> what would you see as the most effective way to improve the usefulness of ubuntu to people who run servers, not desktops?
* TiMiDo has quit (Remote closed the connection)
<mdz> sabdfl: -EWOULDBLOCK, you already have a question in the queue ;-)
<sabdfl> mjg59: the idea of arbitrating between two good ideas is very interesting, and i think a good example.
<bddebian> heh
<sabdfl> mdz: ESORRYBACKINGOFFNOW
<mjg59> sabdfl: Lacking technical infrastructure - if I said "The ability to release a distribution right now", would I be punched? :)
<sabdfl> mjg59: that's really up to them to organise :-)
<mjg59> But other than that, not really - bugzilla makes it a bit too easy to lose track of what still needs doing, but I'm hoping Malone should make that easier
<mjg59> How could we work constructively with the DCCA? I think trying to work with them (and, by proxy, Debian) on LSB compliance would be a good plan as far as possible
* zul has quit ("leaving")
<mdz> mjg59: what qualities do you feel are most important when considering potential Ubuntu developers?
<mjg59> Improving Ubuntu for server users - GUI tools for managing large numbers of machines
<ogra> ++
<\sh> "How to package empty packages"?
<ogra> \sh, the Mez syndrome ? 
<mjg59> mdz: Ability to understand how their contributions impact upon the entire distribution
<bddebian> Uh oh :-)
<mjg59> That's important both from the point of view of functioning as a team, but also in terms of producing a distribution that's well integrated
<mdz> mjg59: what methods would you use to measure that understanding on the part of a particular individual?
<mjg59> mdz: Look for packages that interoperate with other packages in the distribution
<mjg59> Ideally where that's been done by working with people looking after those other packages
<mjg59> That's not always possible, but I think it ought to be encouraged
* ivoks has quit (Connection timed out)
<mdz> further questions for mjg59?
<bddebian> Are they open to anyone or just TB?
<mdz> remember, folks, it's the community at large who will be voting here, not just the tech board
<mjg59> Questions from anyone
<ogra> bddebian, anyone
<jbailey> mjg59: What's in it for you? =)
<jbailey> More fully: It seems like alot of work and responsibility.
<jbailey> You already do alot.  Why do you want to do more?
<bddebian> mjg59: I'm curious if you have any thoughts about a closer relationship between MOTU's and main or do you even see an issue there?
<mjg59> jbailey: Somebody needs to do it. 
<mjg59> And I think for someone to do it well, they need to be heavily involved in the project
<mjg59> If I didn't do it, some other poor bastard would end up with the job :)
<jbailey> =)
<bddebian> Heh
<pitti> mjg59: in the beginning of the TB meetings, we had a lot of technical discussions, nowadays the main action is about approving new maintainers; do you feel that you have enough experience with the MOTU community for the latter?
<Loiosh> Just because I'm missing this... what is the DCCA?
<\sh> mjg59: was it not more the case, that the call came from sabdfl, and there is nothing in the ubuntu which can overrule sabdfls call? ,-)
<\sh> +world even ;) 
<mjg59> More importantly, I think it's important that the tech board have input from the community, not just from Canonical staff
<jbailey> mjg59++
<ogra> \sh, the suggestion came from sabdfl but the TB expressed the need fr an additional member before
<ogra> *suggestion for mjg59 
<sabdfl> mjg59: +1 on that
<\sh> ogra: how many smilies should i draw? :)
<ogra> ;)
<mjg59> pitti: I don't think approving MOTUs should be seen as the most important role of the TB. It's one role amongst many. I'll happily admit that there are people with a better understanding of the state of play of MOTU, and I'm also happy to admit that I'd rely on them for guidance. But any TB member has to be able to deal with the other responsibilities as well.
<mjg59> Finding someone who could satisfy all criteria perfectly is fairly unrealistic :)
<pitti> mjg59: right, that was my impression, too. thanks
<bddebian> How many/what members are close to the MOTUs?
<pitti> mjg59: I did not mean that as an offence, by no way
<mjg59> \sh: He hasn't got my signature on a contract yet, so I get to ignore him as much as I want to :)
<pitti> mjg59: I'd love to see your weight in technical decisions
<ajmitch> bddebian: TB members?
<\sh> mjg59: hehe :)
<mjg59> pitti: Oh, yes - I hadn't interpreted it as one
<mjg59> Loiosh: www.dccalliance.org
<mjg59> (not to be confused with www.dccalliance.biz)
<pitti> mjg59: I'm not sure why there are so few technical discussions on TB nowadays - maybe they have moved to the specification BoFs :-)
<bddebian> ajmitch: How many of the Technical Board itself I should say
<mjg59> bddebian: I think it's fairly inevitable that main and MOTU will remain separate, simply because of the different standards demanded from the two groups
<pitti> mjg59++
<bddebian> mjg59: I got that.  My question is more around taking resources from main and vice versa.  Elmo for example gets inundated with sync requests from us
<\sh> mjg59: two serious questions: 1. When the LaptopTesting started, and we had the problems with the sk98lin driver, you explained (and even fabbione) that we're not including the driver of syskonnect. Why did you change your opinion, patched it and included it in the final "product"?
<mjg59> Personally, I think it would be great to see more community members with main upload privileges. But for that to be possible, we need to be sure that they're able to package software we can commit to supporting for a long time
* crimsun (i=crimsun at pdpc/supporter/silver/crimsun) has joined #ubuntu-meeting
<pitti> mjg59: not only that, we should also be reasonably sure that they are available for a longer time
<pitti> Hi crimsun 
<bddebian> Heya crimsun
<\sh> 2. Do you, personally, see a success story of the dcca, regarding the unsuccessfull tries of SuSE and others to establish such a thing like an alliance? (UnitedLinux it was I think)
<crimsun> (hi, don't want to interrupt :-)
<mjg59> \sh: The original decision was made because a supportable driver was appearing in the near future. In the end it turned out that the decent driver wasn't adequate for us.
<ajmitch> mjg59: for dapper, what is your opinion of what we should focus on (technically) for it to be 'enterprise-ready'?
<\sh> mjg59: but what was important for you? The need of the User or "the decent driver wasn't adequate for us"? 
<mjg59> The sk98lin driver is basically impossible to support for any length of time. It's effectively the Windows driver with a think Linux layer around it. Supporting it would have been a nightmare. In the end, we took the decision to ship it only for the small set of devices that wouldn't otherwise be supported.
<mjg59> \sh: Shipping a driver that we can't support is not necessarily preferable than shipping no driver, as far as the user is concerned
<mjg59> Users want us to be able to keep to our commitments
<mjg59> The sky2 driver simply didn't work for most people
<mjg59> So in the end that wasn't an option
<mjg59> ajmitch: Stability, stability, stability
<pitti> ajmitch: which process changes would you prefer to achieve that?
<pitti> erm
<pitti> s/ajmitch/mjg59/
<ajmitch> mjg59: with that stability in mind, what do you think about when UVF & feature freeze should be? earlier?
* pef has quit (Connection timed out)
<mjg59> For the long-term supported releases, certainly
<mjg59> pitti: Reducing code churn earlier in the process
<mjg59> It'd also be good to see more management utilities
<mvo> mjg59: what kind of utils do you have in mind here?
<mjg59> The infrastructure needed for Ubuntu to be enterprise ready certainly exists - that's easy enough to see from it being used in the enterprise...
<mjg59> mvo: Better tools for managing user profiles and lockdown
<mjg59> But it ought to be easy for me to push a package out to 500 machines
* mvo nods
<ogra> mjg59++
<mjg59> If I'm managing a set of servers, I want to be able to check that they're all up to date with security patches in under 30 seconds
<mjg59> Linux tends to be lacking in that sort of area - making life easy for the admin of large networks
<mjg59> So the admin ends up writing a bunch of scripts to do it, and we get code duplication all over the planet
<Kamion> mjg59: I'm guessing that running the LaptopMission project has given you a fair amount of experience with working with maintainers and packages throughout a pretty good cross-section of Ubuntu. Is there anything you'd change as a result of that experience?
<Kamion> (either technical matters of laptop support, or process)
<mjg59> Sometimes small changes to large packages are needed in order to support something
<mjg59> Writing that change is easy enough, but it's not practical to integrate it and upload it, especially when that may disrupt what the maintainer is working on
<mjg59> So you submit a patch to bugzilla or whatever, and it's queued for inclusion
<mjg59> But from then on, there's no good way to see what's happening
<mjg59> And, inevitably, some of those patches get overlooked, and then you have to resort to chasing people up about it
<Mithrandir> from the maintainer's side, it's also way too easy to drop/not include patches unintentionally.
<mjg59> And that sucks
<Kamion> right, I can agree with that on both sides
<mjg59> Some way of managing those patches would be excellent
<mjg59> So, if I could change one thing, it would be to have that. And a pony.

-- 
 - mdz