Extras/SteeringCommittee/Meeting-20070125

= 2007 January 25 FESCo Meeting =

Present

 * Brian Pepple 	(bpepple)
 * Thorsten Leemhuis	(thl)
 * Warren Togami	(warren)
 * Jeremy Katz		(jeremy)
 * Christian Iseli	(ch4chris)
 * Toshio Kuratomi	(abadger1999)
 * Jason Tibbitts	(tibbs)
 * Tom Callaway		(spot)
 * Dennis Gilmore	(dgilmore)
 * Bill Nottingham	(notting)
 * Rex Dieter  	(rdieter)
 * Josh Boyer		(jwb)
 * Kevin Fenzi 		(nirik)
 * Jesse Keating	(f13)

Absent

 * Andreas Bierfert	(awjb)

EPEL Update

 * Still waiting on RedHat IT. Most of the necessary people will be at FUDCon, and the plan is to have session regarding EPEL at the HackFest.

Opening Core

 * Warren discussed the basic plan on how the review of the Core packages will proceed. He is going to work out the final details before FUDCon.

Encourage co-maintainership

 * thl sent an e-mail to the mailing lists with his proposal for co-maintainership which generated quite a bit of discussion. He will incorporate suggestions from the mailing lists and the meeting into his proposal, and bring it back to FESCo.

Syslog-ng Patent Problems

 * bpepple is going to check with Greg DeKoenigsberg and spot to verify that this is in legal's queue.

Preparation for F7

 * nirik is going to poke some folks regarding broken deps.
 * The current plan is not to do a mass-rebuild of packages since there aren't any toolchain reasons for it.

Proposed ACL system

 * notting gave a brief description on how the ACL system will work:
 * there will be a file 'pkg.acl' that can be added either to the package toplevel or per-branch. It lists account names (one per line) that get access:
 * no pkg.acl == wide open
 * empty pkg.acl == 'owner' only
 * 'owner' == owners.list + owners.epel.list owner
 * only the owner or the CVS admin can add/modify the acl
 * owners.list is going to be locked down.
 * per-branch ACLs inherit from the toplevel ACL for the package
 * e-mail notification: the package owner + anyone in the acl for the package will get e-mail notifications of all changes to said branch
 * For more details, please refer to the IRC log.

Misc

 * There will be no FESCo meeting on 2007-02-01, since most of FESCo will be traveling to FUDCon that day. FESCo will have a meetup during FUDCon.
 * People attending the HackFest at FUDCon, please look at http://www.fedoraproject.org/wiki/ThorstenLeemhuis/HackFest

Log
--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process c4chris here, but only for about 10 minutes... shouldn't we be on #fedora-meeting ? FESCo meeting ping -- abadger1999, awjb, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, thl, tibbs, warren c4chris c4chris|w thl is around abadger1999 is here c4chris: I couldn't get Chanel OPs in time for the meeting. I'm here. bpepple, ah, ok Cool, one less tab. tibbs, I actually would like to get rid of tabs by using the meeting room for more meetings tibbs, then I could get rid of fedora-qa and fedora-board but well, usage cases depend :) Alright, it looks like most folks are here. --- bpepple has changed the topic to: FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update oh man, another meeting. yup --- bpepple has changed the topic to: FESCO-Meeting -- Opening Core -- jeremy/warren -- plans for the mass review seem to be really needed soon! pong whoop spoke to soon. only gave us 47 seconds :-P --- bpepple has changed the topic to: FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update Any word from RH IT? So basically we've added a discussion to FUDCon. no word from RH IT. bpepple: not yet :( Though I start working there the monday after FudCon so I'll probably be following up directly at that point. we are going to do a QA session at FUDCon as well we plan to work out the finer details there QA being Questions/Answers ? c4chris: yes is there interest for a small EPEL meeting at the hackfest, too? to discuss the near and long term future? --> notting (i=notting@redhat/notting) has joined #fedora-extras Is there someone we can poke at RH to speed this up, or will the discussion at FUDCon address the outstanding issues? We could do that, i think all the key players will be there. ok. notting is our best contact for that. --> rdieter (n=rdieter@sting.unl.edu) has joined #fedora-extras mmcgrath, how much time would we need? when do you and quaid have time for it? i thinkthe people we need to deal with will be at fudcon I can easily make time for it because it involves the future of the infrastructure team (its where our packages will come from) mmcgrath, it's listed already on http://www.fedoraproject.org/wiki/ThorstenLeemhuis/HackFest but has to time slot yet but we can decide that dynamically at the hackfest, too dgilmore, mmcgrath: anything else regarding EPEL? bpeppel: not much other than my neglect of the wiki site. Moving on then.. --- bpepple has changed the topic to: FESCO-Meeting -- Opening Core -- jeremy/warren -- plans for the mass review seem to be really needed soon! http://www.tiki-lounge.com/~toshio/fedora/buglist.html We're trying to nail down the final details but the basics are 1) File a bug for every package 2) separate those bugs onto several different package category trackers, so it doesn't go too damned slow 3) Have cached's views of those trackers like Toshio's http://www.tiki-lounge.com/~toshio/fedora/buglist.html who files all those bugs? could we automate that? 4) This will be separate from existing trackers like FE-NEW because they are of higher priority to happen, while FE-NEW contains things of questionable quality. Automate, yes we could. The only hard part is... how do we choose which goes onto what tracker? s/could/should/ IMHO randomly? what categories will there be? Desktop tracker? Java tracker? everything else? As long as we split it roughly evenly between 3 or 4 trackers this shouldn't be unreasonably sow. slow. or assign them all agains one tracker, and then allot them could they be split by comp groups? base/core/desktop/ et? Sorry, guys: gotta run. I can help with automated BZ filing if needed. I'll read the log later and see what was decided. Feel free to email me directly if I can be of help... c4chris c4chris|w later I'm afraid that 1,000 bugs on one tracker will be far too slow. c4chris: no problem. warren, have then on one tracker and allot them is still easier then file all of them manually afaics thl, what does this mean? could we use a new bugzilla instance for this? then fold the data back into the main one as each package gets accepted? FDESKTOP-NEW -> FDESKTOP-ACCEPTED (no need for REVIEWED? ASSIGNED can mean "taken" nirik, no. nirik, merging bugzilla databases is non-trivial and error prone. warren, I just don#t want to file all of them manually :) ok, just a thought. the purpose of having one ticket per review is to have a paper trail for history +1 thl, yeah, filing will be automated. we just have to create the categories. I'm here for another m inute if there is something I can do right now? quaid, that topic passed a while ago ok, warren: what is the plan for sponsoring current RH maintainers? warren: BASE? DESKTOP? KDE? JAVA? DEVTOOLS... or just leave it up to the person making the script to automate adding the bugs? +1 for " leave it up to the person making the script" Doesn't matter how it is split, as long as it is automatic filed, and soon. =) warren: +1 soon +1 bpepple, I'm going to have to beat each RH developer individually. +1 for whatever. I don't think the blockers matter much. warren: ok. clue-by-four beating. wait a sec Shouldn't we figure out the category lists ourselves? are the category lists that important? well.. no Another possibility, is to have the "core" stuff in one category, with less central dependencies in others. eh... we'll figure something out, I'll talk with c4chris when he gets back. move on warren: ok. On to the next topic. topic FESCO-Meeting -- Encourage co-maintainership -- all --- bpepple has changed the topic to: FESCO-Meeting -- Encourage co-maintainership -- all Core merge does enable co-maintainership =) warren: cool. :) This really isn't a good topic anymore, just many pieces need to be done to make it easy . next thl? well I don#t think it's that easy sorry guys i gotta run Or do we want more discussion on the list about it? co-maintainership is much more than just to have two or more maintainers I#d like to know what the FESCo people think about the whole idea dgilmore: later. last week I got a go with that stuff I wrote and now it's completely disliked? not disliked, some folks took offense to the tone, thought it was to dictatory. I admit that my wording might be a bit to direcdt here and there I don't think anyone disagreed with the (core) mesage. but that why I'm asked here before I send it out I'm no native english speaker, so sometimes the tone might accdentatlly be more harsh then I#d want it to be imo, it's (mostly) fine. You can't please 100% folks 100% of the time. if the direction is to improve the current proposal I can work further on it rdieter: agreed. but then I need a bit more backing in case some people dislike parts I did appreciate the comment that policy should be separated from suggestions/best-practices. I felt left there quite alone yesterday no fsco members particiapted or better: backed the idea rdieter, well, we have that mix in other policies, to too Sorry, I participated in one thread, but then I suppose that was on a different mailing list. tibbs, was, no problem I did throw in a comment I thought, but yesterday was really busy. ;( what skvidal suggested is okay, but it leaves many thing that are IMHO important out and we left them out far to long already IMHO thl: Agreed. we need ways for new contribnutors to get involved more We could start simple, with something close to what skvidal/f13 suggested, and add to it as needed. rdieter, what skvidal suggested is there already That seemed to please most folks in the thread. that what we said all the time alredy I think the main ingredient to add to what skvidal said is "Encourage comaintainers" thl: I participated, I'm in FESCO... abadger1999, that is old, too abadger1999: How is that any different than what has already been done? thl: It's the actual topic for this discussion in fact. f13, that's why I wrote "backed the idea" in the last line ah from where i sit, i haven't seen a lot of cases where people are off wanting to package the same thing s/last/line after that/ i don't know if that's because they assume it's already taken so they won't bother, or what. but adding some kind of blurb on the wiki about co-maintaining would be a good start IMHO, the "policy" needs to be short and sweet, like skvidal's. Complimenting the policy could be some text explaining WHY co-maintainership is encouraged and what problems it seeks to solve. jwb, well, I for myself gave of a lot of packages in the past and that way got new people into the project jwb: i've seen it happen a couple of times, but i don't think it's a major thing. cwickert is such a example thl, right but i'm saying how often is that the case? we'd see how it goes jwb: Our packaging culture is kinda pointing in the wrong direction. I did not force anybody to hand over packages abadger1999, meaning? I just suggested that get co-maintainers first, and hand over packagers if they do a good job is another way we could use Packages are treated as being owned by the person who originally packaged them and co-maintainership is the specifal case. I might be missing something important here, but why is the idea of co-maintainership so contentious? abadger1999, +1 abadger1999, treated by whom though? I think it should be more clear that the projects sort of "owns" the packages warren: no idea. Some people seem awfully territorial about their packages. thl, +1 The new proposed ACL policy that f13 was talking about is simple: thats because we have hte idea of ownership and responsiblity and that certain project contributors that really now what they are doing should get access everywhere as ralf suggested on the list 1) By default, only owner may touch it. _you_ brought this package to the collection _you_ are responsible for the bugs and keeping it working _you_ are on the line for issues. 2) The owner may grant privs to others. I wated to write a proposal where all maintainers are equal in the beginning jwb: Everything. Comaintainership should permeate a pakcage's life cycle. but that was disliked when I proposed that here i mean, i've never had a single person ask to co-maintain one of the packages i own. i would love it if someone did, but i don't see a huge pent up demand for it... 3) I suggested that a maintainer may grant not only individuals, but arbitrary groups. i'm just wondering if we're trying to force something for which there is no demand jwb: You're doing too good a job. owner is accountable, co-maintainers are responsible? jwb, some people might step up if you would offer it jwb: nobody is "forcing" anything. abadger1999, doubtful ;) warren: individuals is easy. groups is hard. warren: the idea isn't contentious. Making policy that forces every package to have one or two co-maintainers is. f13++ I've only asked to comaintain packages where there's a problem (like the maintainer is short of time) thl, ok i'll be sure to do that thl: agreed. that's how I found co-maintainers for some of my packages. well, let's stop here I'll write something up and send it to the list there are a number of packages that i would offer co-maintainership for. f13: ++, the thing is that when I read the policy I read "should" everywhere... So partially it's interpretation of the guidelines. maybe we should to the whole thing in smaller steps abadger1999: the nature of how Fedora works there is package ownership, there is somebody that is responsible / accoutnable for what ahppens to a package. Because of this, many don't want unknowns messing with what they are responsible for. thl: good idea. thl, +! er, 1 rdieter, more work for me :-/ abadger1999: there is a very clear difference between should and shal. Ok, we should problaby move on. bpepple, +1 thl: I know, that's life, just like in the packaging comittee... baby steps. should == suggestion. shal == forced policy I think a better write up of why co-maintainers are needed would be good... as well as a 'how to find a co-maintainer' nirik, I'll think about it f13: And I'm saying that I didn't see shall in a whole bunch of cases. nirik, send me a note if I forget it --- bpepple has changed the topic to: FESCo-Meeting -- MISC -- kernel-naming - What did davej find out about this? nirik: I don't think anyone has ever suggested the idea co-mainters is bad... (: f13: I agree with your analysis of why people don't like to hand partial ownership to others. (But not that it is the best thing for the project) jeremy, did davej ever get back to us? he's still in .au, iirc okay, we'll visit him there jwb: he's not back yet notting, yeah.. jeremy said he had special ninja skillz to get ahold of him rh pays the flight jeremy, failure to deploy the ninjas?
 * warren here.
 * jeremy is here-ish
 * nirik is here mostly.
 * spot is here
 * bpepple doesn't see mmcgrath or dgilmore, so maybe we should come back to this.
 * dgilmore is breifly here
 * thl wonders is quaid actually is around for the hackfest
 * rdieter runs in late.
 * mmcgrath will do it, promise.
 * rdieter suspects someone with enough bugzilla-fu could make it work (best). (:
 * quaid saw his name mentioned here but cannot look back up the buffer atm to see why
 * thl querys quaid
 * bpepple is fine with that also.
 * bpepple wonders about that also.
 * jwb is here now
 * notting strongly prefers skvidal's suggestion. leave long policies to when we run into more issues with people trying to adhere to that one
 * bpepple is doing that with the telepathy stack.
 * mmcgrath has had people ask to become co-maintainers
 * XulChris is reminded of all the shalls in government software specification documents
 * thl likes to note that the topic came up on fedora-test-list last week once again, too
 * thl hides

--- bpepple has changed the topic to: FESCo-Meeting -- MISC -- No meeting on 2007-02-01, due to folks traveling to FUDCon? jwb: nah, I thought that getting the answer could wait until he was back as long as he got the mission to ask :-) well, davej is in an odd mix of sight seeing and sick as a dog jeremy, k I don't think he's taking any time to respond to ninja smoke. jeremy, maybe we should talk to him on the hackfest I will be on the way to the airport. that's rpobably be easier for all people involved perhaps a special quick meeting at fudcon? nirik, +1 nirik: That's what I was thinking also. somebody get special fesco badges made up and pass around? excellent idea, if nothing else, to get to meet everybody in person. who fesco is *not* going to be there? nirik: +1 is awjb going to be there? bpepple, nope not i I havent seen hoim for ages I think I should just ask him to leave FESCo  Fedora-QA is planing a meeting on Saturday FWIW I think he's okay with that thl: I was wondering about that also. I don't remember the last time I saw him. Bob-Laptop, our schedule is at http://www.fedoraproject.org/wiki/ThorstenLeemhuis/HackFest bpepple, I'll try to contact him thl: great, thanks. why? lost interest? busy (with other stuff)? he had some problems with this university long story give him our best.. If awjb and I would leave that would make fesco smaller (13 people again then) When do people want to meet-up and FUDCon, or do we want play it by ear when we get there? bpepple: play by ear. It's an unconference ear++ hell, we could meet up over at the Red Hat bar sounds good to me. wait f13: even better!  redhat has a bar? it's called the Red Hat Cafe, and it has nothing to do with Red Hat that's a bit problematic, as dgilmore and abadger1999 might be involved with infrastrucute stuff  ok sign me up! ;) a bit planing might help in this case XulChris: http://www.bostonredhat.com/ We should definitely set a time but it could be after we arrive. abadger1999, in the kick of meeting Saturday morning maybe? If wouldn't hurt for at least the folks staying in the hotel to get together and save on cab fare. tibbs: +1 tibbs: +1 thl: +1 or bus fair busses/T may be much cheaper But AFAIK Rex and I are the only ones in the Fairmont. mmcgrath: I wouldn't recommend it. yeah, +1, but I am in a diffrent hotel. ;) mmcgrath: driving in Boston and trying to park is a no win situation I said no but I think it was assigned to me. Will there be no place to park? tibbs: I'm at the Fairmont. Well, that's three at least. theoretically, you can get from most hotels to other hotels via the T and reasonable walking mmcgrath: Jack had some trouble with that last year tibbs: I think I'll be in the Fairmont too. (Haven't made reservations yet.)  tibbs: thl is at the fairmont k. notting: indeed Unfortunately the hotel tells me it's 12 blocks from the Fairmont to the university. anything else regarding FUDCon before moving on? oh snap, I should make hotel reservations thx Bob-Laptop, seen it (and thx again for helping with getting the room) bpepple, please mention http://www.fedoraproject.org/wiki/ThorstenLeemhuis/HackFest in the summary thl: no problem. people attending the hackfest should look at that page bpepple, thx --- bpepple has changed the topic to: FESCo-Meeting -- MISC -- the "syslog-ng patent problems" - Has RH legal looked at this yet? 'no' (short answer - it hasn't come up yet) notting: It's in legal's queue though isn't it? i don't know. might ask spot or gregdek? it didn't come up in the board/legal discussion (probably b/c it didn't get on the agenda) notting: I'll contact them and see if they know the status. Onto the next topic. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Extras 7 preparation -- roadmap, broken deps, key packages (wxGTK2 issues solved?), rebuilds, FE7Target bug, mail to all package owners? mschwendt wanted this added to the schedule. bpepple: is there a slightly more wordy description available? notting, +1 oh, I'm sure. ;) there are fewer broken deps, but still some... I can try and poke some more people this weekend. that would be a big help why do wee need a FE7Target bug? we only need F7target afaics since Test1 is coming up, it would be good to have a consistant tree what is the criteria for being added to a F7target? Can we cajole the wxgtk maintainer into putting out a -compat package? yeah, wxGTK2 seems to still have lots of issues. another one? :/ nirik: historically, there isn't one. although bugs may get removed if they're frivolous, impossible, etc. nirik: A) not critical enough to block the release B) something we think we have a good chance at fixing for the release. ok, fair enough. Are we planning on doing mass rebuilds again this release? They are a pain, but I would say yes... before t3? bpepple: I haven't heard anything yet from the tools folks bpepple: i don't think we have any toolchain related reasons to do so without any technical reason, I'd rather not. f13: +1 but they're so fun... there's bunches of things in core that would have linked against extras packages f13: agreed. f13, +1 well, it does find awol maintaiers/orphaned packages... but yeah unless you feel that getting them all buitl with the new buildsystem software is a technical reason. wwoods: of course, but that's a separate issue. so the plan is not to do rebuilds, unless the toolchain requires it. nirik: thats a screw in search of a hammer. rdieter: okay then There was discussion of trying to get core rebuilt so that we could have the logs handy when reviewing. f13: yeah, probibly so. ;) nirik, well, maybe we should have a real "find awol maintainers" solution (e.g. a database that sends out mails and tracks if they get answered or something) thl: maybe that's something we can work on post F7? I would think we'd find them naturally if bugs against their packages go unanswered for a period of time thl: or files bugs against packages and checks to see if they have been closed correctly by the maintainer, etc... but thats another discussion. bpepple, that not urgent (but was proposed for F6 already, but never started) I have a particular itch (sound-juicer built without id3 tag support) I want scratched, but if that type of problem can be fixed without mass rebuilds... then yay! bpepple, somebody just needs to do the work... but I don't consider it much important nirik, yes, for example something like that wwoods: I"d rather just see those requests be handed individually tibbs: I think thl asked mdomsch about doing that... I was thinking about mirroring fc5/fc6/devel core/extras on a USB2 drive and bringing it with me to fudcon if it would assist any... he evaluates if it's possible nirik, I asked gregdek for a server with a local mirror ok, cool. and two machines that can be used to start mock or for people without notebook nirik: I was planning to have a checked out CVS tree and a mirror on my disk. anyhow, on this topic, perhaps we should ask mschwent to expand? nirik: if nothing else a nslug + usb drive Ok, I'll expand upon this issue on the wiki, and check with mschwendt to see if there's anything else he thinks we should look. we should stick a builder on every box there :-D nirik: agreed. I'm going to try and bring an extra laptop as well. I should have access to my ppc/x86_64 boxes here from there too... can do builds... provided my x86_64 box doesn't decide to keep locking up. Is there anything else folks want to say in regard to F7 prep? Otherwise I'll move on. Of course, assuming the network is reasonable I can get back to my home machines as well. But I'm planning for it not to be, just in case. wait, if we just need more builders... Why don't we stick some in the colo? mmcgrath: +1, hack-fest will pound them. we're getting a bit off topic, eh? bpepple: is a description of the proposed acl system & e-mail notification system wanted? mmcgrath, then we'd need some kind of scratch repos, too (or am I missing something) notting, i'd like one I'm not sure how the hackfest will pound the builders, as we won't be submitting things to the buildsys. bpepple: or is that too much for here? notting: I think it would be fine. Perhaps the reviewed packages will be built once we're done with them. ok, so how ACLs will work: there will be a file 'pkg.acl' that can be added either to the package toplevel or per-branch. lists account names (one per line) that get access no pkg.acl == wide open empty pkg.acl == 'owner' only per-branch ACLs inherit from the toplevel ACL for the package owner according to the owners.list? 'owner' == owners.list + owners.epel.list owner only the owner or the CVS admin can add/modify the acl notting, does this replace or augment owners.list? jwb: builds on top of so the owner is listed in two places? no the acl lists non-owners allowed access the "when to touch other peoples packages" policy allows certain people to touch all packages if there is a good reason too; how will that word with the new scheme? ah, i see ok owner is automatically allowed might need additional privs for security/fesco folks when a checkin/build is needed? ie, the clement stuff? certain people: security team let's let notting finish describing it
 * nirik will be on a plane then I think.
 * thl will be on over the ocean
 * f13 ducks
 * mmcgrath might have a car.
 * nirik is at the Doubletree
 * abadger1999 packs his hiking poles and a snack
 * Bob-Laptop pokes thl ... BTW you are at the fairmont
 * nirik doesn't know how we can tell? someone in communication with legal?
 * thl votes for no (I currently don#t see any good reasons for it)
 * thl did
 * mmcgrath adds a note to the admin schedule

thl: there is ATM a cvs admin group with global access. we could work something else out on top of that this acl mechanism allows for you to have multiple, comma-separated owners in owners.list. however, i suspect you'll break some other tool if you try that notting, it's not that important, but you should might want to keep it in mind when you desing the stuff (it will all move to the pkgdb eventually) notting, do we have a timeframe for rollout? sounds pretty good to me. jwb: soon, very soon. i'd like to get it done before fudcon. on the subject of owners.list... is that a one-way gateway? ie, removing a package doesn't remove the bugzilla component? probably notting, and package owners can add user accounts to pkg.acl for co-maintainership, etc? so is there any way to delete components once they have appeared for any time in owners.list? big fat warning: as the ACL is used for access control (obviously), and owners.list feeds into the access control.... owners.list is going to be locked down. we apologize for the inconvenience :/ jwb: right. but before you scream about notting's warning... the new buildsystem requires a buildsystem admin to "add" the package to a collection, before it can be built. could that admin then do the cvs branching, too? so there is already going to be a barrier of entry, the "add" the package step could populate the owners list, be it in flat file or db. yay. thl: probably the same group of admins that already does it thl: technically they are nonblocking steps and can be done in parallel perhaps we should expand the list of admins by a couple people you can branch all you want before/after adding the package to the collection, you just can't build before the package is added notting, f13, then I vote for parallel as those stuff often will be needed at the same time e-mail notification: the package owner + anyone in the acl for the package will get e-mail notifications of all changes to said branch thl: if it is one person doing it, hard to work in parallel sometimes 9: thl: parallel of what and what? f13, :) f13, hence adding more admins f13, nearly parallel :) jwb: indeed, this would be very rel-engy type stuff notting, add to the collection and request branches f13, sign me up
 * jwb was just waiting for an explanation
 * hint* *hint*

so what triggers off this? wiki page request? FE-ACCEPT addition? notting: thanks, is there anything else? nirik, i would think wiki page request pointing to the review bug nirik, as is done for branch requests today notting, oh and this sounds good to me ok. fair enough. bpepple: not really. So does this stuff all exist currently? the import process is almost certainly going to change to fail-safe (existing but empty pkg.acl) Ok, since we're running late we should probably wrap-up the meeting. --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora Extras tibbs: written, needs finished testing is there anything folks want to discuss before calling it quits for today? nirik: well, if we get an honest rel-eng team built up, an email address that leads to a ticketing system might be better once the import has been done. BTW, is the repository changing for the merge? So extras maintainers will need to check out their packages again? would make it easy to find packages with no co-maintainers. ;) tibbs: the old path will work tibbs: one way or another wonder if some mirrors who don't carry extras will blow up with all of core+extras in a f7 dir... oh well, burn that bridge when we come to it. nirik: mirrors will be kept in the loop of changes. althought it may not be easy to transition them with the use of hardlinks like I did when I changed rawhide layout so, pain for the mirrors. nirik: we are currently discussing a proposed download layout with some mirrors and some community members. it will most likely be a new /pub/fedora/releases (or similar) heirarchy, so things will need to change anyway f13, _growing_ pains we don't create pain, we just mirror it. ;) notting: yeah, and epel in the mix too. -- MARK -- Meeting End
 * rdieter needs to run soon, elf needs food, badly.
 * nirik would be happy to help doing these tasks as long as what to do was explained to him. ;)
 * thl wonders where packages get uploaded in the future after the merge
 * bpepple will end the meeting in 60, and objections?
 * bpepple will end the meeting in 30
 * bpepple will end the meeting in 15