[08:48] <mether> skvidal: ok
[08:56] mspevack (i=mspevack@fedora/mspevack) joined #fedora-board.
[08:57] Topic changed on #fedora-board by mspevack!i=mspevack@fedora/mspevack: Board meeting 2006-12-12 @ 10:00 EST (15:00 GMT)
[08:57] <mether> mspevack: can I call now
[08:58] <mspevack> yep
[08:58] <mether> excellent
[08:59] mdomsch (n=Matt_Dom@cpe-70-112-153-20.austin.res.rr.com) joined #fedora-board.
[09:01] <skvidal> mspevack: I'll be late - conflicting day-job meeting
[09:01] <mspevack> no problem seth
[09:02] <mspevack> just waiting on people to arrive
[09:03] <mspevack> max, bill, matt, rahul are all present.
[09:04] <mspevack> jeremy is on the phone
[09:04] notting (i=notting@redhat/notting) joined #fedora-board.
[09:04] <mspevack> when gdk walks in, we will start
[09:07] <mspevack> fedora 7 plan, and messaging for matthew's direct reports
[09:07] <mspevack> also the rest of release enginerring
[09:08] <mspevack> those are basically the final steps in the "buy in of our plan"
[09:09] <mdomsch> blizzard joins
[09:09] <mspevack> bill -- we need to get a schedule in place, and start acting on the planned items
[09:11] <mspevack> max -- so once we get that last buy in, assuming it happens shortly, then what?
[09:11] rdieter (n=rdieter@sting.unl.edu) joined #fedora-board.
[09:12] <mspevack> bill -- message what we're doing all internally/externally, schedule for the merge, public plan for the build system, what we're doing for test1/test2 timeframe
[09:12] <rdieter> sorry folks, I'm out of cell-range atm.
[09:12] <mspevack> also the governance and committee ideas for the new Fedora universe
[09:12] <mspevack> greg -- when we get a list in public that everyone can see, then the public can tell us whether we're missing anything or not
[09:13] <mspevack> bill -- also, then it's possible to talk about any other technical things that we may or may not be interested in for fedora 7
[09:16] <mspevack> part of the remaining messaging involves reassuring folks within Red Hat that nothing really changes for RHEL5 at all, as a result of our Fedora plans
[09:16] <mspevack> chris -- keep the messaging as simple as possible
[09:17] <mspevack> matt -- so, what in terms of a Test1 release?  what are we trying to accomplish by a test1, that our end users will see?
[09:17] <mspevack> bill -- just making it build, smoke-tested, etc.  No real major Test1 work right now
[09:18] <mspevack> max -- shouldn't our test releases be based around the build system work, etc?
[09:18] <mspevack> rahul -- test1 releses are generally not of much interest except for specific features
[09:18] <mspevack> bill -- and we don't have any features
[09:19] <mspevack> matt -- i want users to have a reason to upgrade to f7, and i haven't seen anything that makes people upgrade rather than it's just the latest
[09:20] <mspevack> bill -- we have talked about ideas of how we can make changes to a desktop or server package, etc.
[09:20] <mspevack> chris -- there are a few things, a new firefox, etc.  
[09:21] <mspevack> greg -- if we're talking about things that excite users, liveCD is the major thing
[09:21] <rdieter> livecd, pungi, definitely.
[09:21] <mspevack> chris -- i'm not sure?  talking about how cool it is to generate your own liveCD perhaps
[09:22] <mspevack> bill -- livecd is interesting from an evangilization perspective.  that's the benefit of fc6 livecd
[09:22] <mspevack> greg -- jeremy, how likely is it to have bits in anaconda that can install livecd by fedora 7 test1/test2?
[09:22] <mspevack> jeremy -- well, that depends when test1 is going to be :-)
[09:23] <mspevack> greg -- but we keep saying "how can we set a milestone if we don't know what's going in" and then "we can't know what's going in until we set some milestones".  so which is it
[09:23] <skvidal> grr
[09:23] <notting> hi seth!
[09:24] <skvidal> hi
[09:24] <skvidal> still in the day-job meeting
[09:24] <rdieter> I think a tentative milestone date is a good place to start.
[09:25] <mspevack> max -- yesterday i suggested april 16th as GOLD
[09:27] <mspevack> relesae -- 4/23
[09:27] <mspevack> gold -- 4/16
[09:27] <mspevack> test3 -- 3/26
[09:27] <mspevack> test2 -- 2/26
[09:27] <mspevack> test1 -- 1/29
[09:28] <mspevack> fudcon -- between test1 and test2
[09:28] <mspevack> freeze dates all one week before
[09:29] Action: mdomsch stays on the call but drops off irc
[09:29] mdomsch (n=Matt_Dom@cpe-70-112-153-20.austin.res.rr.com) left irc: "Leaving"
[09:30] <mspevack> jeremy -- regardless of the summit, it's a pretty reasonable schedule
[09:30] <mspevack> greg -- let's let max worry about the summit
[09:32] <mspevack> bill -- coming back to f7, what are we going to do with the name?
[09:32] <mspevack> greg -- prevailing wind is just fedora 7...
[09:33] <mspevack> *********** Fedora 7 is the name ***********
[09:33] <mspevack> unanimous
[09:33] <mspevack> jeremy -- we can still give the 'package universe' a cute name if we need to
[09:33] corbet (n=user@vc7-1-72.dsl.netrack.net) joined #fedora-board.
[09:35] <mspevack> max -- talking about source control.  jeremy is of the opinion that we're not doing enough to make it worth all the changes to cvs.
[09:35] <mspevack> bill -- distributed would be nice
[09:35] <mspevack> greg -- do we need distributed to make it easy for people to move bits from fedora to rhel and rhel to fedora?
[09:35] <mspevack> greg -- that seemed to be one of the big concerns.  if that's not really that big of a deal...
[09:35] <mspevack> bill -- it is a good thing, but we don't necessarily need it *right now*
[09:36] <mspevack> jeremy -- i liked the idea of creating a group to look into it and come back with a recommendation
[09:37] <mspevack> max -- and that idea was floated before, and we never moved forward with it
[09:38] <mspevack> chris blizzard, source control SIG leader
[09:39] <mspevack> fudcon
[09:40] <mspevack> greg -- i had been operating under the assumption that in the worst case we could have it at the Mugshot office like we did the FedoraSummit.  But maybe not -- regardless, we're still shooting for Feb 9-11, which is Friday - Sunday.
[09:41] <mspevack> sort of a BarCamp on Friday, hackfest saturday/sunday
[09:41] <mspevack> need to move on -- NOW -- knowing exactly who we want at the event and getting them invitations
[09:42] <mspevack> need to find a core set of strong people who can contribute, and who we can invite and fully subsidize
[09:43] <mspevack> greg will send a first draft of names to the board list
[09:43] <mspevack> our "fantasy roster of engineers we'd love to have working on Fedora for a couple of days"
[09:44] <mspevack> max has a list of "interesting coding topics" as well that we can start with
[09:53] blizzard (n=blizzard@H11.C26.B96.tor.eicat.ca) joined #fedora-board.
[09:53] dgilmore (n=dennis@fedora/dgilmore) joined #fedora-board.
[09:55] <dgilmore> hows the meeting comminag along?
[09:56] <mspevack> good, we're off on a tangent that doesn't really need IRC
[09:56] <mspevack> max -- anything else?
[09:56] <mspevack> seth -- want to mention some stuff from the LSB meeting last week
[09:57] <mspevack> the plan regarding how the LSB will function in the future.  it seems to me (seth) that it will be impossible for Fedora to be LSB4 compliant
[09:57] <mspevack> greg -- why?
[09:57] <mspevack> to be LSB 4 compliant, you'll have to be LSB 3 compliant?  and so on
[09:58] <mspevack> RHEL can be LSB compliant if they want to, regardless of Fedora.
[09:58] <mspevack> blizzard -- we shouldn't decide anything until we see the actual specs
[09:59] <mspevack> seth -- i didn't make a decision, i just said what I thought was likely
[10:00] <mspevack> seth -- things like LSB compliance can have an impact on people's perspectives.  it's a risk (one way or another) we need to be willing to take.
[10:00] <mspevack> greg -- if we can get LSB compliance for relatively little pain, great.
[10:02] <dgilmore> not all arches have lsb defined 
[10:02] <dgilmore> there is no LSB for SPARC
[10:03] <notting> dgilmore: is there the solaris standard base
[10:04] <dgilmore> notting: i dont think so 
[10:04] <dgilmore> notting: i dont care for SPARC/solaris 
[10:08] <dgilmore> i guess any arch can be covered under the generic LSB definition.  MIPS, alpha, SPARC, etc  dont have LSB specific definitions