--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
* dgilmore is here
notting is here
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
Hi everybody; who's around?
* tibbs here
spot is here
c4chris is here, hi All
nirik is here.
caillon is angry today
abadger1999 looks in
c4chrisc4chris: need a [] ?
bpeppleok, I see eight of us here, so we can probably get started.
--- bpepple has changed the topic to: FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-devel-list/2008-May/msg01414.html
bpeppleFPC had one proposal about  withdrawing the JPackage naming exception.
* jeremy
notting is +1. but i don't see anything in that report about the fpc vote
nirikis someone going to go thru and remove that and push new builds? at least for rawhide?
* spot would like to note that the fpc vote was unanimous
nirik+1 in any case...
spotnirik: i can do that.
nirikare we also going to change f7/f8/f9 ? or just rawhide?
tibbsnotting: You're right; I seem to have forgotten to summarize the vote.
spotnirik: just rawhide
spot+1 from me
tibbsnotting: The vote was unanimous among the seven members of the committee who were present.
bpeppleok, I see seven '+1', so FESCo doesn't object to the FPC proposal.
* jwb is here now
bpepplemoving on, unless someone has something else to add to this.
--- bpepple has changed the topic to: FESCO-Meeting - Cut-off date for new F7 packages - nirik, all
dgilmorebpepple: we should be done
nirikI dont much care. For the last cycle we stopped at release time for the new one (1 month left in life)
dgilmorebpepple: i thought it was agreed that when when the second release is out there will be no more new packages
dgilmorenirik: :)  i thought that was policy
nirikdgilmore: I thought so too, but I can't find anything codifying that policy
and not sure why it was we did that...
bpeppleIs this a case we just need to put this in a policy then?
cailloni don't really think we should cut it off.  if people want to support releases that we still officially support, more power to them.
nottingwell, considering it goes EOL a month after, stopping new packages now seems reasonable
dgilmorenirik: because at that point things should be slowing down
bpepplenotting: +1
dgilmorenotting: thats why it was done that way in the past.  the release should be preparing for EOL.
spotsomething related may be to consider having "release managers" for each release
that person would be responsible for coordinating such efforts, may help distribute load better
* f13
dgilmorespot: sounds reasonable
f13sorry I'm late, I had some people show up.
bpepplespot: yeah, sounds like a good idea to me.
c4chrisspot: sounds good
f13spot: I'm all for that
niriksure, but if we are accepting new builds/updates, why not new packages?
* f13 self nominates for rawhide.
nirikin any case, I don't care much, just wanted to know for cvs processing.
spotf13: well, not rawhide per se, but F-10
which happens to live in rawhide now. :)
c4chrisany takers for F-7 ?
* dwmw2 arrives
dgilmorenirik: i think that at this point only serious bug fixes should be getting done for F-7
bpeppledgilmore: +1
c4chrisdgilmore: I'd tend to agree
dgilmorenirik: if fixing a serious bug needs and update which needs a new package  then so be it
f13spot: yes but rawhide itself needs a constant release manager, which I would want to have responsibility of.
drago01dgilmore: how do we define "serious bugs" or who is going to enforce that?
nirikdgilmore: sure... I would think exceptions would be made if need be.
dgilmoredrago01: security/severe usability issue
nirikok, so vote: disallow new f7 branches starting soon (say monday) and announce today?
caillondgilmore, while i agree, we explicitly DONT have that requirement.
bpepplenirik: +1
dgilmoredrago01: by severe usability i mean it just doesnt work
nirik: +1
c4chrisnirik: +1
drago01dgilmore: ok
caillondgilmore, we have had this argument many times on fedora-devel list where people want to rebase, change API, etc
and others complain about it
and we just say "use best judgement"
dgilmorecaillon: :)  yes
caillonso i don't see why F7 is any different
dgilmorecaillon: the reason why we exteneded the release life was to allow people a month after a release to upgrade
nirikwell, introducing new packages so close to end of life also leads to the possibility of a broken package going out, and then no time to update it...
caillonnirik, that can happen for anything that gets pushed in the next month, be it new or not.
f13I'd prefer that we didn't do new packages, and left it up to maintainers best judgement with a heavy suggestion that only critical fixes go into F7
dgilmorecaillon: continuing to add new packages to F-7 does not give people incentive to upgrade to F-8 or F-9  until after F-7 is EOL
in which time a security issue might crop up that we cant fix
nirikcaillon: true, but I think more likely for a new package that hasn't hit the entire F-7 userbase yet, over a package thats been in and working.
spotperhaps we should cut off new F-(X-2) packages when F-X goes gold?
nottingspot: sounds good to me
jeremyspot: +1
tibbsCould we perhaps ban them by default but allow them with justification?
nirikspot: yeah, that is what we did last time... just not codified. I would be ok with that as a policy moving forward.
dgilmorespot: thats what i thought we decided upon last release
tibbsMany people just request them because they know F7 is still supported.
bpepplespot: +1
dgilmorespot: its what we did.  I guess we didnt chisel it in stone
f13haha, we probably did decide that and nobody codified it
c4chrisspot: +1
caillondgilmore, i don't think people need incentive to upgrade.  they either will or they won't.  there are still people on RHL 7.2
* f13 is welcome to suggestions for wording in the ReleaseEngineering/Overview page
bpeppleso, where on the wiki do we need to put this?
dgilmorecaillon: my last job i had a RHL-6.1 box
spotprobably on the cvs request wiki page
caillonexactly :)
* nirik notes we should add that item to the release checklist... "mark no new branches in F(X-2) and update cvsadmin page"
caillondgilmore, and walters has a patch to nag people to upgrade when there's a new release out.
bpepplespot: do you want to add it, or you want me to?
spotbpepple: please, add it. i've got more than enough on my plate atm.
bpepplespot: works for me.
caillon(for the record, -1 from me for this proposal)
f13please also add it to the ReleaseEngineering/Overview page
bpepplef13: will do.
f13I want to keep that a good source of info as to how we do releases.
bpeppleok, anything else on this or should we move on?
dgilmorelets move on
--- bpepple has changed the topic to: FESCO-Meeting - Kernel-libre: http://fedoraproject.org/wiki/Features/FedoraFreedom - all
f13currently pending requests will be honored?
dgilmoref13: yes
dwmw2: please speak up here
bpeppleIs Alexandre around?
jeremylxo ?
f13spot: can you wait on touching jpp packages in rawhide until I've got something from the jpackage folks?  I'll get something before Alpha.
dwmw2I set out what I believe to be the best way to approach this
lxoI am
spotf13: ok.
dwmw2kernel-libre is not it
f13dwmw2: +1
spotgood intentions of kernel-libre aside, i agree with dwmw2, a forked kernel is not a viable approach.
c4chrissame here
lxoplease drop the forked
there's no 'fork' in that
nottingso, two points: 1) we don't allow alternative kernels - ergo, kernel-libre as it is described does not fit 2) we don't allow random conflicts without specific reason. ergo, fedora-freedom does not agree with the guidelines
dwmw2lxo: that's only true if you feed your patches upstream. Which is what we're asking you to do
lxocan you please explain why you think that's not viable?
I don't have patches
spotlxo: you're scraping out the parts you dont like and making a new tarball.
thats a fork.
dwmw2lxo: that was question and answer, wasn't it?
nottinggiven that both #1 and #2 don't go with the guidelines, having a spin including them can't be called Fedora. so, -1 overall to the feature
lxoso, Fedora doesn't want a Freedom feature
dwmw2lxo: seriously, let's get the upstream kernel to the point where we can strip out the blobs
lxo: yes, we do. But we want it done right
lxosee above
* spot agrees with dwmw2
lxono conflicts with non-Free firmware
f13and now we're going in circles again
lxotherefore, no assurance to users that they can use Fedora in Freedom
dgilmorelxo: we want the work to happen upstream so that it benefits all users not just ours
lxocan we please disregard the linux-libre approach for a moment and consider where we want to get?
what's our mission? is freedom a feature indeed? how do we want to offer it to our users?
f13lxo: we'd like to get to where all firmware are in their own packages so that one /could/ make a subset of Fedora packages into a "free┬▓" spin.
spotlxo: i don't think anyone disagrees on the idea of separating the firmware inside the kernel, but it needs to be done cleanly, in upstream.
tibbsYour devinition of freedom is not the only definition of freedom.
lxoI get the impression you're getting distracted in opposing one particular approach you dislike, and throwing the baby along with the bath water
dwmw2lxo: it would be great to get to a point where we can ship a spin without the binary firmware
tibbsI would be much less annoyed by this discussion if it didn't have so much loaded language.
lxoso what's fedora's definition of freedom?
dwmw2I'd like the 'normal' kernel to support that, but allow users the freedom to add bits of firmware which they need
lxodwmw2, I don't see that happening in upstream kernel any time soon
it *is* hopeless
dwmw2lxo: I don't agree.
spotlxo: if someone who is motivated to take on that work actually starts doing it, it will happen.
dwmw2it's hopeless if you refuse to even try, and a priori refuse to send patches :)
cebbertyou want to ship a spin without firmware updates for processors so people can experience CPU bugs?
lxopeople have started that before
dwmw2if it's important enough to someone to actually get on with it, it'll happen
lxoit was actively pushed away
f13lxo: it was broached... poorly
nottinglxo: fedora *works with upstream*
spotlxo: there is a noted difference between "YOUR KERNEL IS UNCLEAN, FIX IT NOW" and "here's a patch to separate the firmware from the driver"
dwmw2lxo: I have outlined an approach which I think would have better success
lxoit's pointless to repeat what hasn't worked before
dwmw2if done sensibly
f13lxo: do it within reason and you've got something.  Do it as a fanatic and well you get plonked.
dwmw2i.e. not refusing to send patches.
nottinglxo: then why are we having this conversation again. it certainly hasn't worked before.
f13lxo: Can't never could because he never tried.
lxonotting, what does fedora do when upstream has implemented policies that conflict with our goals?
dwmw2lxo: 'pointless to repeat what hasn't worked before' has _always_ been untrue in Linux development
nottinglxo: do not conflate yours with mine with the project's
dwmw2and I've recommended that you do not merely repeat; I have made a different suggestion
lxoI'm talking about Fedora's stated mission of building an operating system out of free and open source software
f13a "working" operating system perhaps
but again, now we're down to arguing about words instead of talking about the actual issue.
dwmw2I propose that FESCo's response be "We'd love this feature, but it needs to go upstream first and not involve an alternative kernel package."
spotdwmw2: +1
lxodwmw2, I'll have to get back to you to even begin to understand what you're suggesting.  it appears to me that the suggested use case is already covered
f13lxo: we'd like to see you succeed in your mission.  We've given you examples of how to do it that would be acceptable to Fedora.  Either do it or don't.
caillonlxo, we also have another feature which is "we work with upstream".  and given how not working with upstream hurt debian's openssl package, i'd like to not give up that feature for your feature on such critical packages.
c4chrislxo: that's what we do, to the best of our belief.  It migth be our belief does not exactly coincide with yours, but that's life
bpeppledwmw2: +1
nirikdwmw2: +1
jeremydwmw2: +100
lxocaillon, again, what happens when upstream has goals that conflict with ours?
do we blindly follow upstream just because it's upstream?
nottinglxo: i'm not here to argue semantics. fedora has, *as a project*, approved the use of firmware that may not fit your definition of free. your semantical arguments about mission are, in essence, saying we should reconsider that decision. that is *NOT* the reason we're having a discussion now, so that's pointless to be discussing now
dwmw2lxo: to start with, augment the kernel's own firmware-loading class so that as well as loading firmware from userspace, it can also load one of a set of firmwares which were built in to the kernel image.
nottingdwmw2: +1
f13lxo: what we do when that happens is we work with upstream to get to a point where we're in harmony.
notting(to 'upstream first')
dwmw2lxo: then, convert all users of firmware blobs to the firmware class, completely isolated from complaints of regressions because people have to use initrd,, etc.
c4chrisdwmw2: +1
nottingf13: and then a coca-cola commercial!
dwmw2then, we can move the blobs to a separate tarball or something. People still have the _option_ of building them into their kernel
spotnotting: with polar bears?
dwmw2but Fedora, which uses an initrd everywhere, would not need to
caillonlxo, then we change upstream's goals.  it wouldn't be the first time we need to convince upstream.  but we do it using sane arguments, not just complain.
nottingspot: in tunisia
dwmw2problem solves, and people can still boot monolithic kernels on their machines which need SCSI controller firmware
cebbertobviously the commercial should have penguins
jeremylxo: and rather than a package full of conflicts, you could easily write a yum plugin which checked the license of packages being installed and give a loud warning if suitable
lxodo you honestly foresee a say linux-2.6.39.tar.bz2 without any such non-Free firmware if someone follows your suggested plan?
f13lxo: yes.
lxoI seriously don't.  people will complain because they now have to go fetch the firmware from some other tarball
jeremy, this is not about the license
f13lxo: then you might as well pack up and go home.
nottingjeremy: lxo: well, if you're doing a spin, just Don't Include those packages. don't worry about conflicts/plugins
caillonlxo, we do have a lot of sway with upstream kernel given how much we contribute to it.  and i really think we can get a patch upstream if done right.  if you don't want to do it right, that's your prerogative.  we don't want to take it if it's not done right.
lxoplease don't conflate license with having your freedoms respected.  these are related, but quite distinct issues
dwmw2lxo: if we get to stage 2 of my 3 stages, and it's just the tarball, then I would support Fedora splitting that out.
cebbertwho get to handle all the bug reports against the kernel after the package gets split out?
dwmw2cebbert: pjones. It's a mkinitrd thing
lxodwmw2, but that's what I do now!  why should I put in weeks of work and discussion and tolerance to verbal abuse just to get back where I am now?
jeremynotting: the conflicts or plugin would then let you add more software later and not worry about getting things that don't meet your criteria
cebbertI'm sure he'd just love htat
dwmw2lxo: no, you do something different now.
f13lxo: you don't split it out in a way that is sane and easy for those that wish to opt back into the firmware
lxo: and you don't do it in the existing kernel package.
dwmw2the difference is that people would be able to just drop in the appropriate blobs if they need them (and Fedora would ship them in the default spins)
f13we're not going down the route of having two kernel srpms again.  That was a huge mistake, we wont' do it again.
lxonotting, this is not just about spins.  this is about user choosing "I don't want non-Free stuff from Fedora installed on my machine".
lxo"if any updates attempt to bring it in, stop right there"
dwmw2cebbert: they'd be in the default install; the only time it would matter is when it's needed for the boot device. So we'd need firmware loading in initrd -- but don't we have that already?
nottingwow, it's the GPL-is-infectious argument in reverse
lxoGPL?  who's talking about GPL?
cebbertlxo, and if your system crashes because you don't have the latest Intel CPU firmware you get to replace the processor
dgilmoredwmw2: we have it.  i have a box that has fiber channel storage as the primary storage.  upstream kernel removed its firmware  and now it gets loaded by initrd
* spot wonders if this is productive.
dwmw2dgilmore: right.
nottinglxo: you're using the standard corporate 'if any GPL software touches me, I'm infected' in reverse against non-free software
dwmw2and that's the way forward
lxocebbert, so do *you* get to decide the user must not be able to choose that?
cebbertdwmw2, we're still going to get bug reports from people who don't have the latest firmware and think the kernel is at fault
dwmw2cebbert: the in-kernel firmware almost never changes, I thought?
cebbertlxo, I just don't want a pile of bug reports from people who choose to go that route
lxodwmw2, that's mostly correct
dwmw2and we can put Conflicts: into the kernel package to make it dislike earlier firmwares
spotProposal on the floor is "We'd love this feature, but it needs to go upstream first and not involve an alternative kernel package." ... do we have enough votes for it to pass?
nottingspot: yes, seven
lxobnx2x firmware and nouveau voodoos are changing quite constantly
f13spot: +1
nirik+1 on the proposal on the floor
dwmw2jeremy gave it 100. Isn't that enough?
tibbsspot: +1
lxo(and there's no copyright notice covering the voodoos, or permission to distribute them, BTW; something to look into)
* jeremy reiterates his +100
dwmw2lxo: they're a clear GPL violation as far as I can tell. But that's a different issue :)
lxoso, no FedoraFreedom, is that what you're deciding?
dwmw2lxo: no. It's not.
f13lxo: stop being a drama queen.
lxoor are you just ganging up against one particular implementation detail?
bpeppleok, so I count nine "+1", to spot's proposal.
abadger1999lxo: "´╗┐ it needs to go upstream first"
f13lxo: we're deciding that we want our Freedom done right.
spotlxo: its not the spirit, its the implementation.
dwmw2lxo: we're saying _yes_, we want this feature. But done right.
niriklxo: no, we are saying we would love to have it... go do it the right way.
lxoah, sorry, I had missed spot's proposal
I apologize
too many things going on at once
mea culpa
bpepplelxo: no worries.
caillonspot, +1 to that proposal
lxoso...  designing a backup plan
dwmw2lxo: is there anything unclear about the plan I outlined?
lxowhat if upstream refuses to take changes as proposed by dwmw2?
spotlxo: we can revisit it if/when that occurs.
dwmw2we promote an attitude of violence towards them
caillonlxo, let's cross that bridge if it occurs
dgilmoredwmw2: we never do that.
lxoso, backup plan is wait and see
niriklxo: you might pass your changes by dwmw2/alanr/other fedora kernel folks before posting upstream?
lxoyou know...  we could have a backup plan right now
nottingnirik: alanc?
niriknotting: right, sorry...
lxosay, if upstream kernel doesn't take it, we go ahead with the changes anyhow
nottinglxo: you have the persistence of a 5-year old who wants to go to the swimming pool
* nirik points to the cart, and the horse, and the order they are in.
caillonlxo, i believe it's a good feature.  you believe it's a good feature.  i think we all agree it's a good feature.  i believe upstream will agree too (though i can't speak for them).  so i see no reason to expect upstream to not take the feature based on the feature itself.
lxo, thus, the only reason i can see them rejecting it for is implementation.
dwmw2lxo: I can't see _any_ problem with parts 1 and 2 of my plan. And as I said, I'd support Fedora doing part 3 on its own
f13and I see no reason to get worked up and spend offert on a fictional backup plan.
lxocaillon, that's where we differ.  I find it extremely unlikely that upstream will go for it.  and I have the scars to explain why :-)
f13it's not worth FESCos time.  We've decided, MOVE ON>
dwmw2caillon: that or the possibility that people refuse to post patches in 'diff -up' form :)
nottingdwmw2: of course you can't see any problems, you proposed it ;)
spotbpepple: i think there is not much left of this horse.
lxoit's not just a matter of rejecting the implementation
dwmw2notting: dude, I propose kernel code all the time that I see problems with :)
f13lxo: perhaps it wasn't the idea that upstream shot down, but the way in which it was presented.
lxoit's a matter of sacrificing a bit of convenience out of respect for users' freedom
bpepplespot: I agree.  we should probably move on.....
caillondwmw2, heh
lxothat's just not something in LKML's radar
dwmw2lxo: when you post the first patch of the 3, I don't want to see _any_ mention of freedom in it
f13bpepple: what's our next topic?
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
dwmw2that goes for the second patch, too.
that'll help
lxoI'm not going to post it
I'm going to send the ed diff to you
bpepplef13: there's nothing else on the agenda for today.
lxoas you proposed
dwmw2heh, ok :)
nottingwell, the ed diff requires #1 and #2 to be there first. so is *anyone* actually going to do that work?
bpeppleanything else folks want to discuss before wrapping up the meeting?
lxoand I'll do that if I manage to convince myself that this will indeed advance the cause of freedom, and that this is more important to do than my other activities in this regard
jeremyanyone with comments on the feature process and improvements for f10 should send them to poelcat
cebbertcould we get a "freddom" spin to pass some parameter to the kernel that indicates it's opted out of firmware loading?
lxonotting, what does 'being there' have to do with anything?  I do have these files, of course.  I clean them up, after all.
poelcatjeremy: or better add them to the wiki page
nottinglxo: #3 is not acceptable as is without the framework of  #1 and #2 to make it *usable*
lxoI object to promoting the use of the stuff that's in there, to distributing it.
jeremypoelcat: indeed!
* poelcat is lurking in airport mode
nottingpoelcat: jeremy: along those lines
bpeppleok, I don't see anyone speaking up, so I think we can wrap it up for this week.
* bpepple will end the meeting in 60
nottingi wonder if rather than handling F10 stuff in FESCo, board, releng multiple times a week, if there should be a standing Fedora 10 meeting
with some subset of all those groups
and perhaps feature approval goes there
poelcatnotting:  like a "project meeting" ?
lxocebbert, freedom spin built out of sources that contain non-Free doesn't make much sense to me.  it fails the goal
jeremynotting: definitely worth at the very least thinking about
nottingpoelcat: something like that
maybe i should send something to the list
bpepplenotting: might be worthwhile.  since we don't tend to get to anything else when feature time comes around.
dgilmorenotting: with someone responsible for the whole release.  that will see it through to EOL
poelcatnotting: i'd be willing to consider leading it if that would help.. maybe along the lines of our release readiness meetings
nottingat a minimum you'd want representation from rel-eng, board, fesco, all spin-producing SIGs/teams, QA, docs...
poelcatcould even meet less than every week if there are not a lot of topics
nottingbut i suppose there would be overlap (who approves schedules, who approves features, what does fesco do then, etc.)
* nirik suspects if you get too many people it's going to take even longer than when fesco was discussing them.
bpeppletruthfully, I'd like to restart the discussion on the responsibilities for FESCo again now that F9 is out the door.
poelcatwe've found that to wokrk well internally
nirik: right.. the rr meetings were one rep from each group
nirikbpepple: agreed. I think we should look at doing more proactive things rather than just sitting around.
jeremybpepple: it's probably worthwhile ot try to figure that out before we elect ourselves...
warrenjeremy: +1
bpepplejeremy: agreed.
maybe at next week's meeting we could work on that.
nirikbpepple: sounds like a good plan to me.
tibbsThe problem with being proactive is that you need the ability to direct others to do things.
poelcatnirik: and we did them on the phone which made them much more efficient
tibbsIn a volunteer project it's tough to do anything other than ask people to do things.
* poelcat has to run
nottingok, so table the 'Fedora 10 group meeting' plan until after next week when we discuss a better idea of what fesco is doing
bpepplenotting: sounds like a plan to me.
notting(this idea came out of the multiple-postpartum-meetings for fedora 9)
f13I do really like the idea of an Asterisk based "F10" meeting every couple weeks or every week.
that could conveniently coincide with release readyness meetings
nottingf13: is asterisk ready yet?
f13(IE be one in the same)
notting: I think it's usable for smaller sets of folks who can get their equipment in working order
bpepplef13: I'm not really a fan of conference call meetings, since there is no record for the rest of the project (which is my #1 beef with the Board).
f13especially if we ask infrastricture nicely to make that happen for us
niriktibbs: agreed... but one resource we have is the fesco members. We can tell ourselves what to do... ie, mentor features, etc.
* nirik also hates phones. ;)
f13bpepple: yeah, that does suck, but voice is just such a higher bandwidth :/
f13notting: failing asterisk, we can do things with global meet
nirikfudcon might also be a good time to have a 'what should fesco do' session.
nottingnirik: is that post-election?
bpepplenirik: unfortunately, it's after the election/
tibbsnirik: To some degree, but I don't think the committee is useful if the committee members have to do all the work themselves.
f13bpepple: anything done on the phone absolutely needs to have a notes / minutes taker
tibbsAnyway, time to run.
nirikyeah, true... bad for election timing. ;(
* warren looks at the nomination page
bpepplef13: yeah, but there's always parts of the conversation that is lost in translation.
warrenperhaps the election for fesco makes a lot more sense after we DEFINE it
meaning, we should delay the election
nottingunless we can define it beforehand :)
dgilmorebpepple: we are working on making sure conference calls are recorded on our asterisk setup
warrenhttp://fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations  we don't have enough people to even hold an election on this page
cebbertlxo: all I want is a flag passed to the kernel that tells me I can ignore a bug report because there's no firmware available
bpeppledgilmore: that would be good.
warrenwe have 2 people running plus one contingent
bpepplewarren: I expect most people will sign-up about a week before the election, just like has happened in the past.
nirikdgilmore: good, but still not as nice as a transcript... perhaps we could get some folks willing to listen and transcribe...
warren(Foo Bar isn't eligible due to the felony convictions.)
bpepplewarren: ;)
* nirik still hasn't decided if he will run again or not...
nottingcebbert: heh
bpepplenirik: I haven't either.  Figure I'll make the decision next week.
nirikyeah, me too...
warrenperhaps this is an important sign?
dgilmorenirik: we are also working on making sure that it can be streamed live
warrenthat we need to define fesco before electing it
nirikdgilmore: cool.
warrenpeople don't know if they want to run if it isn't defined
nirikdgilmore: I should try again to get my bluetooth headset working.
warren: yeah, agreed...
dgilmorenirik: i keep meaning to buy a bluetooth headset
bpepplewarren: hopefully at next week's meeting we'll be able to do that.
warrenso we either define fesco before the deadline or we delay the election
nirikdgilmore: I have a pile of them... can bring you one at fudcon if you want. :)
dgilmorenirik: :) would be cool
bpeppleok, we're at the hour, so I should probably call time of death.
* bpepple will end the meeting in 60
bpepple will end the meeting in 30
bpepple will end the meeting in 15
bpepple-- MARK -- Meeting End
Thanks, everyone!

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