FESCo-2007-09-13

bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
* jeremy is here
nirik is here.
warren here
bpeppleHi, everyone! Who's around?
dwmw2_MPLfish
* notting is here
warren read "nothing is here"
abadger1999 takes a seat in the gallery
bpepplewas there an FPC meeting this week?  I don't remember seeing any minutes for it.
abadger1999There was
We discussed eggs some more but no voting yet.
bpeppleAh, ok. thanks, abadger1999.
* jima lurks a little
lmackenwarren: nothing is everywhere
bpeppleOk, 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_MPLdo it already :)
bpeppleYeah, I've think we've discussed this enough, and can probably vote on it. ;)
nirikso how does |DrJef|'s dkms proposal fit in here? Obsoleted by it?
bpepplenirik: I think it's a separate item altogether, IMO.
dwmw2_MPLfairly much, yes.
tibbsBTW, I did mail minutes but to fedora-devel-announce (since -maintainers is supposed to be gone) but it was rejected.
nirikbut 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_MPLwarren: yes, but so is shipping kmods
that's kind of an orthogonal issue
* dgilmore is here
warrennirik, good question.
jeremynirik: 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
jeremynirik: an upstream developer who doesn't want to get his code upstream could conceivably have a dkms payload for you to download
nirikright, so if this proposal is accepted, |DrJef|'s is moot.
f13I'm here.
dwmw2_MPLnirik: yes, you're right. Sorry, it's not _that_ separate then, is it?
nirikright. I just wanted to make that clear...
f13not 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.
tibbsI 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.
f13proposal even.
tibbsUsers will get this stuff from somewhere, after all.
dwmw2_MPLtibbs: agreed. But actually putting useful stuff into the kernel rpm will.
nirikso is there any provision for the current existing kmods? or they just disappear?
dwmw2_MPLand that's the flip side of this proposal.
tibbsI'm not sure it would actually alleviate any kernel maintainer pain.
dwmw2_MPLcan we list them?
f13tibbs: 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
nirikdid we get any kind of +1 from cebbert/davej on this?
|DrJef|nirik, i love being moot!
f13|DrJef|: so be quiet then!
nirikkmod-em8300 and kmod-sysprof
tibbsAnd what about the whole "fedora sticks with upstream" thing?
c4chrishi all.  Got a family emergency to attend to, so won't be able to participate today.  I apologize.  Later...
dwmw2_MPLtibbs: 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
tibbsMore 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
tibbsOr do we just drop modules that don't rebase easily?  And then who is well-served by that?
dwmw2_MPLtibbs: "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
f13tibbs: 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_MPLif 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_MPLand rawhide works again
tibbsf13: 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".
dgilmoretibbs: 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_MPLupdates for shipping releases happen infrequently, after the problematic rebase stuff has already been worked out in rawhide
f13tibbs: and for that, |DrJef|'s dkms approach may be best.
tibbs: but that's for "other repos" to decide upon.
tibbsdgilmore: And we're talking about adding more patches.
dwmw2_MPLf13: perhaps so. All outside the context of 'Fedora' but in the larger ecosystem
dgilmoretibbs: yes i know.  but people are unliekly to notice since they did not notice or pay attention when we cleaned it up
f13tibbs: would you be happier if we just outlawed these modules all together?
tibbsNot at all.  I'm not against kernel module packages.
f13tibbs: 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
tibbsI'm just asking questions that I haven't seen asked in this discussion.
jeremynirik: 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
f13tibbs: 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_MPLfurthermore, 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
f13which is the /right/ kind of work the person should be spending time on
warrenf13, and neither is encouraging the module to go upstream
f13not busy work making a complex module package.
tibbsf13: I happen not to agree with you, but I don't really see that disagreement as being material to the base issue.
nirikI'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_MPLnirik: years of history isn't enough of an indication that the fedora kernel maintainers are willing?
nirikotherwise I think it's a good plan.
dwmw2_MPLdid you not notice when we started shipping bcm43xx before it was upstream?
dwmw2_MPLand all the other wireless stuff more recently?
f13warren: 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.
tibbsIn the end I don't think this body has ever considered acking what patches the kernel maintainers carry in the kernel.
dwmw2_MPLand a whole bunch of things before that?
tibbsSo if they want to suck in things that we are shipping as kmods then I have no problems at all with that.
nirikdwmw2_MPL: yeah, I suppose thats true... ok, I withdraw that...
dwmw2_MPLsome provision for existing kmods would be useful though, yes.
tibbsBut then it raises the question of why they haven't incorporated those modules already, if they're so important to Fedora.
dwmw2_MPLwe could even allow them to persist for a little while, with grandfather rights. Although I'd rather not.
knurdtibbs, 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)
bpeppleOk, are we at a point where we should vote on this?
dwmw2_MPLshould we clarify the status of the existing kmods first?
* knurd wonders where that rule will get written into
knurdinto the packaging guidlines somewhere?
bpeppledwmw2_MPL: that would be fine with me.
dwmw2_MPLrealistically speaking, maybe we don't want to kill them before F8?
f13I'm ok with voting on this proposal in general and just persuing the existing kmods as a seperate issue
dwmw2_MPLso let's just say no _more_ kmods ever, and ... what f13 said
spotyeah, i think they can stay in F8 but should be either merged or dropped by F9
dwmw2_MPLand no dkms payload either
f13right
bpepplespot: +1
dwmw2_MPLspot: 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.
bpeppleProposal: No new kmods, and existing ones dropped by F9.
jeremy+1
bpepple+1
spot+1
nirik+1
knurdbpepple, s/kmods/kernel modules packages (kmods, dkms, kmdls)
dwmw2_MPL+1
bpeppleknurd: agreed.
dwmw2_MPLand what knurd said.
jeremyknurd: yeah
dwmw2_MPLdkms _source payloads_ that is; dkms infrastructure itself is fine
* dgilmore is afk for a few
knurddwmw2_MPL, sure
tibbs-1
bpepplenotting, warren: ?
notting+1
warren+1
dwmw2_MPLtibbs: what can we do to make you happier? I thought we addressed both your concerns?
bpeppleok, that's 7 '+1', and one '-1'.
f13+1
dwmw2_MPLsorry, those were nirik's. But what can we do anyway?
tibbsdwmw2_MPL: Probably nothing; I'm simply against all of this banning of useful things.
dwmw2_MPLcan 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
tibbsAs 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_MPLok
tibbsDon't worry about appeasing me; my opinion is on record and that's fine with me.
bpeppleAlright, 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?
knurdso where will that result be written to?
just wondering...
packign guidelines?
bpeppleknurd: somewhere in the Packaging Guidelines would make sense.
dwmw2_MPLtibbs: it would be easy to digress from here to the whole quality vs. quantity thing, on which I think I'm mostly outnumbered
bpeppleDoes anyone have a suggestion as to where?
tibbsI guess FPC will need to codify this.
knurdtibbs, bpepple, agreed, but who takes care of it?
f13spot: ping?
* spot whistles innocently
spotalright, alright, i'll do it
knurdthx spot
jeremythanks spot :)
bpepplethanks, spot! ;)
abadger1999knurd: 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.
tibbsI was trying to find where the current policy is.
dwmw2_MPLright, 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
bpepplelater, dwmw2
knurdshould 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_goneabadger1999: 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.
tibbsI think leaving the third party repos entirely without guideance is a step backwards.
f13knurd: isntead of remove, we should just replace them with a reference to the new policy
bpeppleknurd: maybe we can mark them as obsolete.
dwmw2_goneknurd: go easy on that for a while; they might be useful to third parties.
knurdjust asking because I have some improvements
abadger1999dwmw2_gone: Right.  But the kernel isn't reviewed yet :-)
dwmw2_goneheh
knurdthat we are using in livna-devel already
tibbsPull it from the distro!
dwmw2_goneanyway, food calls.
* dwmw2_gone &
jwbbpepple, did i miss the vote on kmods?
bpepplejwb: yeah.
tibbsjwb: Indeed.
jwbcrap
f13jwb: you can toss our vote in for hsitory sake
bpeppleIt was approved 8-1.
knurdand it does not help if we have old kmod stuff in hte wiki that is not maintained
* dgilmore is back
jwbf13, we approved dwmw2_gone's proposal?
f13knurd: doesn't rpmfusion have any policy that is otherwise not in the FEdora packaging policies?
jwb: yes.
knurdthus 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
abadger1999Might be nice to point to the policies in other repos... if it's legal to do so soon.
f13jwb: 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
jwbhm
knurdf13, 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
jwbf13, bpepple: i'll review the logs on the discussion and send in my vote via email.  not that it matters much
knurdI can understand him, thus I think we just kick it out
f13, btw, rpmfusion did not decide yet how to handle kenrel-module packages
warrenknurd, it seems pretty clear that fusion would need packaging guidelines beyond fedora
knurdwarren, +1
and it likely easier for everyone if it maintains those on it own
the fpc has enough to do already
warrenFedora's guidelines shouldn't prevent 3rd parties from extending beyond its own guidelines
tibbsFedora couldn't prevent that in any case.
bpeppletibbs: right.
dgilmorewarren: we control fedora  nothing more nothing less
warrennod
knurdtibbs, well, we try to work together with Fedora
thus if there are guidlines, we try to follow them
tibbsBut not to the point of excluding kmods, of course.
knurdbut if they are not maintained in fedora, I#d say we kick those guidlines (e.g. for kmods in htis case)
tibbs, sure
dgilmoreknurd: thats a good thing.   and there are obviously parts were you need to diverge to meet your market :)
knurdso 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?
bpeppleknurd: truthfully, I don't feel strongly either way.  I think marking it as obsolete would be fine.
knurdthat are the two alternatives afaics
knurdbpepple, why not remove it then?
knurdit#s still in the wiki history if someone really wants to read about it
* nirik is fine with just removing it...
f13I think they should be reduced to information about the current kmod policy
f13so that people who knew the locations of them before are informed of th enew policy
knurdwell, something must be done
it's up to you guys to decide
I#d say: mark them as obsolete for a year
nirikyeah, I don't care. Remove them, put 'OBSOLETE: see linktonewpolicy' on the top of them, or what...
knurdadd a "no seperate kernel modules pacakges are allowed" on all the pages
and remove them after taht year
bpeppleknurd: that sounds fine w/me.
knurdI#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
f13no, we haven'tleft.
Proposal: Replace existing kmod content with a link to the new policy (wherever it lands).
dgilmoreknurd: if there is another channel im excluded from it
f13+1
jeremy+1
bpepplef13: +1
* viking-ice op serve's from the shadows..
dgilmoref13: +1
tibbs+1
notting+1
knurdf13, 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
f13knurd: 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.
knurdf13, well, okay, if someone writes that, sure
bpeppleOk, I that's 7 '+1'. f13's proposal has passed.
knurdthx guys
f13np
bpepplewho wants to write that?
f13dwmw2_gone should IIRC
with the other kernel folks
warrenSo instead of a vague notion of heading toward upstream, things accepted into fedora kernel are whatever our kernel maintainers accept?
bpepplef13: sounds good.
f13basically a how to on submitting things to the kernel.
warrenAnd we have no encouragement toward upstream at all?
f13warren: absolutely not
warren: please get off that horse.
tibbsIt's a valid question, though.
dgilmorewarren: we allways encourage upstream for every patch.  so enougha lready
f13warren: 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.
warrenok
bpeppleok, we should probably move on....
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- keep fedora-test-list & fedora-packaging-list? - all
bpepplePeople on the list questioned if we should also close these two lists also.
jwbnot 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. ;)
bpepplejwb: I think the packaging list probably should be.  The test-list I don't really have an opinion on.
f13I'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.
jwbyeah, that's my thinking
tibbsI'll just host another list elsewhere for the packaging committee if fedora insists on closing it.
warrenThe traffic on fedora-test-list is pretty heavy
can we really handle that on f-d-l?
jeremywarren: most of the traffic on fedora-test-list is from the test update announcements, though
lmackenonce bodhi gets RSS feeds, that would be much more elegant than hammering test-list
warrenlmacken, +1
wwoodsso, you want all the fedora testers to join -devel-list?
warrenlmacken, comment and discuss an update can happen in bodhi
lmackenwarren: right
warrenlmacken, perhaps with non-account commenting with CAPTCHA
nirik128 of the last 260 posts on test have been test update announcements.
wwoodsI'm perfectly okay with closing -qa-list, as an aside
jeremywwoods: I think there should be _a_ list for testers
wwoods: right now, there are kind of two (-test and -qa)
wwoodstest-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.
jeremywwoods: quite possibly
we used to get lots of value from the release-specific beta lists
wwoodsjeremy: right, I'm all for closing -qa and doing tool development on -devel and tester discussion on -test-list or -devel-users or whatever
jeremyand with them, the discussion was focused around testing of the beta of a specific release
wwoodsI 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.
knurdwwoods, rawhide-list -- where would test-updates get discussed?
lmackenbodhi
wwoodswarren: I think so
knurdwwoods, test-updates are not really rawhide
warrenknurd, within bodhi itself
f13knurd: bodhi is a better location as the pusher has a higher chance of seeing the comment.
tibbsBodhi needs to grow some better discussion capability, then.
knurdonly there? I don#t like that idea
wwoodsknurd: yes, in bodhi
tibbsA 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...
warrentibbs, that's the idea.
lmackentibbs: all comment notifications now get sent to anyone that has made a comment on an update
knurdpeople often discussed "kernel-foo did not boot for me" stuff
wwoodsnirik: we tried a big mailing list reorg push and it went nowhere
knurdthat won#t work in bodhi
lmackenand you can keep up with the latest comments in bodhi from your front page
warrenlmacken, I suppose we could have a read-only mailing list for bodhi comments as well.
lmacken(you'll see this stuff later today)
wwoodsknurd: I'm not suggesting we *eliminate* -test-list
warrenlmacken, if people want to subscribe to the firehose.
lmackenwarren: or an RSS feed ?
warrenlmacken, yeah.
err.. yeah.
we really have to use RSS more
mail is so inefficient
nirikwwoods: 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?
warrennirik, is fedoraproject.org hosted list even possible?  Did we get past the legal limbo?
f13I'm still not entirely convinced it's necessary
or good use of our resources.
nirikyeah, dunno.
wwoodsMy 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
warrenf13, running our own MTA would be an upgrade given our MTA forwarding problems
warrenbut that is a separate issue entirely
wwoodsit might make sense to also have a rawhide-list for rawhiders
warrenwalters, state of things of what?
oops
wwoods, state of things of what?
wwoodsheh. I'm ww<tab>, not w<tab>
bpeppleOk, we're out of time.  Does anyone feel we should close fedora-packaging or fedora-test? Otherwise we should probably wrap this up.
wwoodswarren: all things testable. test updates, rawhide, test releases, &c
nirikperhaps continue discussion on list ? :)
warrenI think we should consider closing fedora-test-list only after bodhi has gained necessary functionality + RSS.
For now, no.
bpepplewarren: agreed.
f13bpepple: I say no now.
warrenmve on
move on =)
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
bpeppleanything people want to discuss?
wwoodshere'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?
f13well, rawhide is where most the development of Fedora happens
but not all of it.
wwoodsindeed, sir
so yes, there are non-rawhide things discussed on -devel-list
f13I picture fedora-devel not as "rawhide list" but as "fedora development"
bpepplewwoods: 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
wwoodsf13: with all rawhide discussion being a proper subset thereof?
f13wwoods: pretty much, unless you want to do qa of rawhide on -qa or -test-list
wwoodsmore generally: where do people running rawhide go to talk about rawhide?
-qa-list can die
f13I 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
f13wwoods: I think it depends on what they want to talk about.
wwoodsand we're talking about phasing out -test-list
tibbsCan we stop calling rawhide "devel", then?
wwoodsyeah really
f13tibbs: I tried to everywhere I found it.
warrenbugzilla
f13tibbs: except for the bugzilla component.
|DrJef|f13, isnt the tree still called development
f13which might not be too hard to change in the DB
|DrJef|: that is a good point.
wwoodsI 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
wwoodswe can change the bugzilla component name
|DrJef|f13, development is...the process
f13for F9 I could change it.
warrenShould we vote on this?
* nirik would like to see it called rawhide everywhere...
f13mirrors will shoot me if I do it now.
nottingchanging the tree on the ftp site is painful
warrenOfficially call Rawhide... Rawhide.
wwoodsthat's no problem. say the word. shall we do that for post-f8 rawhide?
nirikand perhaps we could add a 'redneck' translation back in. ;)
f13notting: yeah, hardlinks would really be wanted then.
for a period of time.
nottingf13: possibly. or just a toplevel symlink
f13we kind of screwed the mirrors on the whole s/Fedora/Packages/ change.
warrenWe could decide upon this now, and next meeting create a transition plan for the *hard* parts.
wwoodsprobably we should refer this to the board or somesuch to make sure it's a good decision wrt branding
f13notting: 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
wwoodsI definitely feel that having a clear name for Rawhide makes it stronger
warrenWe *could* keep the development directory and have rawhide as a symlink to it.
f13and 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
f13wwoods: unless they're hardlinks, rsync may wind up copying double files.
dgilmoref13: i kinda think we hardlink devel and rawhide  for awhile then drop off devel some point after f-8 is out the door
f13s/wwoods/warren/
warrenf13, eh?
f13, I don't think so.
f13warren: depends on options used I suppose
warrendefault options wont
f13default options don't include -H
warrenf13, hardlinks wont help either then.
dgilmorewarren: most mirrors use hardlinks
f13nope.
but you're right, with -H it may do the right thing with a symlink.
warrenf13, with default options, symlinks wont cause double copies, is my point.
wwoodsso, okay, we want to change the name of the 'devel' tree to 'rawhide' everywhere, and that's a good thing.
bpepplewwoods: +1
warrenLet's work on a transition plan next meeting.
wwoodspost-f8-release we'll be changing the bugzilla version name and the directory name
implementation of latter TBD
bpepplewarren: sounds like a plan.  I'll add it to the schedule for new week.
anything else? or should we wrap it up?
dgilmorebpepple: wrap er up
bpeppledgilmore: 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!