--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
Hi everybody; who's around?
* tibbs here
notting is here
jwb is here
centosian is lurking
warren here
poelcat here
dgilmore is present and accounted for
* nirik is here.
bpeppleok, we probably get started....
--- bpepple has changed the topic to: MISC - Proposal Template: http://fedoraproject.org/wiki/JesseKeating/FESCoProposalTemplateDraft - f13
nottingwhoa. meta.
tibbsI was going to use this, but then I realized that I don't actually understand what "Problem Space" and "Scope" mean in context.
dgilmorebpepple: that looks useful
tibbsI'm not really good with the newspeak.
f13bpepple: here.
bpepplef13: we're just looking at your template so far.
f13tibbs: problem space is "what problem are you seeking to solve"
dgilmoretibbs: whats your problem.  and what is it going to effect
f13tibbs: "scope" is "what all things will this proposal touch on and change"
caillontibbs, see the "Active Ingredients" section
tibbs"## Describe the scope of what all things will be effected by the proposal"
f13I'd love to see suggestions for clearer text in teh comments.
* c4chris here now -- Hi folks
tibbsI guess I'm just dumb, that that doesn't mean all that much to me.  Sorry.
nirikhow about adding 'Owner(s)' ? someone who is managing and pushing the proposal?
caillontibbs, it might make more sense if you s/the scope of//
f13nirik: good suggestion!
nottingf13: *cough* affected
* jeremy wonders if we're getting too tied up in our own bureaucracy
f13notting: I always get that wrong.
jeremy: I'm not trying to add more bureaucracy. Using the template is optional.
caillontibbs, which is more clear i suppose (after you get past the "what all" ;-)
bpepplejeremy: I don't think we're going to force anyone to use this, but we would prefer them to.
f13I'm just trying to provide an accepted template that folks cna use if they wish when bringing proposals to FESCo.  It helps me personally with my proposals, I think it can help others.
bpepplef13: +1, I'm all for this.
f13tibbs: I'll gladly replace the text with something that makes sense to you
tibbsI like the idea of a template.  It's just that I think some corporate people have seen that terminology before but I'm a lowly academic.
nirikI'm fine with it being suggested, but not required. Not sure fesco needs to take any action other than say 'use this if you like'?
* dwmw2_BOS appears
jeremy isn't against it, just thinks that something for us all to think about over the next little bit is what role we want fesco filling
f13tibbs: so, how about some language that makes sense to you?
tibbsWell, I have a proposal to propose later, so I'll try filling in the gaps and see where it gets me.
c4chrislooks fine to me.  I'd maybe just add one topic like "decision seeked" or something to that effect
f13c4chris: that's near the bottom
bpepplef13: where are you going to put this on the wiki?  Somewhere in the development namespace?
f13bpepple: I'm not really sure.  THe FESCo namespace has some information about how to add topics for discussion right?  It should be linked to there
f13oh, as far as where the /template/ itself goes,
bpepplef13: that sounds good.
* warren has no strong opinion on this.
f13bpepple: yeah, probably somewhere in Development/
f13ok, so I don't think anybody is against it,a nd we can tweak the template as we go.  We can probably move on
bpepplef13: cool.
moving on...
--- bpepple has changed the topic to: MISC - http://fedoraproject.org/wiki/JesseKeating/AwolRenameProposal - f13
f13This should be pretty straight forward, just a s/AWOL/MIA/
tibbsFine by me.
bpepple+1.  I don't have any problem with that.
nirikMIA is still not ideal, but I can't think of anything better. ;) +1
notting+1. awaiting POW/MIA packager bumperstickers
f13nirik: how makes you feel that MIA isn't ideal?
jeremysure.  +1
caillondoes it have to be an acronym?
non-responsive is the most accurate term, really.
nirikstill sounds miltary.. who are we at war with? Should we be sending a rescue team to look for our MIA packagers?
caillon(which I pointed out on a mailing list somewhere a while ago)
* jeremy likes non-responsive too
warrennirik, we never leave anyone behind.  Except when we do.
f13*shrug* I can easily call it 'non-responsive'
warrenI think I prefer MIA
f13anbody opposed to that term instead of AWOL/MIA?
dwmw2_BOSI think AWOL is easier
I don't really care though
warrendoes AWOL make sense to non-americans?
cailloni don't want to imply that our contributors need to request leave before going absent
caillonbecause that's not the case
c4chriswarren: no
f13right, AWOL is hostile
* dgilmore has no strong opinion
dwmw2_BOScaillon: one would have to be rather... strange.. to make that inference
f13MIA isn't, but apparently still rubs people the wrong way?
* bpepple doesn't really have a strong opinion either.
f13dwmw2_BOS: AWOL stands for Absence Without Leave...
dwmw2_BOSI think we're being silly
smoogeI think any phrase is going to rub some people wrong
dwmw2_BOSf13: I know what it stands for
sm|CPU SmootherFrOgZ smooge
tibbsDo we have any examples of anyone who was actually offended by the current wording?
SmootherFrOgZ smooge
* nirik doesn't care that strongly either... MIA is not ideal, but ok, non-responsive is fine.
bpepplesmooge: agreed.
tibbsIf so, what would they find non-offensive?
warrenAWOL implies that they did something wrong.  MIA doesn't imply anything.
f13tibbs: there were complaints on mailing lists, which led me to doing this proposal.
dwmw2_BOStibbs: and can we take them out back and shoot them, thus solving the problem? :)
f13: got references?
f13dwmw2_BOS: not handy
smoogeI think MIA is better than AWOL. War Prisoner might be a third term
f13ok, this is getting silly
bpepplef13: agreed.
warren+1 MIA
f13does anybody feel strongly about MIA vs non-responsive?
tibbsI'm so difficult to offend that I can't tell what would be offensive.
bpepplef13: no
dwmw2_BOSI'm offended by the idea that we might need to change it just because some people are being stupid
* caillon would much prefer non-responsive, but i'm not even sure why we're voting on these things, to begin with :)
dwmw2_BOSLet's stick to AWOL
smoogedwmw2_BOS, when aren't you offended :)
f13caillon: to avoid revert wars?
jeremycaillon: indeed
f13tell ya what, I'll just change it and ya'll can deal with it.
caillonf13, i meant to imply this doesn't strike me as something that *fesco* should be dealing with ;)
dwmw2_BOSsmooge: good point
tibbsThe thing is, AWOL does have a defined meaning, as does MIA.  Do either of those actually match with what we want to say?
smoogedwmw2_BOS, No offense meant of course :P
MIA matches what we are trying to say
nirikMissing in action is a status assigned to a member of the armed services who is reported missing following combat and may be injured, captured, or dead.
f13nirik: it's applied to a lot more than the armed service
but that's likely the origination
abadger1999Neither are perfect matches.  I like non-responsive much better from that standpoint.
* caillon votes to send this to our PR SIG
f13fine, non-responsive it is.  Next?
bpeppleagreed.  moving on....
--- bpepple has changed the topic to: MISC - Automated MIA Proposal - http://fedoraproject.org/wiki/JesseKeating/AutomatedMIAProposal - f13
tibbsSure, non-responsive +1.  And if we really have a PR SIG, by all means give it to them.
f13this proposal has a bit more meat.
caillontibbs, heh
note to whoever's reading the minutes: start a PR SIG! :-)
* smooge puts on the list
dwmw2_BOSI don't like MIA. The whole point is that there's _no_ action
missing in inaction?
warrenisn't that the purpose of fedora marketing?
f13dwmw2_BOS: They were in action at some point, they brought a package to Fedora.
dwmw2_BOS: now they're missing.
tibbsRE Automated*Proposal, I like it but do we have buy-in from the bugzilla admins since that runs into Red Hat territory?
f13dwmw2_BOS: but we've moved on from that topic.
nirikI think the automated thing sounds great at this high level. We may need to adjust/provide feedback on specific things, but if people are willing to work on it, I say +1.
f13tibbs: I haven't talked specifically with them, but so long as we're using the api provided and not inventing new bugzilla things we should be OK.
nirikalso, I think the comment from the list is good that it should always take a human at the end looking over things before it orphans/removes maintainer...
f13nirik: I personally think that just gums up the works.
caillonf13, the only concern i have is that people shouldn't have to keep emailing someone with "i'm not dead yet".  fixing bugs and rebuilding packages should be sufficient.
tibbsI thougyht there was something about keywords or flags.  Keywords, I guess, are unstructured and we can make them up, but flags require someone to program something, don't they?
f13caillon: automation doesn't require responding to a mail.
caillon: it requires commenting on a bug.
an already open bug for a specific reason.
caillonany bug?  or a specific bug
f13caillon: specific bugs
caillon: the proposal would only allow a specific class of bugs to be considered for automation
tibbsThings like "your package failed to build in rawhide".
f13caillon: bugs like broken deps, package conflicts, broken upgrade paths, etc...
nirikwell, I suppose it depends on how good the detection is... at least at first it would be good to have a human check it over before it starts marking people gone.
f13the type of bugs where we really do want a response of some kind in a reasonable manner
nirik: I'm ok with a staged deployment
and FESCo would get another opportunity to review/etc.. before anything is turned on
warrensounds good
f13but this proposal will give people something to work from and a goal to get to
bpepple+1 to proposal.
nirikyeah, +1
* poelcat wonders what this will do to the already 13K open bug count
can we cry about the word 'orphan' too, because it implies death?
dwmw2_BOS: it's a hard knock life
bpeppledwmw2_BOS: ;)
ok, I see nine '+1', so the proposal has been approved.
* c4chris passes a hanky to dwmw2_BOS
dwmw2_BOS sneezes into it
dgilmoredwmw2_BOS: it just means your parents dont want you anymore
bpeppleanything else? or should we move on?
dgilmorebpepple: move on
* nirik is reminded of a place that got mad about dns 'slave' servers.
--- bpepple has changed the topic to: FESCO-Meeting -- http://fedoraproject.org/wiki/JasonTibbitts/MergeReviews -- tibbs, nirik
dwmw2_BOSheh. Didn't we have that idiocy about USB too?
We have USB 'gadget' support in the kernel isntead of USB slave :)
f13I +1 their proposal.
bpepple+1 here also.
tibbsI don't pretend that the mandatory set in @base is actually a useful system, but it at least gives us a place to direct our efforts.
jeremytibbs: I think this is a great way to start really making some progress
and to have a defined target, etc
caillonit's a small enough base to not be impossible even
nirikyeah, looks good. FYI, tibbs did the work on this... I slacked. ;) I can start doing some of the reviews tho. ;)
tibbsI will go through the 15, double check the flags and ping if necessary.
+1 even
tibbsThen should I post the final list of ungrabbed reviews to fedora-devel?  Or indicate this by a keyword or something?
nirikI would think post would be good...and/or use the wiki page list...
bpeppletibbs: I think posting to the -devel list is a good idea.
jeremytibbs: I'd just post a list  (or post a link to the page)
c4chrisI think a post would be good
caillontibbs, add to F9Blocker/Target?
(how badly do we want these reviewed for F9)
tibbsI will also gather links to all of those reviews so you don't have to search for them.
Finally, I can keep a list updated and post it periodically if folks would like that.
* jeremy is okay with sticking on F9Blocker for now. we can always re-evaluate based on the status before the feature freeze
caillonor maybe file a generic "Review these packages for F9" bug so we can just look at the dependency list
bpepplejeremy: +1
caillonand then stick THAT on the blocker list
tibbsAnyone disagree with caillon?
c4chriscaillon: I like this
tibbsSeems reasonable to me.
bpeppleI'm fine with it.
* nirik thinks that sounds great.
dwmw2_BOSmakes snse
nirikfyi, the rpm review is just waiting for license checking. If anyone wants to help on that... ;)
tibbsOK, I'll do that and then post to fedora-devel-list.
bpeppletibbs: anything else on the merge reviews, or should we move on?
tibbsI'm done.
bpeppletibbs: great, thanks.
--- bpepple has changed the topic to: MISC - FESCo meeting schedule over the holidays - all
* nirik personally should be around... so thursdays still work for me.
f13I'm around as well
bpeppleok, we've got meetings scheduled for dec. 27, and jan 3. is that going to work for people?  or do we cancel or reschedule?
warrenas-is, good for me.
c4chris20 - ok; 27 - not sure
* spot won't be around on the 27th.
caillonI'm out dec 27
* notting is probably out for both
tibbsI'm around on the 27th.
jeremyI suspect that skipping the 27th makes sense
f13but I wonder if we have folks that aren't going to be around if we should delay voting on anything non-pressing sot hat we don't have the appearence of "sneaking" something in.
warrenonly meeting I can't make is Jan 3rd
f13, require 7 votes to pass anything?
bpepplehow about we cancel the 27th meeting, and try to keep the one on the 3rd.
c4chrisbpepple: +1
warrenJan 3rd I wont be able to make.
nirikbpepple: +1
f13bpepple: +1
warrenbut if the majority prefers that, then OK>
caillonbpepple, sure
jeremysounds like a good plan.  +1
tibbsEither way is fine with me; I'll be online both days so if someone calls a meeting then I'll be there.
notting+1, sure
bpeppleok, it sounds like the majority is fine with that, so let's plan on cancelling the 27th meeting, and keeping the meeting on jan. 3rd.
warrenlet's move on?
bpeppleok, moving on....
--- bpepple has changed the topic to: FESCo-Meeting -- New Features - http://fedoraproject.org/wiki/Features/Dashboard - poelcat
tibbswarren: If you just want to chat on the 27th, I'm here for you man.
bpepplepoelcat: you want to lead this?
--- poelcat has changed the topic to: Vote to accept http://fedoraproject.org/wiki/Features/VirtAuthentication
f13(I reviewed ahead of time!!)
tibbs"FreeIPA, and ActiveDirectory" but no plain kerberos?
tibbsBut +1 anyway; better kerberos integration is another proposal, I guess.
f13tibbs: I think freeipa provides kerb
jeremytibbs: plain kerberos doesn't have directory functionality... you always have to have kerberos+<something>
* poelcat notes the +1s have it
--- poelcat has changed the topic to: Vote to accept http://fedoraproject.org/wiki/Features/VirtPolicyKit
jeremyfreeipa and activedirectory are both kerberos+ldap.  you could also do nis or hesiod ;)
bpepple+1, seems like a no-brainer.
f13+1 even.
* poelcat notes the +1s have it
--- poelcat has changed the topic to: Vote to accept http://fedoraproject.org/wiki/Releases/FeatureMoreNetworkManager
warrenbefore adding a vote, one question
warrenI see no mention of ifup/ifdown compatibility.  Are we just going to drop that?
There was prior mention of ifup/ifdown compat in the past.
caillonwarren, "more" not "all"
nirikso would this include making NM default on all installs?
Yes, would this be default on all installs?
caillonbut we're not supposed to be shooting down features on whether we like a feature or not.  if its a good marketing thing, we should be accepting it, AIUI.
nirikI guess it depends on how far it gets...
yeah, so +1...
warrencaillon, I don't plan to shoot it down, was just asking for clarification.
caillonwarren, ah.  i'd ask dcbw after the meeting
* poelcat notes the +1s have it
--- poelcat has changed the topic to: Vote to accept http://fedoraproject.org/wiki/Features/K12Linux
caillonisn't the board supposed to be approving spins?
dgilmorecaillon: its not a spin
f13I didn't think this was a spin
what are we talking about?
f13just an effort to improve some Fedora infrastructure so that it can be used in K12LTSP scenarios easier.
caillonf13, the first thing in "contents" makes me believe otherwise :)
nirikyeah, I see no spin mentions.
tibbswarren: Did all of the reviews pass?  I saw that some of them were problematic.
warrenpjones, you are a fucking ass.
tibbs, none of the new packages were submitted yet
dgilmorewarren: thats really inappropriate in a meeting
warrentibbs, the existing packages sititng there are being thrown out
dgilmore, I'm sorry.
nirikso again, I think this is good and we will see how far the feature gets... +1
warrenThe feature request is not about the spin, but rather the feature itself.
dgilmore+1 from me
spotdoes this require a mkinitrd rewrite?
warrenThe spin comes later if the feature pans out.
spot, no.
pjonesspot: not a rewrite, but significant changes.
f13+1 from me, I'd like things to work better for the LTSP folks.
warrenspot, I implemented a few patches for mkinitrd that are necessary
f13it'll make my Linux Fest Northwest event a lot more fun
warrenpjones, did you even review what I asked you to look at?  they are not significant at all.
tibbswarren: So that bash-initrd work you were doing is orthogonal?
warrentibbs, yes
tibbsCool.  Just trying to untangle everything in my head.
warrentibbs, I backported the network boot features to minimal patches for upstream
pjoneswarren: I was under the impression, since you told me so, that you'd need more changes than just what you'd sent me so far?
warrenpjones, that's the minimum to get it to work.
pjones, git clone http://fedorapeople.org/~wtogami/mkinitrd-upstream-proposed/
tibbs+1 in any case, although I'd advise those new package review requests to get in soon.
warrentibbs, that's the plan, likely to submit before Christmas
pjones(btw, my -1 up above was entirely a joke)
warrentibbs, spent most of the past 2 months unfscking upstream
caillon+1 i guess
poelcatis that 7 +1s ?
caillonpjones, oh bah, you're changing your vote?  i only voted +1 since you were voting -1  :p
* pjones falls over laughing
warrenpjones, I would really appreciate it if you could review the proposed changes for upstream, they are a lot less invasive than bash-branch and heavily tested.
bpepplepoelcat: yeah, I see eight '+1'
nirikpoelcat: 8 looks like.
pjonesI'm +1 on the idea.
bpepplepoelcat: anything else? or should we move on?
warrenmove on
poelcatThat is it for features today... http://fedoraproject.org/wiki/Features/Dashboard contains some others not quite ready
bpepplepoelcat: great, thanks.
nirikthanks poelcat
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
caillonwho's going to fudcon?
bpeppleok, anything else people wish to discuss before wrapping it for today?
tibbsI had something...
* nirik hopes to... is the hotel code finalized yet?
f13caillon: I'm there.
tibbsWhile working on the minimal package set, I noticed that @base and @core aren't really well defined any more.
pjonescaillon: not determined yet, budget for travel is on paulc's desk.
caillonnirik, i know we have rates, not sure about the code
bpepplecaillon: unlikely.
* caillon will try to be there via TV
nirikyeah, my work wants all the hotel info before they book anything... ;(
tibbsWhat I'm thinking of doing is coming up with one minimal package group; the mandatory packages are the absolute minimum required to boot a system, and the default packages are just enough to download and install packages.
c4christibbs: that would be good I think
warrennirik, talk to spevack
niriktibbs: sounds great, but might need some poking to get the set not to be huge... I am sure there are still some nasty dependencies and pull in too much still.
tibbsWell, @base is pretty small (114 packages + kernel)
jeremytibbs: @core should be enough to get to a login prompt (and there's not much "fat" there...  I've been doing a lot of @core live cds)
tibbsBut @base and @core have almost exactly the same package footprint.
jeremytibbs: @base should add bits to be a little bit more .. umm... useful
f13tibbs: I like hte idea.  Merging the two into one group and making it less confusing would be nice
jeremy: the reality of @core depsolved and @base depsolved results in not that much difference.
or so it seemed from conversations with tibbs
jeremytibbs: I'll have to try an @base in a little bit... but there was a substantial different the last time I looked
(eg, you actually have things like dhclient in @base :)
and yum
f13anywho, is it really necessary to have two groups for that though?
instead of mandatory / default split?
I suppose it is if you want to just hide one group and it's always selected
and also, there are plenty of docs, etc that refer to the current way
f13does kickstart /always/ select @core though?
tibbsNo, it always selects @base unless you do %packages --baseonly.
c4chrisdunno, but it looks different to me to 'just boot' and to 'get an environment wheer you can download more packages and do stuff'
tibbsSorry, %packages --nobase
f13which seems odd to me.
jeremy@core always gets selected
@base gets selected unless you do --nobase
f13I bet I don't handle that right in pungi
jeremy(because of hystorical reasons)
tibbsThat would explain my confusion; I'm just working from what pungi gathers.
At the very least there's a need to document and rationalize this.
f13jeremy: that's an anacondaism outside of pykickstart isn't it?
jeremyf13: yes
* f13 files pungi ticket.
poelcatRE: feature pages on the wiki... would there be any objections to moving all F9 pages to the wiki/Features namespace (if they aren't there already)
to keep thing tidy and organized
c4chrispoelcat: fine
* poelcat wasn't sure how much visibility something like this needed
caillon didn't know that fesco controlled the wiki
cailloni dont care really, though
bpeppleanything else? or should we wrap it up for today?
caillonbpepple, <badpun> let's make like a gift and wrap it up </badpun>
bpepplecaillon: ;)
* 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!
nirikthanks bpepple
c4christhanks bpepple

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