Extras/SteeringCommittee/Meeting-20070426

= 2007 April 26 FESCo Meeting =

Present

 * Brian Pepple 	(bpepple)
 * Jason Tibbitts	(tibbs)
 * Rex Dieter  	(rdieter)
 * Jesse Keating	(f13)
 * Christian Iseli	(c4chris)
 * Toshio Kuratomi	(abadger1999)
 * Josh Boyer		(jwb)
 * Jeremy Katz		(jeremy)
 * Bill Nottingham	(notting)
 * Warren Togami	(warren)

Absent

 * Dennis Gilmore	(dgilmore)
 * Kevin Fenzi 		(nirik)
 * Tom Callaway		(spot)

FESCo Meeting Minutes

 * warren will look at a bot to post irc logs from the meeting to a web directory, and then we will only be posting the summaries to the wiki.

Policies Updating

 * c4chris, tibbs, and bpepple will start fixing policies that have inconsistencies due to the merging of Core & Extras.

Sub-Groups Reporting to FESCo

 * Discussed how to be more efficient in handling of reporting from sub-groups. If a sub-groups provides a summary 24-hours prior to the FESCo meeting, the FESCo chair will just ask if there are "any objection to this week's report of at ".
 * Still needs to decide procedure for summaries from groups that can't get a summary to FESCo in time. bpepple sent an e-mail to the mailing list to get input on how folks would like to handle this.  https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00713.html

Log
FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren star bucks Hi everybody; who's around? yo oh :-) tibbs: you made it. hi I'm actually here, tunnelling through .ch thanks to c4chris. I'm here tibbs: cool. ain't networks fun :) ok, we can start off slow while folks start to wander in... --- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop tibbs: nothing for us to vote on this week, correct? spot is on a plane Actually nothing to report this week, yes. snakes on a plane 2: spot on a plane rdieter: ;) tibbs: ok, we can move on then. We did have a meeting and do stuff, but it's all painful and slow-moving. So, yes, do move on. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Meeting Minutes -- Do we want them posted in the wiki or on the mailing list? Rahul brought this up on the mailing list. Are we having issues with wiki size? tibbs: he mentioned that searching could be slowed down.  tibbs, I send the pointed about that to the list I'll note that posting notes to the wiki increases its size but doesn't have much of an impact on the site. why can't log files be posted to a directory, with links from the wiki? I think ml is the way to go (safer) But someties I want to sarch the logs... I've no great love for the wiki, but it does have its advantages. abadger1999, I showed a solution that IMHO should make both sides happy on the list e.g. per week meeting summaries Don't consider the wiki in this discussion, just pick the right place for you guys to put your stuff. that get overwiritten after one year if its the wiki, great, if its somewhere else, thats great too. I don't need it to be on the wiki but I would like it to be on a searchable website of some sort. imo, summaries -> wiki, full logs -> ml. abadger1999: agreed. (logs too) so long as it's easy to find the logs. I mean, the wiki is where this sorta stuff is "just expected" to be c4chris too Maybe it could go in plone post F7? plone's not really the right place for that. bpepple, c4chris, the main problem IMHO: when you search for something, you find a lot of meeting logs and not what you search for actually I guess it could be. knurd: how is it different in a ml log ? k. I'm just trying to figure out how we can have searching that can target the logs when someone requests it and doe not target the logs otherwise. /doe/does/ c4chris, ? c4chris, say you look out for something in the guidlines and search for foo I'm not sure how you can know that the meeting logs aren't what you are searching for. why not post the logs to a web directory and rely on a web search engine? c4chris, then you now often find "foo" in meetings logs and it's harder to find what you really looking for knurd: ah, ok. I thought you implied ml was better than wiki in this way Proposal: 1) Put all logs in a web directory. 2) Rely on a web search engine. that gets worse the more logs get into the wiki warren, +1 3) Put summaries in the Wiki. warren: I don't have a problem with that. sorry about being late -laptop issues warren: who would be responsible for posting them? what would the retention policy be? warren: sounds fine too cweyl: Right now I handle the posting of them. cweyl, who was responsible for doing it before? warren: That would be fine.  But we would need to write a little interface to easily upload logs. cweyl, posting logs to a web directory is easier than past.  A *bot* could do it. warren: well, if it's going to be "somewhere on the web", it's not just a matter of anyone with wiki access It could do formatting too. afk a few minutes... warren: oo, now there's an idea an auto-logging/posting bot? You tell the bot START FESCO MEETING and STOP, etc. yes such bots already exist not sure about security though. see, now that's just about perfect. they're always posted.  No one needs to do it manually, and everyone can leverage the solution yup, sounds cool Yeha, bot does auto-formatting too, which is cool. warren: Do you want to do the research to find a bot that will work for us? It does seem to be a perfect solution. Anyone against warren's proposal? Otherwise, I think we should implement it. +1 warren's proposal. +1 I'm ambivilant Hey, one less step for me in preparing the FPC minutes, so I'd be happy. bot: Meeting start - FESco bot: Meeting End +1 i am for any proposal that gets minutes posted somewhere predictable where the mechanism is not me that would be nice :) notting: :) +1 Now, can the bot count votes too? tibbs: sounds like a nice AI research project :-) So we need a team to work this out? :) sounds like the job of a blue-ribbon commission. anyone want to work on this? I'll ask (other team) about their bot. I bet their bot has no security. =) actually, with some discipline like START VOTE topic, etc... it might work Let's start with just logging? sure warren: agreed. yeah... but the way FESCo votes (screams count more than actual voting), it might not be such a great fit keep this simple so it actually happens warren: yah warren: +1. Simple to begin with. so, who will seek the bot ? Doesn't necessarily need to be a FESCo member. ;) Well, warren indicated that he'd look into what "(other team)" is using; we probably should start from there. tibbs: agreed. moving on, unless there are any objections. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Policies that need updating for merge? -- http://fedoraproject.org/wiki/PackageMaintainers/Policy Rahul also brought up this topic. We need to go through the policies we have, and make sure they take into account the merge. Anyone want to start working on this? In short, remove/update references Fedora Extras -> Fedora ? Well, obviously anything referencing "extras" needs to change. I can do some of this as well. i suspect packagedb may change more of that doucment than the actual merger When we refer people to lists, what list should be used? fedora-devel-list? c4chris: I should have some time this weekend also to look over them. tibbs: I think fedora-devel since it's an open list. the maint/lifecycle thing needs fixed yea, fedora-devel And why does that document end with an empty list of documents? o_O tibbs: good question. regardless we can start going through them and fix the inconsistencies. Anything else, or should we move on? notting: Hmm... Is that a poicy that should just be dropped? abadger1999: well, there needs to be an EOL policy. whether it should be there or not, i dunno There's no Legacy at the moment so EOL == end of our support. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Better interaction between FESCo & sub-groups - https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00372.html thl brought this up on the mailing lists. I'm not 100% sure how to go about fixing this. Well, frankly I think the way FPC works is the proper way to do it. tibbs, which way? the old, the current, or the new one? I mean, we summarize the meeting on-list and then report to FESCO as requested. tibbs, report in the meetings? I'm not sure what you mean by "the new one". tibbs: yea I think it's fine too knurd: Now you're not making sense to me. tibbs, you discussed some stuff in this weeks meeting afaics Yes, and? tibbs: problem with that is that FESCo duties will probably expand a bit after F7. To fit everything into a weekly hour meeting will be pretty tough. the "current" one afaics was: discuss and vote on each item and that#s what I dislike as it takes much time No, we report. It's up to fesco to decide if they want to vote or not. tibbs, yeah, that's what is written in my mail I just want to make that official policy so it's written down and solved once and for all for EPEL, too Oh, knurd == thl. tibbs: you report, we decide? egads. :) tibbs, yes ;-) tibbs: took me awhile to remember about his nick change also. ;) sorry for the trouble learned renaming from ender ;-) knurd, tibbs: anything else? bpepple, well, still the same bpepple, we should write it down somewhere Well, obviously FPC will report in the manner that FESCO wants us to report. I'd rather we continue this way for a while longer: keeps us better in the loop, plus it's not clear to me what we should or should not discuss bpepple, then everyone knows how to to it and what to expect But I'm not sure if it's worth me waiting after each item for a vote. tibbs, there is also something in my mail about that ;-) imo, assume ratify, unless someone asks for veto vote. rdieter, or unless one of the FESCO members yells on the list The real question is whether the summary in fedora-maintainers is sufficient, and we can skip discussing it in the meetings entirely. tibbs, I think it should be (sufficient) +1 Well, I only started reporting because I was asked to. rdieter: +1. I would rather just have FPC notify FESCo with the weekly summary, and skip it in the meeting. but that's just me :) bpepple, that's what's in my mail https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00372.html knurd: I agree with you e-mail. I'd be more comfortable if the chair would just ask "any objection to this week's report of at http:// " c4chris: agreed. c4chris, shure, that would be fine in addition, too c4chris: that sounds good to me c4chris: That's a good plan. s/shure/sure/ c4chris: that would be fine with me. Is everyone fine with c4chris's proposal? fine++ +1 No problems here. +1 +1 +1 eh, it means i have to read it rather than have it presented to me!. ok. :) +1 +1 notting: even presented, you're still reading it ;) bpepple, do we go only with c4chris stuff or mix it with my stuff? just wondering knurd: c4chris's seems fairly simple and straight-forward. bpepple, how long to wait until something can be implemented? I'm fine with doing it starting with the next meeting. no, I meant how long has EPEL to wait in case EPEL decided something does it have to wait for FESCo? same for FPC and other groups well, EPEL is different that FPC, as EPEL is a direct sub-committee of FESCo, right? cweyl, same fir FPC afaik cweyl, both are below FESCo these days hm. cweyl, that was the outcome of the "new FESCo after the merge" discussion knurd's proposal does include policy details that currently don't exist (or at least not documented). is in the archives of fab-list somewhere knurd: ok, cool... knurd: The differences I see are 1) wait period extended from 24hours to 56 hours... 2) No intervening meeting necessary. 3) Send email directly to FESCo-list, not just -maintainers. abadger1999, FESCo list is closed I can send anything there that would need to change fesco list _and_ maintainers, right? the current waiting period is much longer up to one week and one day see the FESCo schedule page I'm totally fine with c4chris idea but I really like to see it written down including those details the FESCo schedule currently reads: "A representative from the packaging committee will send a report after each committee meeting to fedora-maintainers@redhat.com for public discussion. In order to give ample discussion time, this report should be sent no less than 24 hours before the next FESCo meeting; if the report is late, the veto period will be extended by one additional FESCo meeting. FESCo may also extend the veto period if there is still ongoing discussion." that text needs adjustments knurd: agreed. How long of a grace period do we want? and should be more general, to cover EPEL or other committee's, too Personally, I think 24hours prior to a meeting works very well for what the PC does. I'm fine with 24 hours abadger1999: agreed. But EPEL and other groups could definitely have different requirements. abadger1999, that meant up to one week for EPEL abadger1999, as it meets 24 hours before FESCo that's to long knurd: when does epel have their meetings? knurd: Could be the same under the new policy.... abadger1999, not the one I porposed at https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00372.html bpepple, wednesday, same time as FESCo send out an announcement two days before FESCo meeting; the day after FESCo meeting a couple members veto it; have to wait until the next FESCo meeting for resolution. we are running late; should we sort out thise details over the next week maybe? yeah, that doesn't give you much time to get out a summary to FESCo. bpepple, exactly; and waiting one week and one day is to long :-/ But it does seem like the way FPC reports and gets things ratified is not a good model for EPEL. knurd: yeah, we can talk about this on the lists, and try to resolve it at next weeks meeting. abadger1999, why? bpepple, +1 knurd: perhaps changing the EPEL meeting time? bpepple: +1 cweyl: taht doesn't scale to all possible sub-meetings cweyl, that's a workaround, no solution notting, +1 knurd: +1 ok, moving on...... who from FESCo will take care of this? over the next week? otherwise we'll endlessly discuss again next week, which I'd like to avoid knurd: I can send out an e-mail tonight, and we can start working on a solution. bpepple, thx --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora So? anything folks want to discuss before wrapping up for this week? I got a question. Any thoughts on making the merger happen? see note I sent to fedora-devel-list make it so. How could we show Fedora to other people? go go go! f13, merge f13: haven't had a chance to read it yet. I mean if we want them to have an experience of fedora so.... what relevance do merge reviews have now that they're not needed for F7? any comments on the repotag issue from EPEL? kiluawuyu: That seems more an issue for an ambassadors meeting; this is a technical committee. cweyl, they are still valid cweyl, just think of them as cleanup reviews at this point ok~Sorry kiluawuyu: no worries. jwb: hmm... ok. do they need to be done by some point (say F8) or can they just linger on? cweyl, i think that's still under discussion or more likely undecided anyway that works. I was just looking over the huge list of them, and it made me go "hmm. why?" f13, where is the koji client? jwb, wasn't there a decision to stop the merge reviews at test4? jwb: in Extras yum install koji f13, k knurd: I believe your correct. Merge reviews really do need to happen at some point, because many of the packages are so crufty. knurd, well... they no longer are required to merge. the bugs can still be left open though, right? s/reviews at test4/& and resume them after F7 is out/ But at some point we'll need to go over even the older extras packages as well. jwb, everything still should be reviewed imho jwb, even after f7 is out I need to start reviewing again. if there isn't a "deadline", as it were, they're never going to get done. All packages reviewed <- feature for F8 tibbs: definitely :) due by Feature Freeze f13: +1 Yes, without some penalty for not getting it done, it won't get done. So the question is, what happens to unreviewed packages? f13: aren't we making that a blocker for F8. Do they go, does it slip the release date, or what? bpepple: we'll make it a feature, and decide if it is a 'must have' feature. for something like this, I don't want to slip release dates. just drop it as a advertisable feature I have some merge reviews that have been waiting on maintainer response for quite some time. and in the meantime, break out the pointy sticks. But to be fair I have some I need to respond to as well. f13: Are we allowed to play bloody havoc with the post-F7 tree? If it doesn't have a review it can't be built for devel? :-) abadger1999: evil, I like your thinking. abadger1999: oooooo nice abadger1999: unfortunately that could cause some nasty ripple effects that I'd like to avoid, effects like no buildroot can init due to missing package, so no builds can be done. Until we get the core packages done I think that's a bit tough, though. I think we can prevent the build from being PUBLISHED, but we want the build to happen and be avilable for other packages to biuld against. ok, we should probably wrap up the meeting, since we're coming up to the hour. maybe 2 stages... first, no publish w/o review until some date, then after that no build w/o date? errr, w/o review maybe bpepple will end the meeting in 30 bpepple will end the meeting in 15 -- MARK -- Meeting End
 * cweyl grabs his usual rabble seat
 * bpepple leans towards keeping it on the wiki.
 * cweyl casts a rabble handful of popcorn towards the wiki
 * notting hopes it doesn't go bang during the meeting
 * jeremy is here now
 * rdieter is back...
 * c4chris will take a look
 * knurd saw not much feedback on the list
 * cweyl thinks it should still be brought up in meetings -- the better to let someone yell
 * knurd further still would like to see the procedures written down somewhere
 * knurd votes for moving on now
 * cweyl may have missed that
 * c4chris would like to see it cleaned for F8
 * bpepple will end the meeting in 60