[11:03] <DarkSun88> Hi all
[03:58] <zul> @schedule montreal
[03:58] <ubotu> Schedule for America/Montreal: 12 Jun 11:00: Kernel Team | 13 Jun 08:00: Edubuntu | 14 Jun 12:00: Ubuntu Development Team | 16 Jun 13:00: Xubuntu Developers | 19 Jun 15:00: Technical Board | 20 Jun 16:00: Edubuntu
[04:51] <zul> do do do
[04:55] <philth> do do do doooo
[04:55] <philth> Smoooooke on the water..
[05:01] <zul> hey
[05:01] <BenC> hello
[05:01] <philth> hi
[05:01] <BenC> waiting for someone
[05:02] <BenC> there he is :)
[05:02] <BenC> Ok, agenda is at https://wiki.ubuntu.com/KernelTeam/Meeting
[05:02] <BenC> Team status will be short
[05:02] <BenC> first I'd like to welcome amitk, just starting with us today
[05:03] <BenC> amitk has a strong background in linux power savings and similar areas
[05:04] <BenC> kyle is currently at UME sprint, and rtg is away this week
[05:05] <BenC> going to skip around in the agenda. I don't want cr3 to sit idle watching our discussions, so lets get the KVM stuff out of the way first
[05:05] <BenC> I did a test logon to the KVM this morning with cr3, and it went pretty well
[05:06] <BenC> so this should give us some excellent access to machines in their centre
[05:06] <BenC> cr3: did you have any comments on the kvm at this point?
[05:06] <dholbach> Rock On, amitk!
[05:07] <BenC> Guess not, let's move on :)
[05:08] <BenC> heno: I assume you are representing the debian-qa team for that agenda item?
[05:08] <BenC> err, distro-qa
[05:08] <heno> BenC: indeed
[05:08] <zul> debian-qa?
[05:08] <heno> yes, I'm a DD now ;)
[05:09] <cr3> BenC: should I mention the 3 annoyance points discussed together?
[05:09] <BenC> cr3: I think they are worth mentioning, yes
[05:10] <cr3> so, after testing the KVM setup with BenC this morning, these are three annoyance points which I would like to address before the next meeting:
[05:10] <cr3> 1. requiring a VPN to the certification network might conflict with local addresses
[05:10] <cr3> 2. list of machines in machines.txt is a pain, I really hate how machines are scattered all over the place: text file, salesforce and wiki. I really want this to all appear in the hardware certification website, if that makes sense to everyone too.
[05:10] <cr3> 3. having to refer to machines by the kvm id is also a pain, might as well have a canonical id which can be used as a reference everywhere
[05:10] <cr3> If there are point that should be given higher precedence, please let me know.
[05:11] <BenC> the vpn is the ugliest...would be nice to have an ssh tunnel instead
[05:12] <BenC> or even an stunnel with client side certs
[05:12] <cr3> BenC: I had originally tried with an ssh tunnel but had problems, so vpn was the quick and dirty solution. I'll try again, I'm sure there's a way to get it working somehow
[05:12] <BenC> cr3: if you need more testing, let us know
[05:13] <cr3> BenC: thanks for the offer :)
[05:13] <BenC> cr3: ok, thanks for dropping in and getting this setup done
[05:13] <BenC> I've noted the items and the action item for working on killing vpn
[05:15] <BenC> heno: so, what does distro-qa have in store? :)
[05:15] <heno> Just wanted to introduce the distro-qa team. We will keep track of certain high impact bugs that originate from our HW testing, our partners of from support. My thinking is to assign hese to the kernel-team and give them a non-zero priority so they show up on everyone's radar. It's of course up to you how you divide that up within the team.
[05:19] <heno> (just the kernel bugs, obviously)
[05:19] <BenC> thank goodness :)
[05:19] <BenC> assigning to kernel-team and giving priority is exactly how we handle bugs now...is there some way to flag the bugs that need more immediate attention?
[05:19] <heno> They'll be subscribed to distro-qa and I can also tag them
[05:19] <heno> I'll also feature certain bugs at the weekly distro meetings
[05:19] <BenC> arbitrary tags are a complete mess we can't manage (or enforce)...so distro-qa subscribe sounds like a good filter
[05:19] <heno> ok, cool. that's already in place
[05:19] <BenC> ah, excellent
[05:19] <heno> https://bugs.launchpad.net/~distro-qa/
[05:19] <BenC> heno: would it make more sense to pull kernel related bugs into the kernel team meeting instead of distro? Only downside is we are bi-weekly
[05:19] <heno> are the ones we are following so far
[05:19] <cr3> heno: could HW testing or support tag the bugs for you?
[05:19] <cr3> heno: reason I offer is that we already have to set milestone and perhaps priority, so setting a tag wouldn't be any more work
[05:20] <heno> BenC: if I could email a list to someone to present here that might work well
[05:20] <heno> cr3: right, I still have to think a bit about how best to group these
[05:20] <heno> people have mixed luck with tags, as Ben says
[05:21] <BenC> heno: sure, email me lists as you feel appropriate and I'll add it to the agenda for our meetings
[05:21] <BenC> might be more focused than the distro meetings
[05:21] <heno> so, just a heads up for now. I'll work more on this process and we'll speak in London
[05:21] <BenC> sounds like a plan
[05:21] <heno> right, that's true
[05:23] <heno> thanks, that's it from me
[05:23] <BenC> heno: I might just make it a rolling agenda item to discuss high prio distro-qa kernel bugs
[05:23] <BenC> we can update the bug status based on the discussion
[05:23] <BenC> add comments and such
[05:24] <heno> good idea
[05:24] <BenC> heno: ok, thanks for your time. In London, the kernel team will be having frequent break out sessions to handle some coordination, so we can do something with you as well
[05:24] <heno> great, let's schedule a session
[05:25] <heno> on this and bug workflow in general
[05:25] <heno> pop quiz: how many open bugs against the kernel today? :)
[05:25] <BenC> gutsy, about 25 :)
[05:26] <zul> alot
[05:26] <BenC> feisty is like 700-800
[05:26] <heno> BenC: which is great, because that's the important number
[05:26] <heno> about 3000 total
[05:26] <heno> but much of that is just noise at this point
[05:27] <heno> (which is an issues in itself)
[05:27] <heno> we should consider some mass closings at some point, at least at EOL
[05:27] <BenC> I did that for 2.6.12, IIRC
[05:28] <heno> ah, right, yeah the old ones are nearly empty
[05:28] <BenC> So let's move on to gutsy kernel hand-off
[05:29] <zul> goodie
[05:29] <BenC> amitk, pkl_: Unfortunately, it's just us 3 here. I would rather do this with all 5 of us, but I can't hold off on it, so we'll start here, and I'll bring kyle and rtg up to speed later
[05:31] <BenC> The basic idea here is that gutsy kernel is where all the action should be at, but because of my initial process for "each team member is responsible for a kernel", it's become quite isolated
[05:31] <BenC> I want to totally, over a period of time of course, get my hands off it, and get the rest of the team working on it
[05:31] <BenC> as a group
[05:32] <BenC> the only twitch to this process is git is funky when we're working with w rebased tree and > 1 developer accessing it with the intention of writing to it
[05:33] <BenC> once 2.6.22 is released, this wont be much of an issue anymore, since the rebase will stop
[05:33] <BenC> so we need a good process for you guys to not step on each others changes
[05:33] <BenC> or at least, good communication about who is doing what, and when someone plans a rebase to linux-2.6.git
[05:34] <BenC> but aside from the technical issue, the process should just be a free-for-all of everyone doing whatever needs to be done
[05:35] <BenC> with normal discussion on kernel-team@ for anything that would be considered questionable
[05:35] <amitk> why can't we all have our own trees, and we (individually) are responsible for rebasing to the gutsy tree?
[05:35] <zul> thats what kind of happens now doesnt it?
[05:36] <BenC> amitk: you can have your own tree, and you can keep it on kernel.ubuntu.com if you want
[05:36] <BenC> but the lifetime of changes in that tree are going to be very very short
[05:36] <zul> what I would do is send an email to kernel-team@ with a diffstat asking for a merge *shrug*
[05:36] <zul> doh..
[05:36] <zul> ls
[05:40] <BenC> how this is all going to work will be a work in progress...there are three goals to this: 1) Get the team working on stuff, and 2) Get the team working together more closely, and 3) Give me more time to step back from day-to-day dev stuff so I can make sure the rest of the team has what it needs to get things done
[05:42] <BenC> So this is a heads up of some upcoming process changes in our devel cycle, and some expectations of what you guys will need to do
[05:43] <BenC> any questions? :)
[05:43] <zul> nope but I guess the community people is involved with that stuff as well?
[05:47] <pkl_> BenC: none at the moment...  It all sounds quite sensible, the test will come when we try to do the co-ordination in practice.
[05:47] <BenC> they can be, yes...but frankly my focus is on making sure that people we hired have work to do
[05:47] <amitk> who QAs the code?
[05:47] <BenC> amitk: most original code we write gets sent to kernel-team@ list, and needs at least one other person to sign-off on it
[05:47] <BenC> amitk: we try to mirror normal upstream kernel development as much as possible to make it easier for people to work with us who are already used to working with lkml/git/linus (and vice versa)
[05:47] <BenC> but we're kind of making kernel-team == Linus in that comparison
[05:47] <amitk> there is no problem till someone decides to rebase to Linus' tree, right?
[05:47] <BenC> right, and that shouldn't happen often, and it only happens until our target version is released (2.6.22, right now)
[05:48] <BenC> it's a quirk, but a big one...some one will have to say "heads up, I'm doing a rebase this weekend, so push all your changes if you want to make things easier"
[05:48] <amitk> will a fixed rebase schedule help?
[05:49] <BenC> yeah, that's what I'm thinking
[05:49] <BenC> friday night rebase parties :)
[05:49] <amitk> so we rebase once (or twice) a week, say, wed and fri, and deadline to get code in is previous day
[05:50] <BenC> twice a week is probably good, after hours, maybe someone different can do it each time
[05:51] <BenC> action item for me, create schedule for rebase during devel cycle, create upload schedule matching milestone releases
[05:51] <BenC> process for rebase, process for group development on devel tree
[05:52] <BenC> I think we're good for today unless anyone has any last minute issues to bring up?
[05:52] <pkl_> after hours in the US for the Europe based people will be really after hours.  In practice this will probably mean early in the morning...
[05:53] <BenC> pkl_: we'll make it a UTC time frame, everyone will just need to be aware of how it affects their work day
[05:54] <BenC> something like 17:00 UTC
[05:55] <BenC> ok, thanks everyone for joining, especially to heno and cr3 for taking time to talk with us
[05:55] <BenC> adjourned
[06:18] <PriceChild> mc44, smells
[10:23] <shawarma> @schedule copenhagen
[10:23] <ubotu> Schedule for Europe/Copenhagen: 13 Jun 14:00: Edubuntu | 14 Jun 18:00: Ubuntu Development Team | 16 Jun 19:00: Xubuntu Developers | 19 Jun 21:00: Technical Board | 20 Jun 22:00: Edubuntu | 21 Jun 20:00: Mozilla Team
[10:27] <fabbione> @schedule aalborg
[10:27] <fabbione> :)
[10:31] <shawarma> :)
[10:31] <shawarma> ECITYTOOSMALL
[10:37] <fabbione> it just doesn't know about continental dk TZ.... :)
[10:37] <fabbione> shawarma: btw.. the last weekend in June i will be in rhus/Randers
[10:45] <shawarma> fabbione: I'll be leaving for the server sprint that Friday, unfortunately. My girlfriend is there with her father the week leading up to it and then we have the weekend together over there.
[10:45] <fabbione> shawarma: oh right.. too bad...