--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
nirikbpepple: you want to kick/ban bugbot at least for the meeting?
bpepplenirik: yeah, that would be great.
themayorwow the bit is buggin out
nirikbpepple: you have to, I am not on the access list here. ;)
bpeppleah, ok.
--- #fedora-meeting :You need to be a channel operator to do that
nirikit's you, spot and gregdk only.
bpepplenirik: you remember the command to get channel op access?
nirikbpepple: /msg chanserv op #fedora-meeting bpepple
bpepplenirik: cool, thanks.
>chanserv< op #fedora-meeting bpepple
--- ChanServ gives channel operator status to bpepple
nirikyou might have to ban it too, not sure if it auto rejoins on kicks or not.
bpeppleFESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod
Hi everybody; who's around?
niriklooks like it doesn't. ;)
* nirik is here.
sharkczhi, /me here
--- bpepple sets ban on *!*n=supybot@*.bugzilla.org
* notting is here
* bpepple waits another couple of minutes to see if we get a majority of FESCo to show up.
* j-rod here
* dgilmore is here
j-rodbpepple: jwb already said he won't make it
j-rodas did dwmw2
bpepplej-rod: yup, so we can probably get started.
.fesco 48
zodbotbpepple: #48 (Control Groups - https://fedoraproject.org/wiki/Features/ControlGroupsTools) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/48
bpepplejwb voted +1 to this online.
nirikso this is the two former features (kernel and userspace) merged?
nottinglooks like it
bpepplenirik: I believe that is correct.
nirikok, looks ok to me, +1
bpepple+1 here also.
nirikIt doesn't look like they have answered notting's questions on the talk page yet tho
lwangnirik, may I ask what the question was?
niriklwang: see https://fedoraproject.org/wiki/Talk:Features/ControlGroups
sharkczjsafrane: see the url ^^^
nottingnirik: i've talked with jan about it... the solution for the moment is to just start the cgroups service before anything else
bpepplecrap, someone's at the door.  could someone take over running the meeting for me until I get back?
nirikah, ok.
bpeppleschedule is here: https://fedorahosted.org/fesco/report/9
nirikbpepple: sure.
bpepplenirik: thanks!
nirikany other votes or questions on this feature?
j-rod+1 for this as well, no questions here
dgilmore-1  i think it needs a more fully formed idea of implementation
j-rodlwang: see, easy, huh? ;)
* nirik also wonders who is supposed to be doing the minutes/summary for this meeting.
j-rodoh, wait... :)
sharkczit's my round for summary
niriksharkcz: thanks.
lwangdgilmore, which part of the implementation you are concering about?
dgilmorelwang: lokos like there is lots of manual munging of things
lwang: it should be more centralised
lwangdgilmore, you mean centralized mgt interfaces for different types of controller?
jsafranedgilmore: that's just the first step, centalisation is one of the next steps
* notting is +1 - it's not the cleanest interface, but it's also not clear if there's a way to make it cleaner
dgilmoreat the very least id like notting's questions answered
nirikdgilmore: sounds like they were, just in person, not on the wiki page.
dgilmorenirik: which means they were not answered
nirikperhaps the feature owner(s) could update the wiki page with their answers?
jsafranewe'll do
nirikin any case I see 5 +1's and 1 -1, so that means the feature is approved (unless I miscounted)
sorry, 6 +1s and 1 -1.
shall we move on?
nirik.fesco 69
zodbotnirik: #69 (Review FPC Guidelines - http://tinyurl.com/dlvxqh) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/69
nirikany objections to the FPC guidelines... there are a bunch of them, so we could take them one at a time, or just look at ones where anyone has an objection.
https://www.redhat.com/archives/fedora-devel-list/2009-February/msg01273.html is the real link with the list.
we had objections to https://fedoraproject.org/wiki/PackagingDrafts/Non-obvious_spec_file_items before, does this address those?
nottingthat's a lot of stuff
nottingthe global/define one doesn't read very clearly to me
j-rodProvides/Obsoletes is often pretty Obvious to me...
nottingnirik: is anyone from the PC volunteering to clean up icon cache scriptlets across the distro? :)
nirikI don't know. ;)
it would be nice to change them all before the mass rebuild of course...
nottingnirik: for non-obvious, i think provides/obsoletes can be obvious, and not using %configure/make install should be obvious when the package isn't autoconfed
* j-rod still going through pages one-by-one...
niriknotting: yeah, the problem with a list is that there are always exceptions either way.
nottingand i still feel explicit requires should be worded 'must not contain explicit Requires: on libraries'
* bpepple makes it back.
bpeppleis abadger1999 about?
nirikor perhaps tibbs|h could chime in?
* jds2001 here at SCaLE though
j-rodagree w/notting on the explicit requires and on provides/obsoletes. and not using %configure/make install in many cases.
nottingi'm +1 to PHP, epoch, icon cache, duplicate files, haskell, symlinks. +1 to non-obvious spec file items, with the caveat that you're probably be going to rely on the maintainer's definition of obvious
* nirik doesn't have a problem with any of them really. The non obvious one falls prey to having a list, but it's a SHOULD item, so it's not a big deal I don't think...
nirikperhaps it should get a 'could' added in there.
* bpepple doesn't have any objections.
dgilmoreno objections here
nirikSome examples of non-obvious items could include (but are not limited to):
jds2001yeah, +1 to all of them.
notting-1 to ExplicitRequires w/o the 'library' provision
* jds2001 doesnt see anything called that up for voting
sharkczwe should start with them sequentially, otherwise we will be lost in the voting
j-rod+1 to everything but ExplicitRequires as-is, and with the caveat that "non-obvious" is up to maintainer discretion
* warren wonders where are details of library provision
bpeppleok, so it sounds like we've no objections to the proposals, except for the ExplicitRequires proposal.
is that correct?
j-rodand minor issues w/the "non-obvious" stuff
bpepplecould someone put our objections on the discussion pages for those proposals?
nottingwarren: basically just reword it to 'should not have explicit Requires on libraries'
niriknotting: whats the library provision again?
nottingbpepple: sure, will do
bpepplenotting: great, thanks!
jds2001i didnt see explicitrequires
nirikso are we passing all except Explicitrequires then?
bpepplenirik: correct.
nirikjds2001: https://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires
bpepplealright, if there is nothing else we can probably move on.
sharkcz+1 to all
jds2001nirik: got it - i talked with abadger1999 about this awhile back.
it's pretty much Use Common Sense(TM) is what FPC wanted.
nottingbpepple: added.
bpepplenotting: thanks!
alright, back to features then....
nirikit's hard to legislate common sense sometimes. ;(
bpepple.fesco 55
zodbotbpepple: #55 (Power management - https://fedoraproject.org/wiki/Features/PowerManagement) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/55
* bpepple notes jwb voted +1 to this feature online.
* abadger1999 is sorry. Here now if needed
nottingfor some reason i thought we already approved this
bpeppleabadger1999: you want to look at this: https://fedoraproject.org/wiki/Talk:PackagingDrafts/ExplicitRequires
nirikI like the idea, but I don't think we should be asking people to do a list of things... it should all be sane/best defaults we can.
bpepplenotting: did we?  truthfully, I thought we had deferred it, but I could be wrong.
notting: I think your correct, since the feature has been tagged as accepted.
dgilmorenotting: the feature page indicated its been approved
jds2001yeah, I could have failed there.
bpeppleok, let's move onto the next feature then.
nirikyeah, we approved it.
j-roddidn't we say "approved, but please make most of these things Just Work"
bpepple.fesco 66
zodbotbpepple: #66 (MinimalPlatform - http://fedoraproject.org/wiki/Features/MinimalPlatform) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/66
nottingacpid? seriously?
i would like some more info on how the anaconda option is supposed to be exposed
nirikok, this is the min install back again. ;) it's not an easy thing to do.
is the feature owner here?
abadger1999notting, bpepple: Excellent, I can take that back to FPC to see about adding that.
bpeppleabadger1999: great, thanks!
nirikwrabco: excellent. The problem in the past has always been: one persons min is not anothers... how will you decide whats in this? Or is this only base/core?
* jds2001 defines it as %packages --nobase and yum
jds2001enough to get other stuff.
wrabcoit's core + around 15 packages
j-rodjds2001: likewise
dgilmorethe only sane minimal install would be enough to give bash and yum
nottingwrabco: in that case... should we extend core?
dgilmoreeverythging else would need to be added manually
wrabcosee: 485995
j-rodwrabco: does this tie into anaconda's text-mode default install at all?
wrabcoyes there is a way to extend the core
nirikwrabco: do you see a 'minimal' in anaconda? or how would this be exposed? Do you have buy in from anaconda devs? or would you do the work?
dgilmorejds2001: i define minaimal as %packages bash yum
jds2001dgilmore: that would give you too much stuff :)
wrabcoI think I can ask anacoda developers
jds2001dgilmore: all the lsb stuff and whatnot.
dgilmorei think i minimal install would be a great thing to ship as a kickstart only
jds2001: it doesnt
wrabcothere isn't so much work
j-rodI'm thinking this should be exactly the same thing as what clumens was talking about being installed in text mode w/o a kickstart
dgilmorewrabco: i diasgree with your comment that it doesnt need documentation
jds2001j-rod: +1
dgilmorewrabco: it needs alot of documentation. because the definition of what is a minimal install varies for each person
wrabcodgilmore, I meant that I don't have any other homepage for it
dgilmorej-rod: i disagree. I have alot of machines where text mode is the only install option
dgilmorewrabco: we have a whole wiki
j-roddgilmore: vnc, dude. :)
wrabcodgilmore, as a definition I propose to paste comment #9 from 485995
dgilmorewrabco: thats not a valid excuse
jds2001dgilmore: you mean VNC won't work?
j-roddgilmore: part of the new minimal anaconda text-mode install eliminates package selection entirely, iirc
dgilmorejds2001: i never use vnc for install
jds2001we approved last week the minimal install
dgilmorei guess im special and need to deal with it
jds2001dgilmore: doesn't mean you can't :D
j-rodso you either get their pre-defined minimal package set, or you use a kickstart
dgilmorejds2001: i missed that portion i guess because i have no idea what yoru talking about
jds2001yeah, i guess we'd need to see what clumens was thinking for that packages set.
* dgilmore really doesnt like that
dgilmorebut i guess i have to deal with it
wrabcoI don't about clumens work
nirikwell, I guess I like this idea overall, but am not sure if we should approve it without anaconda dev's buyin.
bpeppleok, so are we at a point to vote on this feature?
jds2001yeah, i think the right hand might not be talking to the left here :)
j-rodyeah, I'd say postpone until there's been some discussion w/anaconda folks
jds2001or work in in with the text mode revamp.
bpepplesounds good to me.  anyone object to that?
j-rodgenerally like the idea though
sharkczand don't forger about the thincrust project, they have a minimal install set too
"and it's focused on security"
j-rodyeah, would be nice if all of the minimal install sets could be one in the same...
dgilmorewrabco: i agree with jeremy acpid should not be there
wrabcowhat about VM?
dgilmorewrabco: make it work without it
nottingwhat does libvirt need acpi for? it doesn't Require: it
sgrubbsometimes VM's don't shutdown
dgilmoresgrubb: make it work without it
sgrubbI was told that the solution was to add acpid
dgilmorethats not a solution
niriksounds like a hacky workaround. ;(
sgrubbbut maybe in newer kernels VM's listen better
sgrubbdgilmore, I guess if that is the only objection we can live with it
big difference :)
dgilmorei also disagree with a MDA and audit being there
nottingoh, libvirt implements shutdown by faking the power button?
sgrubbnotting, yes
dgilmorethey should be things that the admin choses
dgilmoreMail Delivery Agent
i.e. postfix
sgrubboh, well you can't get cron out put without it
* nirik notes any minimal set will need someone watching it and fixing when it pulls in too much or grows weird deps...
dgilmorei personally would put postfix on.  but others would choose something else
sharkczyea, like sendmail ;-)
sgrubbwas someone working on a non-network MDA ?
jds2001i thought that there was an MDA that's not also an MTA.
* jds2001 forgets the name.
nirikwe should really get some kind of really dumb local MDA. Or email2rssfeed or something so we don't need that dep
* nirik thinks we are drifting offtopic now tho. ;)
Nirmal nirik
bpepplenirik: agreed.
sgrubbwell, not really
the goal is a working server in the end
no MTA, no cron output
dgilmoresgrubb: thats ok
bpeppleok, so we're going to bump this feature until the anaconda team has a chance to weigh-in.  Is that correct?
sgrubbwe could do without postfix if there was something smaller
dgilmorei think anaconda, releng and QA need to weigh in on this
niriksgrubb: exim might be, but thats debatable.
nottingln -s procmail /usr/sbin/sendmail ;0
(probably won't work *just* like that, but)
wrabcoexim doesn't deliver email to root by default (just a note)
sgrubbok, if we come up with something procmail based are we OK?
* nirik could put his qmail package in for review. ;) har har.
nirikwell, that could possibly solve that issue, depending on how hacky the solution is...
shall we move on?
bpepplewho is going to contact the anaconda team? feature owner or FESCo?
j-rodshould be feature owner, if you ask me...
otherwise, we're playing telephone tag
wrabcoI'll contact them
bpepplej-rod: works for me.  wrabco, that alright with you?
bpepplewrabco: great, thanks!
bpepplealright, moving on....
.fesco 68
zodbotbpepple: #68 (PPC64 as primary - https://fedoraproject.org/wiki/Features/PPC64_as_primary) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/68
nirikis the feature owner here?
bpeppledwmw2 voted -1 to this.
maynardjI submitted the feature
j-rodrel-eng had major objections too
sjmunroethe issue is fedora as a path to RHEL
dgilmoreso this would mean we add another arch
sjmunroeRHEL is all 64-bit hardware
dgilmorewe would need to do a ppc and ppc64 compose
j-rodthe bulk of fedora ppc users are ppc32 still
maynardjsjmunroe is a team member of mine, here to help answer questions
j-rodso yeah, we'd wind up having to do both a ppc32 and ppc64 spin
sjmunroewhat about G5 and PowerStations
niriksjmunroe: sure, but you use 32bit userspace right?
j-rodfor an already niche userbase
sjmunroewe are switching to 64-bit default
nirikwhy? I thought that was bad performance wise and made no sense?
j-rodfor the record, I *have* a powerstation here, and it works quite nicely w/a 64-bit kernel, 32-bit userspace... :)
dgilmoresjmunroe: and they are probably all less than 4gb ram and wouls see significant performance slowdowns  and ram usage increase
j-rodnirik: end-users aren't the brightest things...
dgilmorej-rod: you have to have a 64 bit kernel on 64 bit hardware right?
same as sparc does
j-rodnirik: they want to build 64-bit stuff, and get confuzzled
sjmunroewith -msecure-plt the gap between it only 8%
j-roddgilmore: yes, 64-bit kernel on my powerstation w/32-bit userspace
nirikI think this is a bad idea to cover over a documentation issue.
sjmunroemore then that
hard to build 64-bit apps on fedora
too much missing
dgilmorethis needs full releng/mirror buy in.  since it means we have to add another set of cd/dvd isos
j-rodso we build more 64-bit stuff
dgilmoreas well as qa  who need to test a whole extra arch
nirikwhat 64bit things are missing?
dgilmorej-rod: its all built
j-roddgilmore: I know :)
dgilmorej-rod: its shipped as a side repo
j-rodsorry, should have said "put more 64-bit stuff in the 'ppc' distro tree"
sjmunroetry building a 64-bit mono
dgilmorej-rod: it means at least 10
8 gb on the mirrors
ryanarnalso 64-bit biarch headers support for perl and python are busted.
ryanarnat least last I checked.
nottingyou can't run both arches of perl and python simultaneously, if that's what you mean
but you can certainly build for 64-bit if you point mock at the right repo
ryanarnright, you can't even build a 64-bit app that has python header dependencies if they were '32 bit' generated headers.
well you can build it, but the definitions are wrong for 64-bit.
dgilmorethis  feature would mean that we add a set of iso's http://download.fedora.redhat.com/pub/fedora/linux/development/ppc64/
j-rodhttp://download.fedora.redhat.com/pub/fedora/linux/development/ppc64/os/Packages/ has 64-bit glib and pcre in it
dgilmorehttp://download.fedora.redhat.com/pub/fedora/linux/releases/11/Fedora/  would get an extra arch tree ppc64
im going to vote -1 unless releng, qa and the mirrors all say yes lets do this
dgilmorei really dont see the benefit that fedora users would get
nottingryanarn: the matching headers in the x86 and x86-64 python-devel package are identical - the arch-specific defines are in a separate file
nirikit would also mean multiarch changes? isn't the ppc64 repo only ppc64 now, but would have to grow multiarch ?
nottingnirik: correct
dgilmoreif someone wants a 64 bit mysql or postgres to use more than 4gb ram per process then they can enable the ppc64 repo and install it
notting(back in a couple minutes)
nirikso, mock doesn't work for you ppc64 building?
sharkczand the FE-ExcludeArch-ppc64 tracker bug should contain things that doesn't build on ppc64
dgilmorenirik: i know it does.  thats how we build all the 64 bit packages in the Everything ppc64 tree
* nirik agrees with dgilmore. -1 unless feature owners can get releg/qa/mirrors folks to sign off on all this work.
bpepple-1 to this feature also.
dgilmoresjmunroe: you can always use the fedora tools and make your own spin to test things for RHEL
jds2001-1 here as well.
sharkcz-1 here too
sjmunroebut that will not leverage the community for test?
j-rod-1 here
nottingsjmunroe: no, but given the existing community is 2:1 ppc32...
dgilmoresjmunroe: i think you will find that you will get little to no testing.  since there are far to many losses by making this change.
maynardjso how would we run this past releng/qa/mirrors folks, if we decide to continue to push this?
dgilmoresjmunroe: people will use the 32 bit userland spin not the 64 bit userland spin
maynardj: Jesse Keating already weighed in on the talk page
wwoods: can you please look this over and weigh in also
maynardjhe's releng, right?
dgilmoremaynardj: Jesse keating is
wwoods: is QA
nottingoh, for the record, -1 from me.
dgilmoresjmunroe: you will find your binaries are bigger and slower, lake longer to load and use more ram.  the only time it will make sense is if you are running processes that need to access more than 4gb ram.
nottingi think that's 8 with one abstention.
sjmunroedgilmore, my personal G5 has 8GB
bpepplenotting: correct.
dgilmoresjmunroe: mine has 1gb,
niriksjmunroe: yes, but do you have single applications/processes that use more than 4? the ppc64 kernel should work with all your memory and 32bit userspace yes?
dgilmoresjmunroe: and you run alot of processes needing more than 4gb ram?
bpeppleok, so there were eight '-1', and one abstention, so we've not approved making PPC64 as primary.
niriksjmunroe: what processes just out of curiosity? firefox?
* notting would assume databases, computational things, etc.
sjmunroequadtree analysis of images
my hobby
bpeppleok, anything else folks want to mention regarding this feature, before moving on?
dgilmorelets move on
niriksjmunroe: ok. So you can enable the ppc64 repo and install just the packages you need to do that, and can build the app in mock, right?
* bpepple gets ready to move onto the next topic.
f13fwiw, release engineering has a big -1 on the ppc64 feature.
bpeppleok, moving on then.....
maynardjI presume that since Keating from releng has already voted no, it wouldn't buy us anything to pursue with qa and mirrors folks.
bpepple.fesco 65
f13unless we /only/ did ppc64
zodbotbpepple: #65 (Fedora Creative Commons Content repository) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/65
bpepplemaynardj: I think you would probably need to get rel-eng buy-in first since they would be the folks doing most of the work.
nirikok, so this is a seperate repo of free content packaged for fedora...
nottingon one hand, i like the idea
nirikme first thought is that perhaps this should go to the Board. Is this something fedora wants to get involved in in the long term?
nottingon the other hand, having a bunch of stuff packaged in rpm format and installed at the system level seems sort of strange
jds2001so i'm all for this idea, but is Fedora the right place?
niriksecondly, can we work with/partner with some other thing doing that already?
sharkczsuch content could be shareable between distros, at least rpm based ones
dgilmoreI think we should encourage this. being content that can take advantage of whats in fedora.  one repo should work on all releases
dgilmorecontent that needs things outside of fedora would have to not be allowed in
bpepplein general I like the idea.
sharkczdgilmore: +1
nottingalso, our current package search/browse tools are almost certainly the wrong way to pick through this sort of content, at least for music/image/video
dgilmorebut it probably needs board approval to pursue
I think the overhead of packaging and maintaining content in rpms is probibly not worth it for most content.
bpeppleI'm +1 the idea in general, but I think we probably need some guidelines on packaging and what is acceptable.
jds2001so i talked with spot about this last night
and the precedent is that we already have dive into python in the distro
niriksure, but thats the corner case where it does make some sense. As it's a maintained large document that gets revisions, etc and is of direct interest to fedora users.
j-rodmy particular use case was Linux Device Drivers
nirikon the other side what about a image of someones cat. It won't ever get updated (except in other pictures).
bpepplej-rod: yeah, that suggestion was what sold me on the idea. ;)
j-rodnirik: but an image of someone's cat provides no significant tangible benefit
f13except for screensavers
so on, so forth
nottingreally, it depends on the cat
bpepplenotting: ;)
nirikif it's CC licensed it could go in this repo... right? or what is the deciding question on what could be added?
bpepplenirik: I think that's why we need some kind of guidelines on what's acceptable.
nirikI love the idea of working to make CC/free content easily available to our users. I don't know that packaging them as rpms is the right way for most of it.
* notting stops writing his comment and just +1s nirik
f13from a releng pov I agree
this isn't content specific to Fedora, there really isn't a reason why it should be duplicated in our repos for our users
dgilmorenirik: it may not be.  but certainly its something we should encourage someone/group to come up with a solution
f13when a more globaly usable repository can be setup at the source
* nirik votes to punt to the Board and see if they can answer some of these questions: Can we work with someone else doing this? Should we package them in some neutral format? should we have a fedora repo for this? etc.
wwoods starts reading scrollback
bpepplenirik: yeah, the board might be a better place to make a decision on this, since it's not really a technical issue per se.
abadger1999Maybe asking what the proponents think rpm management of the content will add to the user experience would help?
nirikI think it's a longer term issue as well... we seek the Board's long term vision. ;)
dgilmorenirik: +1  take it to the board
* wwoods has no objection to FESCo's decision to reject PPC64 as a primary arch
sharkczrpm will allow to uninstall the stuff
jds2001+1 punt to the board
sharkcz+1 for taking it to board
j-rod+1 for water-boarding. wait, wrong window...
bpepple+1 here also.
ok, I see six '+1' to escalating this to the Board.
anything else regarding this? otherwise we can move on.
.fesco 47
zodbotbpepple: #47 (Documented QA Team Scope) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/47
bpepplewwoods: you want to lead this one?
bpepplehmm, looks like wwoods stepped away.
wwoodsnah, I'm here
bpeppleah, ok.  you know the specifics about this one?  I'm not really sure what this one is about.
wwoodsjust trying to find my notes on the subject, since that was a couple weeks ago
wwoodsbasically there's some confusion on where QA ends and where other groups begin
I made up a QA charter on the spot
wwoodsand someone suggested it might be best to make sure FESCo etc. know and agree what I've decided by fiat
wwoodsapologies for the delay
meeting summary is here:
"The QA team's purpose is to ensure the quality of the software produced
by the Fedora project, through testing and other appropriate methods."
notting+1 for beer, where applicable.
bpepple+1 here also. ;)
wwoodsthe important thing here, I guess, is that FESCo (and QA) recognize that QA is *not* responsible for deciding the *content* of the distro
dgilmorewwoods: is there a wiki page?
wwoodsthere was some dispute about whether QA should be deciding things like, say, default settings for openssh
nirikagreed, except QA can be consulting about new content that may impact their testing.
i mean, QA should be involved in content as part of the feature process
wwoodswhich is obviously wrong, but the argument *can* be made that "overall quality depends on blah blah blah"
nottingbut not at the theoretical openssh setting level
dgilmorewwoods: id say QA can make recommendations. if there not followed it could be escalated
wwoodsoverly-literal or overly-technical views of "QA"
cause confusion.
bpeppledgilmore: +1
wwoodsright, dgilmore's point is the secondary thing - even though QA isn't responsible for *deciding* what goes and what stays and making policy
wwoodswe should be consulted about bigger changes and allowed to make recommendations
* nirik nods.
dgilmorewwoods: i whole hartedly agree
wwoodsI think we're really just making explicit the implicit arrangement(s) between FESCo and QA and other groups
wwoodsso. I guess the question is: do we agree to the charter as stated
j-rod+1, worksforme
wwoodsand shall we state for the record that it is *not* QA's job to determine the content of the distro
niriksure, +1
wwoodsexcept in an advisory role
wwoods: and yes i agree QA can advise, but should not be expected to determine content
wwoodsright - FESCo should respect the opinion of people representing QA interests, but in the end, FESCo makes the decision
wwoodsI'll send a note to adamw to make sure we get the Official Charter (tm) somewhere in the wiki page(s)
that's all, thanks.
dgilmorewwoods: thanks
bpepplewwoods: great.  anything else regarding QA?
wwoodsnothing off the top of my head - there's a couple QA-driven features but those will come up in the agenda as normal
bpeppleOk.  Thanks for taking the time to lead this.
alright, we're just about out of time for this week, so the last item I think we should table till next week.
anything else folks want to discuss, or should we wrap it up for this week?
kwizartmy item can be discussed next week
bpepplekwizart: yeah, that was the one I pushed back. ;)
ok, let's put a fork in this meeting.
* bpepple will end the meeting in 60
kwizartbut indeed, it would be interesting to be seen , and a general decision to be made... That was the purpose of asking a FESCo decision
* bpepple will end the meeting in 30
bpepple will end the meeting in 15
bpepple-- MARK -- Meeting End

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