| bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process | ||
| bpepple | FESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren | |
|---|---|---|
| * jeremy is here | ||
| nirik is here. | ||
| warren here | ||
| bpepple | Hi, everyone! Who's around? | |
| dwmw2_MPL | fish | |
| * notting is here | ||
| warren read "nothing is here" | ||
| abadger1999 takes a seat in the gallery | ||
| bpepple | was there an FPC meeting this week? I don't remember seeing any minutes for it. | |
| abadger1999 | There was | |
| We discussed eggs some more but no voting yet. | ||
| bpepple | Ah, ok. thanks, abadger1999. | |
| * jima lurks a little | ||
| lmacken | warren: nothing is everywhere | |
| bpepple | Ok, we can probably get started. | |
| --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- obsoleting kmod proposal: http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal - dwmw2, f13 | ||
| dwmw2_MPL | do it already :) | |
| bpepple | Yeah, I've think we've discussed this enough, and can probably vote on it. ;) | |
| nirik | so how does |DrJef|'s dkms proposal fit in here? Obsoleted by it? | |
| bpepple | nirik: I think it's a separate item altogether, IMO. | |
| dwmw2_MPL | fairly much, yes. | |
| tibbs | BTW, I did mail minutes but to fedora-devel-announce (since -maintainers is supposed to be gone) but it was rejected. | |
| nirik | but if we say "no kernel modules except in the kernel package", dkms can't happen, right? | |
| * warren thinks patching the fedora kernel instead is caving to the "I don't want to go upstream" whiners. | ||
| dwmw2_MPL | warren: yes, but so is shipping kmods | |
| that's kind of an orthogonal issue | ||
| * dgilmore is here | ||
| warren | nirik, good question. | |
| jeremy | nirik: dkms can be shipped. packages of dkms payloads can't be | |
| dwmw2_MPL | _If_ we're going to ship it, we've already caved. Now it's just a question of whether we make life hard for ourselves by doing it in separate packages, or whether we patch it into our kernel. | |
| jeremy: right. | ||
| if we accept my proposal, at least | ||
| jeremy | nirik: an upstream developer who doesn't want to get his code upstream could conceivably have a dkms payload for you to download | |
| nirik | right, so if this proposal is accepted, |DrJef|'s is moot. | |
| f13 | I'm here. | |
| dwmw2_MPL | nirik: yes, you're right. Sorry, it's not _that_ separate then, is it? | |
| nirik | right. I just wanted to make that clear... | |
| f13 | not entirely moot, there could still be policy for how to create said dkms payloads, used by other repos perhaps, but Fedora itself just won't make use of them. | |
| that said, I'm obviously +1 on this current propoasl. | ||
| tibbs | I think we're stuffing our heads in the sand if we think that banning kmods from the main repos will do anything to alleviate user or kernel maintainer pain caused by kmods. | |
| f13 | proposal even. | |
| tibbs | Users will get this stuff from somewhere, after all. | |
| dwmw2_MPL | tibbs: agreed. But actually putting useful stuff into the kernel rpm will. | |
| nirik | so is there any provision for the current existing kmods? or they just disappear? | |
| dwmw2_MPL | and that's the flip side of this proposal. | |
| tibbs | I'm not sure it would actually alleviate any kernel maintainer pain. | |
| dwmw2_MPL | can we list them? | |
| f13 | tibbs: for the modules that Fedora wants to support it makes it much easier for users to get those updated modules along with the updated kernel. | |
| dwmw2_MPL: I think there are only two | ||
| nirik | did we get any kind of +1 from cebbert/davej on this? | |
| |DrJef| | nirik, i love being moot! | |
| f13 | |DrJef|: so be quiet then! | |
| nirik | kmod-em8300 and kmod-sysprof | |
| tibbs | And what about the whole "fedora sticks with upstream" thing? | |
| c4chris | hi all. Got a family emergency to attend to, so won't be able to participate today. I apologize. Later... | |
| dwmw2_MPL | tibbs: having dealt with out-of-tree modules _and_ in-tree modules for most of the last decade, and having dealt with extra patches in the RHL and then Fedora kernels for a slightly shorter period of time, I disagree with you | |
| I think it will alleviate pain all round | ||
| tibbs | More patches in the kernel and more pain on rebasing to upstream pushed directly onto the kernel maintainers. | |
| |DrJef| | nirik, the new language being communicated from upstream regarding making the process of new module inclusion easier moots the underlying desire | |
| tibbs | Or do we just drop modules that don't rebase easily? And then who is well-served by that? | |
| dwmw2_MPL | tibbs: "Fedora sticks with upstream" isn't affected by whether it's in the kernel rpm or a separate kmod package either. | |
| ok, the way this works, in practice. And has worked for years: | ||
| when working on _rawhide_, the kernel is rebased | ||
| f13 | tibbs: this isn't necessarily opening the door to a flood of new kmods, very few are going to pass the bar to get into the kernel I suspect. | |
| dwmw2_MPL | if a patch doesn't apply or build (or even if an in-tree driver temporarily breaks), davej will turn it off. And poke whoever he thinks might care | |
| then they fix it. | ||
| * spot is here, late | ||
| dwmw2_MPL | and rawhide works again | |
| tibbs | f13: In that case, then we'll still have need of kernel module packages in some fashion, even if they're off in the "not talked-about repos". | |
| dgilmore | tibbs: i constantly see reviews stating that Fedora's kernels are heavily patched when its not true any longer. tehre are some patches but its certainly not heavily patched | |
| dwmw2_MPL | updates for shipping releases happen infrequently, after the problematic rebase stuff has already been worked out in rawhide | |
| f13 | tibbs: and for that, |DrJef|'s dkms approach may be best. | |
| tibbs: but that's for "other repos" to decide upon. | ||
| tibbs | dgilmore: And we're talking about adding more patches. | |
| dwmw2_MPL | f13: perhaps so. All outside the context of 'Fedora' but in the larger ecosystem | |
| dgilmore | tibbs: yes i know. but people are unliekly to notice since they did not notice or pay attention when we cleaned it up | |
| f13 | tibbs: would you be happier if we just outlawed these modules all together? | |
| tibbs | Not at all. I'm not against kernel module packages. | |
| f13 | tibbs: because when it comes down to it, how far away we are from upstream matters most when bugs occur, and regardless /where/ the module came from, if the module is loaded then we're not upstream. | |
| * nirik suspects thats pretty much what we are doing... I bet the bar is pretty high to get into the fedora kernel package | ||
| tibbs | I'm just asking questions that I haven't seen asked in this discussion. | |
| jeremy | nirik: the bar for getting a kmod package in has been pretty high. and building a working kmod package is far more pain than doing a driver for the kernel package | |
| f13 | tibbs: IMHO the argument about distance from upstream makes no difference whether the module exists as a patch in the kernel rpm or as a seperate rpm all together. | |
| jeremy | (... as someone who has decided against the former but done the latter a number of times) | |
| dwmw2_MPL | furthermore, the work required for doing a driver for the kernel package is fairly close to what's required to get it upstream | |
| we're pushing people in the right direction | ||
| f13 | which is the /right/ kind of work the person should be spending time on | |
| warren | f13, and neither is encouraging the module to go upstream | |
| f13 | not busy work making a complex module package. | |
| tibbs | f13: I happen not to agree with you, but I don't really see that disagreement as being material to the base issue. | |
| nirik | I'd like to see 2 things on this before I vote yes: 1) some kind of ack from the fedora kernel maintainers that they are willing to deal with this, and 2) some provision for the existing kmods (moved in? dropped? something?) | |
| dwmw2_MPL | nirik: years of history isn't enough of an indication that the fedora kernel maintainers are willing? | |
| nirik | otherwise I think it's a good plan. | |
| dwmw2_MPL | did you not notice when we started shipping bcm43xx before it was upstream? | |
| dwmw2_MPL | and all the other wireless stuff more recently? | |
| f13 | warren: actually given that the work to get it into our kernel package is roughly the same as getting it upstream, we're encouraging them to do the right work. | |
| tibbs | In the end I don't think this body has ever considered acking what patches the kernel maintainers carry in the kernel. | |
| dwmw2_MPL | and a whole bunch of things before that? | |
| tibbs | So if they want to suck in things that we are shipping as kmods then I have no problems at all with that. | |
| nirik | dwmw2_MPL: yeah, I suppose thats true... ok, I withdraw that... | |
| dwmw2_MPL | some provision for existing kmods would be useful though, yes. | |
| tibbs | But then it raises the question of why they haven't incorporated those modules already, if they're so important to Fedora. | |
| dwmw2_MPL | we could even allow them to persist for a little while, with grandfather rights. Although I'd rather not. | |
| knurd | tibbs, sysfoo will never head upstream iirc | |
| tibbs, FESCo back months ago acceted it for some other reason I can't remember | ||
| (just FYI; as I've said multiple time already: I'm fine with banning kenrel-module pacakges of all kinds these days in fedora) | ||
| bpepple | Ok, are we at a point where we should vote on this? | |
| dwmw2_MPL | should we clarify the status of the existing kmods first? | |
| * knurd wonders where that rule will get written into | ||
| knurd | into the packaging guidlines somewhere? | |
| bpepple | dwmw2_MPL: that would be fine with me. | |
| dwmw2_MPL | realistically speaking, maybe we don't want to kill them before F8? | |
| f13 | I'm ok with voting on this proposal in general and just persuing the existing kmods as a seperate issue | |
| dwmw2_MPL | so let's just say no _more_ kmods ever, and ... what f13 said | |
| spot | yeah, i think they can stay in F8 but should be either merged or dropped by F9 | |
| dwmw2_MPL | and no dkms payload either | |
| f13 | right | |
| bpepple | spot: +1 | |
| dwmw2_MPL | spot: I'm fine with voting on that as part of this proposal | |
| or separately, if there's anyone who'd vote no if that happen. | ||
| bpepple | Proposal: No new kmods, and existing ones dropped by F9. | |
| jeremy | +1 | |
| bpepple | +1 | |
| spot | +1 | |
| nirik | +1 | |
| knurd | bpepple, s/kmods/kernel modules packages (kmods, dkms, kmdls) | |
| dwmw2_MPL | +1 | |
| bpepple | knurd: agreed. | |
| dwmw2_MPL | and what knurd said. | |
| jeremy | knurd: yeah | |
| dwmw2_MPL | dkms _source payloads_ that is; dkms infrastructure itself is fine | |
| * dgilmore is afk for a few | ||
| knurd | dwmw2_MPL, sure | |
| tibbs | -1 | |
| bpepple | notting, warren: ? | |
| notting | +1 | |
| warren | +1 | |
| dwmw2_MPL | tibbs: what can we do to make you happier? I thought we addressed both your concerns? | |
| bpepple | ok, that's 7 '+1', and one '-1'. | |
| f13 | +1 | |
| dwmw2_MPL | sorry, those were nirik's. But what can we do anyway? | |
| tibbs | dwmw2_MPL: Probably nothing; I'm simply against all of this banning of useful things. | |
| dwmw2_MPL | can we persuade you not to see it as 'banishing' but more as 'embracing'? Instead of putting in a separate package as a third-class citizen, we embrace and incorporate into the kernel rpm proper? | |
| that's the intention | ||
| tibbs | As stated before, I have no problems with the kernel maintainers slurping kmods into the core kernel package if that's what they want to do. | |
| But we didn't just vote on that; we voted on dropping them from the distro if the kernel maintainers don't want them in the core kernel package. | ||
| And I'm against that. | ||
| dwmw2_MPL | ok | |
| tibbs | Don't worry about appeasing me; my opinion is on record and that's fine with me. | |
| bpepple | Alright, so I see the vote being 8 '+1', and one '-1'. So we've approved dwmw2's proposal. | |
| Anything else on this item, before we move on? | ||
| knurd | so where will that result be written to? | |
| just wondering... | ||
| packign guidelines? | ||
| bpepple | knurd: somewhere in the Packaging Guidelines would make sense. | |
| dwmw2_MPL | tibbs: it would be easy to digress from here to the whole quality vs. quantity thing, on which I think I'm mostly outnumbered | |
| bpepple | Does anyone have a suggestion as to where? | |
| tibbs | I guess FPC will need to codify this. | |
| knurd | tibbs, bpepple, agreed, but who takes care of it? | |
| f13 | spot: ping? | |
| * spot whistles innocently | ||
| spot | alright, alright, i'll do it | |
| knurd | thx spot | |
| jeremy | thanks spot :) | |
| bpepple | thanks, spot! ;) | |
| abadger1999 | knurd: Should go in FESCo policy somewhere I think... Although FPC might want to codify how the kernel package deviates from the upstream mantra by accepting patches that provide modules. | |
| tibbs | I was trying to find where the current policy is. | |
| dwmw2_MPL | right, I'm afraid I need to run; sorry. I should be at this evening's dinner already -- but I couldn't let myself miss another meeting entirely | |
| * jwb is here now | ||
| bpepple | later, dwmw2 | |
| knurd | should we remove all the kmod policies from the wiki as well? | |
| or does fesco or the fpc want to manage those in the future? | ||
| dwmw2_gone | abadger1999: no need to codify how we deviate from the upstream mantra -- there's no change there at all. We've _always_ carried _selected_ other stuff. | |
| tibbs | I think leaving the third party repos entirely without guideance is a step backwards. | |
| f13 | knurd: isntead of remove, we should just replace them with a reference to the new policy | |
| bpepple | knurd: maybe we can mark them as obsolete. | |
| dwmw2_gone | knurd: go easy on that for a while; they might be useful to third parties. | |
| knurd | just asking because I have some improvements | |
| abadger1999 | dwmw2_gone: Right. But the kernel isn't reviewed yet :-) | |
| dwmw2_gone | heh | |
| knurd | that we are using in livna-devel already | |
| tibbs | Pull it from the distro! | |
| dwmw2_gone | anyway, food calls. | |
| * dwmw2_gone & | ||
| jwb | bpepple, did i miss the vote on kmods? | |
| bpepple | jwb: yeah. | |
| tibbs | jwb: Indeed. | |
| jwb | crap | |
| f13 | jwb: you can toss our vote in for hsitory sake | |
| bpepple | It was approved 8-1. | |
| knurd | and it does not help if we have old kmod stuff in hte wiki that is not maintained | |
| * dgilmore is back | ||
| jwb | f13, we approved dwmw2_gone's proposal? | |
| f13 | knurd: doesn't rpmfusion have any policy that is otherwise not in the FEdora packaging policies? | |
| jwb: yes. | ||
| knurd | thus my vote goes for removing it and leave the job up to 3rd party repos | |
| f13, well, I just want to be able to improve kmods | ||
| without making the FPC much work | ||
| abadger1999 | Might be nice to point to the policies in other repos... if it's legal to do so soon. | |
| f13 | jwb: the official vote was to not allow any /more/ kmods/kmdls/dkms payloads. Existing ones need to be merged with kernel or go away by F9 | |
| jwb | hm | |
| knurd | f13, as far as I understood spot there is not much interest in maintaining hte kmod stuff in the future, if it's not used in Fedora | |
| jwb | f13, bpepple: i'll review the logs on the discussion and send in my vote via email. not that it matters much | |
| knurd | I can understand him, thus I think we just kick it out | |
| f13, btw, rpmfusion did not decide yet how to handle kenrel-module packages | ||
| warren | knurd, it seems pretty clear that fusion would need packaging guidelines beyond fedora | |
| knurd | warren, +1 | |
| and it likely easier for everyone if it maintains those on it own | ||
| the fpc has enough to do already | ||
| warren | Fedora's guidelines shouldn't prevent 3rd parties from extending beyond its own guidelines | |
| tibbs | Fedora couldn't prevent that in any case. | |
| bpepple | tibbs: right. | |
| dgilmore | warren: we control fedora nothing more nothing less | |
| warren | nod | |
| knurd | tibbs, well, we try to work together with Fedora | |
| thus if there are guidlines, we try to follow them | ||
| tibbs | But not to the point of excluding kmods, of course. | |
| knurd | but if they are not maintained in fedora, I#d say we kick those guidlines (e.g. for kmods in htis case) | |
| tibbs, sure | ||
| dgilmore | knurd: thats a good thing. and there are obviously parts were you need to diverge to meet your market :) | |
| knurd | so my vote goes to: just remove all the kmods stuff from the wiki and say: no seperate kernel-module packages in Fedora | |
| dgilmore, yeah, but we try to not diverge without need | ||
| seems pretty silent | ||
| so what do you guys want? | ||
| outdatend and unmaintained infos in the wiki? | ||
| continue to maintain it without using/tesing it? | ||
| bpepple | knurd: truthfully, I don't feel strongly either way. I think marking it as obsolete would be fine. | |
| knurd | that are the two alternatives afaics | |
| knurd | bpepple, why not remove it then? | |
| knurd | it#s still in the wiki history if someone really wants to read about it | |
| * nirik is fine with just removing it... | ||
| f13 | I think they should be reduced to information about the current kmod policy | |
| f13 | so that people who knew the locations of them before are informed of th enew policy | |
| knurd | well, something must be done | |
| it's up to you guys to decide | ||
| I#d say: mark them as obsolete for a year | ||
| nirik | yeah, I don't care. Remove them, put 'OBSOLETE: see linktonewpolicy' on the top of them, or what... | |
| knurd | add a "no seperate kernel modules pacakges are allowed" on all the pages | |
| and remove them after taht year | ||
| bpepple | knurd: that sounds fine w/me. | |
| knurd | I#d just like to have a decisions today, so rpmfusion knows what to do | |
| * dgilmore thinks we need a way to have some shared fedora calandering | ||
| dgilmore will look at what we can do infrastructure wise | ||
| knurd wonders if everyone left or if there is a second channel where you guys discuss what to do | ||
| f13 | no, we haven'tleft. | |
| Proposal: Replace existing kmod content with a link to the new policy (wherever it lands). | ||
| dgilmore | knurd: if there is another channel im excluded from it | |
| f13 | +1 | |
| jeremy | +1 | |
| bpepple | f13: +1 | |
| * viking-ice op serve's from the shadows.. | ||
| dgilmore | f13: +1 | |
| tibbs | +1 | |
| notting | +1 | |
| knurd | f13, well, the "new policy" boils down to "no seperate kernel modules are allowed" | |
| f13, do we need a special page for that? | ||
| just wondering... | ||
| but yeah, +1 from me | ||
| nirik | +1 | |
| f13 | knurd: no, there is more to it, as there should be information on how to prepare a patch for the kernel and submit it to the Fedora kernel team. | |
| knurd: and policy on what we'll find acceptable as a patch to our kernel. | ||
| knurd | f13, well, okay, if someone writes that, sure | |
| bpepple | Ok, I that's 7 '+1'. f13's proposal has passed. | |
| knurd | thx guys | |
| f13 | np | |
| bpepple | who wants to write that? | |
| f13 | dwmw2_gone should IIRC | |
| with the other kernel folks | ||
| warren | So instead of a vague notion of heading toward upstream, things accepted into fedora kernel are whatever our kernel maintainers accept? | |
| bpepple | f13: sounds good. | |
| f13 | basically a how to on submitting things to the kernel. | |
| warren | And we have no encouragement toward upstream at all? | |
| f13 | warren: absolutely not | |
| warren: please get off that horse. | ||
| tibbs | It's a valid question, though. | |
| dgilmore | warren: we allways encourage upstream for every patch. so enougha lready | |
| f13 | warren: the kernel folks have emphaticaly stated that what they accept has to be headed upstream. | |
| warren: and the page outlining how to submit stuff can clearly state that. | ||
| warren | ok | |
| bpepple | ok, we should probably move on.... | |
| --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- keep fedora-test-list & fedora-packaging-list? - all | ||
| bpepple | People on the list questioned if we should also close these two lists also. | |
| jwb | not in my opinion | |
| but i don't really care either way | ||
| * nirik isn't on packaging list, but has no problem with moving test list all over to devel. ;) | ||
| bpepple | jwb: I think the packaging list probably should be. The test-list I don't really have an opinion on. | |
| f13 | I'd let wwoods decide on -test-list, I'm ambivilant other than we would need a new landing zone for -testing update announcements. | |
| * spot is pretty firmly against closing fedora-packaging-list | ||
| f13 | -packging should stay, treat it like a SIG list. | |
| jwb | yeah, that's my thinking | |
| tibbs | I'll just host another list elsewhere for the packaging committee if fedora insists on closing it. | |
| warren | The traffic on fedora-test-list is pretty heavy | |
| can we really handle that on f-d-l? | ||
| jeremy | warren: most of the traffic on fedora-test-list is from the test update announcements, though | |
| lmacken | once bodhi gets RSS feeds, that would be much more elegant than hammering test-list | |
| warren | lmacken, +1 | |
| wwoods | so, you want all the fedora testers to join -devel-list? | |
| warren | lmacken, comment and discuss an update can happen in bodhi | |
| lmacken | warren: right | |
| warren | lmacken, perhaps with non-account commenting with CAPTCHA | |
| nirik | 128 of the last 260 posts on test have been test update announcements. | |
| wwoods | I'm perfectly okay with closing -qa-list, as an aside | |
| jeremy | wwoods: I think there should be _a_ list for testers | |
| wwoods: right now, there are kind of two (-test and -qa) | ||
| wwoods | test-list traffic goes in cycles that correspond roughly to the release cycle, peaking shortly after test3 | |
| I think it also scales with the amount of community-building effort put into QA. cough cough. | ||
| jeremy | wwoods: quite possibly | |
| we used to get lots of value from the release-specific beta lists | ||
| wwoods | jeremy: right, I'm all for closing -qa and doing tool development on -devel and tester discussion on -test-list or -devel-users or whatever | |
| jeremy | and with them, the discussion was focused around testing of the beta of a specific release | |
| wwoods | I can totally see having a permanent rawhide-list | |
| warren | -devel-users is more confusing than -test-list no? | |
| wwoods, that might be a good idea. | ||
| knurd | wwoods, rawhide-list -- where would test-updates get discussed? | |
| lmacken | bodhi | |
| wwoods | warren: I think so | |
| knurd | wwoods, test-updates are not really rawhide | |
| warren | knurd, within bodhi itself | |
| f13 | knurd: bodhi is a better location as the pusher has a higher chance of seeing the comment. | |
| tibbs | Bodhi needs to grow some better discussion capability, then. | |
| knurd | only there? I don#t like that idea | |
| wwoods | knurd: yes, in bodhi | |
| tibbs | A forum per update or something, perhaps. | |
| * nirik wonders if we shouldn't just look at the big mailing list reorg instead of doing small steps a few at a time here... | ||
| warren | tibbs, that's the idea. | |
| lmacken | tibbs: all comment notifications now get sent to anyone that has made a comment on an update | |
| knurd | people often discussed "kernel-foo did not boot for me" stuff | |
| wwoods | nirik: we tried a big mailing list reorg push and it went nowhere | |
| knurd | that won#t work in bodhi | |
| lmacken | and you can keep up with the latest comments in bodhi from your front page | |
| warren | lmacken, I suppose we could have a read-only mailing list for bodhi comments as well. | |
| lmacken | (you'll see this stuff later today) | |
| wwoods | knurd: I'm not suggesting we *eliminate* -test-list | |
| warren | lmacken, if people want to subscribe to the firehose. | |
| lmacken | warren: or an RSS feed ? | |
| warren | lmacken, yeah. | |
| err.. yeah. | ||
| we really have to use RSS more | ||
| mail is so inefficient | ||
| nirik | wwoods: yeah, but I thought that was also trying to move to fedoraproject hosted lists, perhaps if we just reorg with the existing infrastructure it might go further now? | |
| warren | nirik, is fedoraproject.org hosted list even possible? Did we get past the legal limbo? | |
| f13 | I'm still not entirely convinced it's necessary | |
| or good use of our resources. | ||
| nirik | yeah, dunno. | |
| wwoods | My only demand is that there be at least one list for testers to discuss the state of things - fedora-test-list seems to do this job nicely | |
| warren | f13, running our own MTA would be an upgrade given our MTA forwarding problems | |
| warren | but that is a separate issue entirely | |
| wwoods | it might make sense to also have a rawhide-list for rawhiders | |
| warren | walters, state of things of what? | |
| oops | ||
| wwoods, state of things of what? | ||
| wwoods | heh. I'm ww<tab>, not w<tab> | |
| bpepple | Ok, we're out of time. Does anyone feel we should close fedora-packaging or fedora-test? Otherwise we should probably wrap this up. | |
| wwoods | warren: all things testable. test updates, rawhide, test releases, &c | |
| nirik | perhaps continue discussion on list ? :) | |
| warren | I think we should consider closing fedora-test-list only after bodhi has gained necessary functionality + RSS. | |
| For now, no. | ||
| bpepple | warren: agreed. | |
| f13 | bpepple: I say no now. | |
| warren | mve on | |
| move on =) | ||
| --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
| bpepple | anything people want to discuss? | |
| wwoods | here's something that's confusing - we call rawhide "devel" and then we have "fedora-devel-list" | |
| is it intended that all discussion about rawhide go to -devel-list? | ||
| f13 | well, rawhide is where most the development of Fedora happens | |
| but not all of it. | ||
| wwoods | indeed, sir | |
| so yes, there are non-rawhide things discussed on -devel-list | ||
| f13 | I picture fedora-devel not as "rawhide list" but as "fedora development" | |
| bpepple | wwoods: the purpose for the -devel isn't very clearly defined imo. | |
| |DrJef| | wwoods, i think rawhide discussion should have its only list called chapped-lips | |
| wwoods | f13: with all rawhide discussion being a proper subset thereof? | |
| f13 | wwoods: pretty much, unless you want to do qa of rawhide on -qa or -test-list | |
| wwoods | more generally: where do people running rawhide go to talk about rawhide? | |
| -qa-list can die | ||
| f13 | I think -devel-users is a mistake. -rawhide-users makes more sense, as questions about rawhide probably get chased off of fedora-list. | |
| |DrJef| | f13, the scope of -test-list is the most confusing to me.. i have to wade through it for both updates-testing packages as well as test releases | |
| f13 | wwoods: I think it depends on what they want to talk about. | |
| wwoods | and we're talking about phasing out -test-list | |
| tibbs | Can we stop calling rawhide "devel", then? | |
| wwoods | yeah really | |
| f13 | tibbs: I tried to everywhere I found it. | |
| warren | bugzilla | |
| f13 | tibbs: except for the bugzilla component. | |
| |DrJef| | f13, isnt the tree still called development | |
| f13 | which might not be too hard to change in the DB | |
| |DrJef|: that is a good point. | ||
| wwoods | I think Jeremy is right and I want to spread love and pride for rawhiders. because people who run rawhide are brave and crazy. | |
| |DrJef| | f13, seriously... rawhide is...the tree..fundamentally | |
| wwoods | we can change the bugzilla component name | |
| |DrJef| | f13, development is...the process | |
| f13 | for F9 I could change it. | |
| warren | Should we vote on this? | |
| * nirik would like to see it called rawhide everywhere... | ||
| f13 | mirrors will shoot me if I do it now. | |
| notting | changing the tree on the ftp site is painful | |
| warren | Officially call Rawhide... Rawhide. | |
| wwoods | that's no problem. say the word. shall we do that for post-f8 rawhide? | |
| nirik | and perhaps we could add a 'redneck' translation back in. ;) | |
| f13 | notting: yeah, hardlinks would really be wanted then. | |
| for a period of time. | ||
| notting | f13: possibly. or just a toplevel symlink | |
| f13 | we kind of screwed the mirrors on the whole s/Fedora/Packages/ change. | |
| warren | We could decide upon this now, and next meeting create a transition plan for the *hard* parts. | |
| wwoods | probably we should refer this to the board or somesuch to make sure it's a good decision wrt branding | |
| f13 | notting: hardlinks will help the mirrors not churn every package. symlinks don't really help that IIRC | |
| but I coudl be wrong. | ||
| wwoods: I'm pretty sure we voted once before to s/devel/rawhide/ everywhere a while ago | ||
| wwoods | I definitely feel that having a clear name for Rawhide makes it stronger | |
| warren | We *could* keep the development directory and have rawhide as a symlink to it. | |
| f13 | and we changed a bunch of wiki pages to help that. | |
| |DrJef| | f13, a give you a money back garauntee that if you called the collection of bits..rawhide.. there would be less confusion with regard to "development"..but the devel-list signal to noise won't be affected | |
| f13 | wwoods: unless they're hardlinks, rsync may wind up copying double files. | |
| dgilmore | f13: i kinda think we hardlink devel and rawhide for awhile then drop off devel some point after f-8 is out the door | |
| f13 | s/wwoods/warren/ | |
| warren | f13, eh? | |
| f13, I don't think so. | ||
| f13 | warren: depends on options used I suppose | |
| warren | default options wont | |
| f13 | default options don't include -H | |
| warren | f13, hardlinks wont help either then. | |
| dgilmore | warren: most mirrors use hardlinks | |
| f13 | nope. | |
| but you're right, with -H it may do the right thing with a symlink. | ||
| warren | f13, with default options, symlinks wont cause double copies, is my point. | |
| wwoods | so, okay, we want to change the name of the 'devel' tree to 'rawhide' everywhere, and that's a good thing. | |
| bpepple | wwoods: +1 | |
| warren | Let's work on a transition plan next meeting. | |
| wwoods | post-f8-release we'll be changing the bugzilla version name and the directory name | |
| implementation of latter TBD | ||
| bpepple | warren: sounds like a plan. I'll add it to the schedule for new week. | |
| anything else? or should we wrap it up? | ||
| dgilmore | bpepple: wrap er up | |
| bpepple | dgilmore: done. | |
| * 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 | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!