| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process | ||
| nirik | bpepple: you want to kick/ban bugbot at least for the meeting? | |
|---|---|---|
| bpepple | nirik: yeah, that would be great. | |
| themayor | wow the bit is buggin out | |
| bot | ||
| nirik | bpepple: you have to, I am not on the access list here. ;) | |
| bpepple | ah, ok. | |
| --- #fedora-meeting :You need to be a channel operator to do that | ||
| nirik | it's you, spot and gregdk only. | |
| bpepple | nirik: you remember the command to get channel op access? | |
| nirik | bpepple: /msg chanserv op #fedora-meeting bpepple | |
| bpepple | nirik: cool, thanks. | |
| >chanserv< op #fedora-meeting bpepple | ||
| --- ChanServ gives channel operator status to bpepple | ||
| nirik | you might have to ban it too, not sure if it auto rejoins on kicks or not. | |
| bpepple | FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod | |
| Hi everybody; who's around? | ||
| nirik | looks like it doesn't. ;) | |
| * nirik is here. | ||
| sharkcz | hi, /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-rod | bpepple: jwb already said he won't make it | |
| j-rod | as did dwmw2 | |
| bpepple | j-rod: yup, so we can probably get started. | |
| .fesco 48 | ||
| zodbot | bpepple: #48 (Control Groups - https://fedoraproject.org/wiki/Features/ControlGroupsTools) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/48 | |
| bpepple | jwb voted +1 to this online. | |
| nirik | so this is the two former features (kernel and userspace) merged? | |
| notting | looks like it | |
| bpepple | nirik: I believe that is correct. | |
| nirik | ok, looks ok to me, +1 | |
| bpepple | +1 here also. | |
| nirik | It doesn't look like they have answered notting's questions on the talk page yet tho | |
| lwang | nirik, may I ask what the question was? | |
| nirik | lwang: see https://fedoraproject.org/wiki/Talk:Features/ControlGroups | |
| sharkcz | jsafrane: see the url ^^^ | |
| notting | nirik: i've talked with jan about it... the solution for the moment is to just start the cgroups service before anything else | |
| bpepple | crap, someone's at the door. could someone take over running the meeting for me until I get back? | |
| nirik | ah, ok. | |
| bpepple | schedule is here: https://fedorahosted.org/fesco/report/9 | |
| nirik | bpepple: sure. | |
| bpepple | nirik: thanks! | |
| nirik | any other votes or questions on this feature? | |
| sharkcz | +1 | |
| j-rod | +1 for this as well, no questions here | |
| dgilmore | -1 i think it needs a more fully formed idea of implementation | |
| j-rod | lwang: see, easy, huh? ;) | |
| * nirik also wonders who is supposed to be doing the minutes/summary for this meeting. | ||
| j-rod | oh, wait... :) | |
| sharkcz | it's my round for summary | |
| nirik | sharkcz: thanks. | |
| lwang | dgilmore, which part of the implementation you are concering about? | |
| dgilmore | lwang: lokos like there is lots of manual munging of things | |
| lwang: it should be more centralised | ||
| lwang | dgilmore, you mean centralized mgt interfaces for different types of controller? | |
| jsafrane | dgilmore: that's just the first step, centalisation is one of the next steps | |
| lwang | *nod* | |
| * notting is +1 - it's not the cleanest interface, but it's also not clear if there's a way to make it cleaner | ||
| dgilmore | at the very least id like notting's questions answered | |
| nirik | dgilmore: sounds like they were, just in person, not on the wiki page. | |
| dgilmore | nirik: which means they were not answered | |
| nirik | perhaps the feature owner(s) could update the wiki page with their answers? | |
| jsafrane | we'll do | |
| nirik | in 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 | |
| zodbot | nirik: #69 (Review FPC Guidelines - http://tinyurl.com/dlvxqh) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/69 | |
| nirik | any 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? | ||
| notting | that's a lot of stuff | |
| nirik | yeah... | |
| notting | the global/define one doesn't read very clearly to me | |
| j-rod | Provides/Obsoletes is often pretty Obvious to me... | |
| notting | nirik: is anyone from the PC volunteering to clean up icon cache scriptlets across the distro? :) | |
| nirik | I don't know. ;) | |
| it would be nice to change them all before the mass rebuild of course... | ||
| notting | nirik: 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... | ||
| nirik | notting: yeah, the problem with a list is that there are always exceptions either way. | |
| notting | and i still feel explicit requires should be worded 'must not contain explicit Requires: on libraries' | |
| * bpepple makes it back. | ||
| bpepple | is abadger1999 about? | |
| nirik | or perhaps tibbs|h could chime in? | |
| * jds2001 here at SCaLE though | ||
| j-rod | agree w/notting on the explicit requires and on provides/obsoletes. and not using %configure/make install in many cases. | |
| notting | i'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... | ||
| nirik | perhaps it should get a 'could' added in there. | |
| * bpepple doesn't have any objections. | ||
| dgilmore | no objections here | |
| nirik | Some examples of non-obvious items could include (but are not limited to): | |
| jds2001 | yeah, +1 to all of them. | |
| notting | -1 to ExplicitRequires w/o the 'library' provision | |
| * jds2001 doesnt see anything called that up for voting | ||
| sharkcz | we 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 | ||
| bpepple | ok, so it sounds like we've no objections to the proposals, except for the ExplicitRequires proposal. | |
| is that correct? | ||
| j-rod | and minor issues w/the "non-obvious" stuff | |
| bpepple | could someone put our objections on the discussion pages for those proposals? | |
| notting | warren: basically just reword it to 'should not have explicit Requires on libraries' | |
| nirik | notting: whats the library provision again? | |
| notting | bpepple: sure, will do | |
| bpepple | notting: great, thanks! | |
| jds2001 | i didnt see explicitrequires | |
| nirik | so are we passing all except Explicitrequires then? | |
| bpepple | nirik: correct. | |
| nirik | jds2001: https://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires | |
| bpepple | alright, if there is nothing else we can probably move on. | |
| sharkcz | +1 to all | |
| jds2001 | nirik: got it - i talked with abadger1999 about this awhile back. | |
| it's pretty much Use Common Sense(TM) is what FPC wanted. | ||
| notting | bpepple: added. | |
| bpepple | notting: thanks! | |
| alright, back to features then.... | ||
| nirik | it's hard to legislate common sense sometimes. ;( | |
| bpepple | .fesco 55 | |
| zodbot | bpepple: #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 | ||
| notting | for some reason i thought we already approved this | |
| bpepple | abadger1999: you want to look at this: https://fedoraproject.org/wiki/Talk:PackagingDrafts/ExplicitRequires | |
| nirik | I 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. | |
| bpepple | notting: 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. | ||
| dgilmore | notting: the feature page indicated its been approved | |
| jds2001 | yeah, I could have failed there. | |
| bpepple | ok, let's move onto the next feature then. | |
| nirik | yeah, we approved it. | |
| j-rod | didn't we say "approved, but please make most of these things Just Work" | |
| bpepple | .fesco 66 | |
| zodbot | bpepple: #66 (MinimalPlatform - http://fedoraproject.org/wiki/Features/MinimalPlatform) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/66 | |
| notting | acpid? seriously? | |
| i would like some more info on how the anaconda option is supposed to be exposed | ||
| nirik | ok, this is the min install back again. ;) it's not an easy thing to do. | |
| is the feature owner here? | ||
| wrabco | yes | |
| abadger1999 | notting, bpepple: Excellent, I can take that back to FPC to see about adding that. | |
| bpepple | abadger1999: great, thanks! | |
| nirik | wrabco: 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 | ||
| jds2001 | enough to get other stuff. | |
| wrabco | it's core + around 15 packages | |
| j-rod | jds2001: likewise | |
| dgilmore | the only sane minimal install would be enough to give bash and yum | |
| notting | wrabco: in that case... should we extend core? | |
| dgilmore | everythging else would need to be added manually | |
| wrabco | see: 485995 | |
| j-rod | wrabco: does this tie into anaconda's text-mode default install at all? | |
| wrabco | yes there is a way to extend the core | |
| nirik | wrabco: 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? | |
| dgilmore | jds2001: i define minaimal as %packages bash yum | |
| jds2001 | dgilmore: that would give you too much stuff :) | |
| wrabco | I think I can ask anacoda developers | |
| jds2001 | dgilmore: all the lsb stuff and whatnot. | |
| dgilmore | i think i minimal install would be a great thing to ship as a kickstart only | |
| jds2001: it doesnt | ||
| wrabco | there isn't so much work | |
| j-rod | I'm thinking this should be exactly the same thing as what clumens was talking about being installed in text mode w/o a kickstart | |
| dgilmore | wrabco: i diasgree with your comment that it doesnt need documentation | |
| jds2001 | j-rod: +1 | |
| dgilmore | wrabco: it needs alot of documentation. because the definition of what is a minimal install varies for each person | |
| wrabco | dgilmore, I meant that I don't have any other homepage for it | |
| dgilmore | j-rod: i disagree. I have alot of machines where text mode is the only install option | |
| dgilmore | wrabco: we have a whole wiki | |
| j-rod | dgilmore: vnc, dude. :) | |
| wrabco | dgilmore, as a definition I propose to paste comment #9 from 485995 | |
| dgilmore | wrabco: thats not a valid excuse | |
| jds2001 | dgilmore: you mean VNC won't work? | |
| j-rod | dgilmore: part of the new minimal anaconda text-mode install eliminates package selection entirely, iirc | |
| dgilmore | jds2001: i never use vnc for install | |
| jds2001 | we approved last week the minimal install | |
| dgilmore | i guess im special and need to deal with it | |
| jds2001 | dgilmore: doesn't mean you can't :D | |
| j-rod | so you either get their pre-defined minimal package set, or you use a kickstart | |
| dgilmore | jds2001: i missed that portion i guess because i have no idea what yoru talking about | |
| jds2001 | yeah, i guess we'd need to see what clumens was thinking for that packages set. | |
| * dgilmore really doesnt like that | ||
| dgilmore | but i guess i have to deal with it | |
| wrabco | I don't about clumens work | |
| nirik | well, I guess I like this idea overall, but am not sure if we should approve it without anaconda dev's buyin. | |
| bpepple | ok, so are we at a point to vote on this feature? | |
| jds2001 | yeah, i think the right hand might not be talking to the left here :) | |
| j-rod | yeah, I'd say postpone until there's been some discussion w/anaconda folks | |
| jds2001 | or work in in with the text mode revamp. | |
| bpepple | sounds good to me. anyone object to that? | |
| j-rod | generally like the idea though | |
| sharkcz | and don't forger about the thincrust project, they have a minimal install set too | |
| wrabco | hehe | |
| "and it's focused on security" | ||
| j-rod | yeah, would be nice if all of the minimal install sets could be one in the same... | |
| dgilmore | wrabco: i agree with jeremy acpid should not be there | |
| wrabco | what about VM? | |
| dgilmore | wrabco: make it work without it | |
| notting | what does libvirt need acpi for? it doesn't Require: it | |
| sgrubb | sometimes VM's don't shutdown | |
| dgilmore | sgrubb: make it work without it | |
| sgrubb | I was told that the solution was to add acpid | |
| dgilmore | thats not a solution | |
| nirik | sounds like a hacky workaround. ;( | |
| sgrubb | but maybe in newer kernels VM's listen better | |
| sgrubb | dgilmore, I guess if that is the only objection we can live with it | |
| sgrubb | s/with/without | |
| big difference :) | ||
| dgilmore | i also disagree with a MDA and audit being there | |
| notting | oh, libvirt implements shutdown by faking the power button? | |
| sgrubb | notting, yes | |
| dgilmore | they should be things that the admin choses | |
| sgrubb | MDA? | |
| dgilmore | Mail Delivery Agent | |
| i.e. postfix | ||
| sgrubb | oh, 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... | ||
| dgilmore | i personally would put postfix on. but others would choose something else | |
| sharkcz | yea, like sendmail ;-) | |
| sgrubb | was someone working on a non-network MDA ? | |
| jds2001 | i thought that there was an MDA that's not also an MTA. | |
| * jds2001 forgets the name. | ||
| nirik | we should really get some kind of really dumb local MDA. Or email2rssfeed or something so we don't need that dep | |
| sgrubb | agreed | |
| * nirik thinks we are drifting offtopic now tho. ;) | ||
| Nirmal nirik | ||
| bpepple | nirik: agreed. | |
| sgrubb | well, not really | |
| the goal is a working server in the end | ||
| no MTA, no cron output | ||
| dgilmore | sgrubb: thats ok | |
| bpepple | ok, so we're going to bump this feature until the anaconda team has a chance to weigh-in. Is that correct? | |
| sgrubb | we could do without postfix if there was something smaller | |
| dgilmore | i think anaconda, releng and QA need to weigh in on this | |
| nirik | sgrubb: exim might be, but thats debatable. | |
| notting | ln -s procmail /usr/sbin/sendmail ;0 | |
| (probably won't work *just* like that, but) | ||
| wrabco | exim doesn't deliver email to root by default (just a note) | |
| sgrubb | ok, if we come up with something procmail based are we OK? | |
| * nirik could put his qmail package in for review. ;) har har. | ||
| nirik | well, that could possibly solve that issue, depending on how hacky the solution is... | |
| shall we move on? | ||
| bpepple | who is going to contact the anaconda team? feature owner or FESCo? | |
| j-rod | should be feature owner, if you ask me... | |
| otherwise, we're playing telephone tag | ||
| wrabco | I'll contact them | |
| bpepple | j-rod: works for me. wrabco, that alright with you? | |
| wrabco | yeah | |
| bpepple | wrabco: great, thanks! | |
| bpepple | alright, moving on.... | |
| .fesco 68 | ||
| zodbot | bpepple: #68 (PPC64 as primary - https://fedoraproject.org/wiki/Features/PPC64_as_primary) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/68 | |
| nirik | is the feature owner here? | |
| bpepple | dwmw2 voted -1 to this. | |
| maynardj | yes | |
| maynardj | I submitted the feature | |
| j-rod | rel-eng had major objections too | |
| sjmunroe | the issue is fedora as a path to RHEL | |
| dgilmore | so this would mean we add another arch | |
| sjmunroe | RHEL is all 64-bit hardware | |
| dgilmore | we would need to do a ppc and ppc64 compose | |
| j-rod | the bulk of fedora ppc users are ppc32 still | |
| maynardj | sjmunroe is a team member of mine, here to help answer questions | |
| j-rod | so yeah, we'd wind up having to do both a ppc32 and ppc64 spin | |
| sjmunroe | what about G5 and PowerStations | |
| nirik | sjmunroe: sure, but you use 32bit userspace right? | |
| j-rod | for an already niche userbase | |
| sjmunroe | we are switching to 64-bit default | |
| nirik | why? I thought that was bad performance wise and made no sense? | |
| j-rod | for the record, I *have* a powerstation here, and it works quite nicely w/a 64-bit kernel, 32-bit userspace... :) | |
| dgilmore | sjmunroe: and they are probably all less than 4gb ram and wouls see significant performance slowdowns and ram usage increase | |
| j-rod | nirik: end-users aren't the brightest things... | |
| dgilmore | j-rod: you have to have a 64 bit kernel on 64 bit hardware right? | |
| same as sparc does | ||
| j-rod | nirik: they want to build 64-bit stuff, and get confuzzled | |
| sjmunroe | with -msecure-plt the gap between it only 8% | |
| j-rod | dgilmore: yes, 64-bit kernel on my powerstation w/32-bit userspace | |
| nirik | I think this is a bad idea to cover over a documentation issue. | |
| sjmunroe | more then that | |
| hard to build 64-bit apps on fedora | ||
| too much missing | ||
| dgilmore | this needs full releng/mirror buy in. since it means we have to add another set of cd/dvd isos | |
| j-rod | so we build more 64-bit stuff | |
| dgilmore | as well as qa who need to test a whole extra arch | |
| nirik | what 64bit things are missing? | |
| dgilmore | j-rod: its all built | |
| j-rod | dgilmore: I know :) | |
| dgilmore | j-rod: its shipped as a side repo | |
| sjmunroe | pcre? | |
| glib | ||
| j-rod | sorry, should have said "put more 64-bit stuff in the 'ppc' distro tree" | |
| sjmunroe | try building a 64-bit mono | |
| dgilmore | j-rod: it means at least 10 | |
| 8 gb on the mirrors | ||
| ryanarn | also 64-bit biarch headers support for perl and python are busted. | |
| ryanarn | at least last I checked. | |
| notting | you 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 | ||
| ryanarn | right, 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. | ||
| dgilmore | this feature would mean that we add a set of iso's http://download.fedora.redhat.com/pub/fedora/linux/development/ppc64/ | |
| j-rod | http://download.fedora.redhat.com/pub/fedora/linux/development/ppc64/os/Packages/ has 64-bit glib and pcre in it | |
| dgilmore | http://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 | ||
| dgilmore | i really dont see the benefit that fedora users would get | |
| notting | ryanarn: the matching headers in the x86 and x86-64 python-devel package are identical - the arch-specific defines are in a separate file | |
| nirik | it would also mean multiarch changes? isn't the ppc64 repo only ppc64 now, but would have to grow multiarch ? | |
| notting | nirik: correct | |
| dgilmore | if 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) | |
| nirik | so, mock doesn't work for you ppc64 building? | |
| sharkcz | and the FE-ExcludeArch-ppc64 tracker bug should contain things that doesn't build on ppc64 | |
| dgilmore | nirik: i know it does. thats how we build all the 64 bit packages in the Everything ppc64 tree | |
| nirik | right. | |
| * 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. | |
| dgilmore | sjmunroe: 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 | |
| sjmunroe | but that will not leverage the community for test? | |
| j-rod | -1 here | |
| notting | sjmunroe: no, but given the existing community is 2:1 ppc32... | |
| dgilmore | sjmunroe: i think you will find that you will get little to no testing. since there are far to many losses by making this change. | |
| maynardj | so how would we run this past releng/qa/mirrors folks, if we decide to continue to push this? | |
| dgilmore | sjmunroe: 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 | ||
| maynardj | he's releng, right? | |
| dgilmore | maynardj: Jesse keating is | |
| wwoods: is QA | ||
| notting | oh, for the record, -1 from me. | |
| dgilmore | sjmunroe: 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. | |
| notting | i think that's 8 with one abstention. | |
| sjmunroe | dgilmore, my personal G5 has 8GB | |
| bpepple | notting: correct. | |
| dgilmore | sjmunroe: mine has 1gb, | |
| nirik | sjmunroe: 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? | |
| dgilmore | sjmunroe: and you run alot of processes needing more than 4gb ram? | |
| sjmunroe | yes | |
| bpepple | ok, so there were eight '-1', and one abstention, so we've not approved making PPC64 as primary. | |
| nirik | sjmunroe: what processes just out of curiosity? firefox? | |
| * notting would assume databases, computational things, etc. | ||
| sjmunroe | quadtree analysis of images | |
| my hobby | ||
| bpepple | ok, anything else folks want to mention regarding this feature, before moving on? | |
| dgilmore | lets move on | |
| nirik | sjmunroe: 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. | ||
| f13 | fwiw, release engineering has a big -1 on the ppc64 feature. | |
| bpepple | ok, moving on then..... | |
| maynardj | I 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 | |
| f13 | unless we /only/ did ppc64 | |
| zodbot | bpepple: #65 (Fedora Creative Commons Content repository) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/65 | |
| bpepple | maynardj: I think you would probably need to get rel-eng buy-in first since they would be the folks doing most of the work. | |
| nirik | ok, so this is a seperate repo of free content packaged for fedora... | |
| notting | on one hand, i like the idea | |
| nirik | me first thought is that perhaps this should go to the Board. Is this something fedora wants to get involved in in the long term? | |
| notting | on the other hand, having a bunch of stuff packaged in rpm format and installed at the system level seems sort of strange | |
| jds2001 | so i'm all for this idea, but is Fedora the right place? | |
| nirik | secondly, can we work with/partner with some other thing doing that already? | |
| sharkcz | such content could be shareable between distros, at least rpm based ones | |
| dgilmore | I think we should encourage this. being content that can take advantage of whats in fedora. one repo should work on all releases | |
| dgilmore | content that needs things outside of fedora would have to not be allowed in | |
| bpepple | in general I like the idea. | |
| sharkcz | dgilmore: +1 | |
| notting | also, 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 | |
| dgilmore | but it probably needs board approval to pursue | |
| nirik | http://mashable.com/2007/10/27/creative-commons/ | |
| I think the overhead of packaging and maintaining content in rpms is probibly not worth it for most content. | ||
| bpepple | I'm +1 the idea in general, but I think we probably need some guidelines on packaging and what is acceptable. | |
| jds2001 | so i talked with spot about this last night | |
| and the precedent is that we already have dive into python in the distro | ||
| nirik | sure, 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-rod | my particular use case was Linux Device Drivers | |
| nirik | on the other side what about a image of someones cat. It won't ever get updated (except in other pictures). | |
| bpepple | j-rod: yeah, that suggestion was what sold me on the idea. ;) | |
| j-rod | nirik: but an image of someone's cat provides no significant tangible benefit | |
| f13 | except for screensavers | |
| so on, so forth | ||
| notting | really, it depends on the cat | |
| bpepple | notting: ;) | |
| nirik | if it's CC licensed it could go in this repo... right? or what is the deciding question on what could be added? | |
| bpepple | nirik: I think that's why we need some kind of guidelines on what's acceptable. | |
| nirik | I 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 | ||
| f13 | from 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 | ||
| dgilmore | nirik: it may not be. but certainly its something we should encourage someone/group to come up with a solution | |
| f13 | when 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 | ||
| bpepple | nirik: yeah, the board might be a better place to make a decision on this, since it's not really a technical issue per se. | |
| abadger1999 | Maybe asking what the proponents think rpm management of the content will add to the user experience would help? | |
| nirik | I think it's a longer term issue as well... we seek the Board's long term vision. ;) | |
| dgilmore | nirik: +1 take it to the board | |
| * wwoods has no objection to FESCo's decision to reject PPC64 as a primary arch | ||
| sharkcz | rpm will allow to uninstall the stuff | |
| jds2001 | +1 punt to the board | |
| sharkcz | +1 for taking it to board | |
| notting | +1 | |
| 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 | ||
| zodbot | bpepple: #47 (Documented QA Team Scope) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/47 | |
| bpepple | wwoods: you want to lead this one? | |
| bpepple | hmm, looks like wwoods stepped away. | |
| wwoods | nah, I'm here | |
| bpepple | ah, ok. you know the specifics about this one? I'm not really sure what this one is about. | |
| wwoods | just trying to find my notes on the subject, since that was a couple weeks ago | |
| bpepple | np. | |
| wwoods | basically there's some confusion on where QA ends and where other groups begin | |
| I made up a QA charter on the spot | ||
| wwoods | and someone suggested it might be best to make sure FESCo etc. know and agree what I've decided by fiat | |
| wwoods | apologies for the delay | |
| meeting summary is here: | ||
| https://www.redhat.com/archives/fedora-test-list/2009-February/msg00048.html | ||
| charter: | ||
| "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. ;) | |
| wwoods | the important thing here, I guess, is that FESCo (and QA) recognize that QA is *not* responsible for deciding the *content* of the distro | |
| dgilmore | wwoods: is there a wiki page? | |
| wwoods | there was some dispute about whether QA should be deciding things like, say, default settings for openssh | |
| nirik | agreed, except QA can be consulting about new content that may impact their testing. | |
| notting | ??? | |
| i mean, QA should be involved in content as part of the feature process | ||
| wwoods | which is obviously wrong, but the argument *can* be made that "overall quality depends on blah blah blah" | |
| notting | but not at the theoretical openssh setting level | |
| dgilmore | wwoods: id say QA can make recommendations. if there not followed it could be escalated | |
| wwoods | overly-literal or overly-technical views of "QA" | |
| cause confusion. | ||
| bpepple | dgilmore: +1 | |
| wwoods | right, dgilmore's point is the secondary thing - even though QA isn't responsible for *deciding* what goes and what stays and making policy | |
| wwoods | we should be consulted about bigger changes and allowed to make recommendations | |
| * nirik nods. | ||
| dgilmore | wwoods: i whole hartedly agree | |
| wwoods | I think we're really just making explicit the implicit arrangement(s) between FESCo and QA and other groups | |
| wwoods | so. I guess the question is: do we agree to the charter as stated | |
| j-rod | +1, worksforme | |
| bpepple | +1 | |
| notting | +1 | |
| wwoods | and shall we state for the record that it is *not* QA's job to determine the content of the distro | |
| nirik | sure, +1 | |
| wwoods | except in an advisory role | |
| sharkcz | +1 | |
| dgilmore | +1 | |
| wwoods: and yes i agree QA can advise, but should not be expected to determine content | ||
| wwoods | right - FESCo should respect the opinion of people representing QA interests, but in the end, FESCo makes the decision | |
| wwoods | I'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. | ||
| dgilmore | wwoods: thanks | |
| bpepple | wwoods: great. anything else regarding QA? | |
| wwoods | nothing off the top of my head - there's a couple QA-driven features but those will come up in the agenda as normal | |
| bpepple | Ok. 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? | ||
| kwizart | my item can be discussed next week | |
| ! | ||
| bpepple | kwizart: yeah, that was the one I pushed back. ;) | |
| ok, let's put a fork in this meeting. | ||
| * bpepple will end the meeting in 60 | ||
| kwizart | but indeed, it would be interesting to be seen , and a general decision to be made... That was the purpose of asking a FESCo decision | |
| kwizart | eof | |
| * 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!