From Fedora Project Wiki

< Extras‎ | SteeringCommittee

Revision as of 14:13, 24 May 2008 by fp-wiki>ImportUser (Imported from MoinMoin)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

2007 April 26 FESCo Meeting

Members

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)

Summary

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 <group> at <url>".
  • 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

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