Extras/SteeringCommittee/Meeting-20070510

2007 May 10 FESCo Meeting

Members

Present

• Brian Pepple (bpepple)
• Jason Tibbitts (tibbs)
• Jesse Keating (f13)
• Toshio Kuratomi (abadger1999)
• Bill Nottingham (notting)
• Kevin Fenzi (nirik)
• Dennis Gilmore (dgilmore)
• Josh Boyer (jwb)

Absent

• Christian Iseli (c4chris)
• Tom Callaway (spot)
• Rex Dieter (rdieter)
• Warren Togami (warren)
• Jeremy Katz (jeremy)

Summary

• No major decisions made this week, since several of the FESCo members where at the RedHat summit.

EPEL Meeting summaries

• EPEL meeting summaries will be sent to the maintainers and FESCo mailing lists. FESCo members have 72 hours to make any objections known on a public mailing list (in this case the maintainers list).

EPEL Repotag

• Thorsten Leemhuis wanted FESCo members opinion regarding the use of repotags. The general concensus from the members present was that they didn't care for them.

Misc

• Discussed the package review for xu4. The FESCo members present didn't have any issues with the solution used for downloading the game data, since it was basically the same solution used for the codec buddy.
• <lmacken> a handfull of stuff needs to get done with bodhi. I'm locking myself in my room this weekend until it gets done :) it will be deployed this weekend.

Log

--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
<bpepple> FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren
Hi everybody; who's around?
* nirik is here.
abadger1999 is here
notting is here
jima (rabble) is kind of here.
knurd on the rabble seats for the next 35 minutes
<bpepple> Ok, we can start slowly, and see if anyone else shows up.  I sorta figured today's meeting we would be missing quite a few people.
<jima> right, RHS.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Policies that need updating for merge? -- http://fedoraproject.org/wiki/PackageMaintainers/Policy
<bpepple> I've fixed most the the pages here, except the EOL page which will need a significant rewrite.
<bpepple> What other pages are people aware of that need to be fixed due to the merge?
<f13> bpepple: Im at the summit, not here.
<bpepple> f13: I figured that.
<nirik> nothing off hand... mether has fixed a bunch, as did stickster I think...
<mbonnet> bpepple: Is there an up-to-date "how to get started with the Fedora build system" page?
<bpepple> mbonnet: I believe jwb has a page for that.  I'll try to dig up the link to it.
<abadger1999> mbonnet: jwb Started one but if you want to work on it it would be great :-)
<nirik> http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge/FAQ ?
<cweyl|work> along those lines -- plague vs koji.  Are we always going to be using plague for <= F7?  (where I'm going here is, will new contributors need to learn how to use both buildsystems?)
<abadger1999> There was also this one: http://fedoraproject.org/wiki/JoshBoyer/MergeHOWTO
<cweyl|work> if so, the docs will need to cover that as well :\
<bpepple> abadger1999: thanks.  that was the link I was looking for.
<nirik> abadger1999: yeah, thats the better one.
* jeremy might be around a little, but at the summit so not entirely paying attention
<abadger1999> cweyl|work: That's a good point.
<notting> cweyl|work: i would hope we could switch to koji for extras 6 & 5 later. maybe not 5 due to when it goes eol
<bpepple> notting: I believe your correct.  I think the plan is for FC6 but not FC5.
<nirik> will core 5/6 continue inside with brew?
<cweyl|work> abadger1999: happens sometimes ;)
notting: yeah.  that would at least narrow the window significantly
<notting> nirik: for a while, at least
<bpepple> Anything else regarding updating the policies on the wiki?  Or should we move on?
Alright, moving on.....
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- EPEL Reporting - https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00713.html
<bpepple> There weren't many replies to this so far?  What do other members think?
boy, went a little crazy with the question marks there. ;)
<notting> where would the reports go to to be reiewed?
reviewed, that is.
<cweyl|work> :)  "objections" means a "hey, lets discuss this next week" or "I nix"?
<knurd> notting, we could send them to fesco-list
<nirik> I kinda like a short "here's what happened in subgroup X" here, but I know it makes the meetings longer
<bpepple> notting: I was thinking the FESCo list.
<knurd> notting, but that list is closed for non-members
(even posting)
but that could be changed
<cweyl|work> hmm.  so the great unwashed wouldn't see the reports?
<abadger1999> I'd be largely in favor of that.  Maybe "days" instead of "business days" as per Nicolas Mailhots's mail.
<notting> as long as it's someplaced defined and obvious, and the three days doesn't take place entirely over the weekend
<knurd> but stuff in addition to fesco-list should get posted and discussed in the open
<nirik> btw: https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00298.html for knurd's last epel status
<bpepple> abadger1999: I'm fine with that also.  knurd has suggested 72 hours after sending the report.
<knurd> nirik, sorry, was a bit late with it
<abadger1999> I don't think fesco-list... it's something we want everyone to contribute to.
<nirik> no worries
maintainers-announce? with followups to maintainers?
<knurd> abadger1999, that's why I switched to hours in my latest proposal https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00067.html
<bpepple> abadger1999: which list do you think we should use? devel?
<knurd> abadger1999, fesco-list would make sure fesco members see it
abadger1999, but yeah, it should be posted somewhere public, too
and fesco members should reply in public, too
<abadger1999> posted and discussed in public.
<bpepple> knurd: agreed.
* dgilmore is here
<tibbs> Sorry, folks, I'm putting out fires this morning.
<bpepple> tibbs: no worries.
<knurd> bpepple, I suggested fesco-list and maintainers in my proposal
<notting> knurd: sounds good to me
<bpepple> knurd: I'm fine with that.
<abadger1999> maintainers is fine with me.
<nirik> maintainers is ok.
<bpepple> Ok, so summaries are going to be sent to fesco & maintainers, and FESCo members have 72 hours to make any objections.
<knurd> s/any objections/& on public lists/
<bpepple> knurd: agreed.
anyone have any objections, or should we move on?
<tibbs> Sounds good to me.
* jwb_gone is here now
bpepple has changed the topic to: FESCO-Meeting -- MISC -- Package Database - abadger1999
<bpepple> abadger1999: I have this as a standing item. anything you want to discuss?
<abadger1999> c4chris coded some of the group acl stuff.
So I should be able to tie into that for doing cvs acls.
<bpepple> cool.
<abadger1999> Haven't had time to work on it this week, but after this weekend I'll be able to devote much more time to Fedora. :-)
And that's about it.
<bpepple> abadger1999: thanks.
--- bpepple has changed the topic to: FESCO-Meeting -- EPEL - repotag
<bpepple> knurd: you wanted to get our opinion on this?
<knurd> if people have a opinion
put it's highly political
EPEL might look bad if we don#t do repotags
as such Fedora might look bad as well
<jwb> in 2 sentences, why is a repotag needed when we already have a disttag?
<knurd> I just want to make sure you guys are aware of it
<tibbs> I just wish we could use existing package metadata, or add more metadata, to represent this instead of overloading the filename even further.
<knurd> jwb, disttag is optional; disttag is not repotag
<jwb> knurd, so repotag would be required?
<knurd> disttag is "dist packages for build for"; repotag is "where pacakge comes from"
<jwb> and it's required?
<knurd> jwb, yes, otherwise it doesn#t make much sense IMHO
<jwb> and having it solves what particular problem?
<knurd> required=
<notting> no, 'why should it be required for epel'?
<jima> as spot said, it could be enforced/enabled at the buildsys level.
<knurd> s/?/?/
* dgilmore is of the opinion that repotags are trying to be forced on us by 2 people
<knurd> s/=/?/
<nirik> 3rd party repos want this so users can see "el5.epel" and complain to us about a package, etc
<wwoods> isn't this what the RPM "Vendor" tag's for?
<bpepple> is there any particular reason the 3rd party repos want this so bad?
<knurd> jima, I think tha was thimm
<notting> wwoods: yes.
<nirik> that would require end users to be able to issue a rpm query
<knurd> jima, but I'm not sure anymore
jima, I think spot has a differnt solution in mind
* jima isn't terribly enamored by the prospect of repotags, but it can be done without a huge amount of overhead.
<notting> nirik: if *enterprise* end users can't issue an rpm query, they have problems
<wwoods> rpm -qi $packagename
<bpepple> notting: +1
<wwoods> it's not that hard.
<nirik> notting: agreed.
<jima> quite true. :)
* f13 peeks in, -1 on a repotag (again).
<nirik> also, apparently this came up with extras in the fedora.us days?
<f13> repotags are fakeable.
<nirik> and was rejected then?
<f13> gpg is the only real way.
(currently)
<abadger1999> repotags: +0.  I'm for letting EPEL decide whether EPEL needs them.
* dgilmore -1
knurd reads the current discussion as "most FESCo members see no sense in repotags or don't care"
<jwb> 0.  i think it's silly, but that's EPELs choice
<bpepple> abadger1999: I believe there just looking for our opinion, not for us to decide this for them.
<knurd> jwb, as I said, I just wanted opinions
I think I got them
<bpepple> knurd: +1
<notting> -0.5. it's the wrong solution. not sure whether fesco wants to let epel be wrong on their own :)
<jwb> k :)
<abadger1999> Then -- +1... I am for epel letting it be the wrong solution if they want to.
<knurd> bpepple, I'd say feel free to move on
* cweyl|work would rather not see divergent packaging requirements between Fedora and EPEL
<knurd> cweyl|work, +1
<notting> my only concern would be how easy are they to get rid of to do the right thing
<bpepple> cweyl: +1
ok, I think we can move on.
<abadger1999> cweyl|work: Clarification -- iplementation should be done so the packaging requirements don't diverge.
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
<abadger1999> zope non-update:
<jwb> did we talk about zope?
<nirik> lmacken: any update on bodhi?
<bpepple> jwb: not yet.
<notting> one at a time please :)
<abadger1999> daMaestro/Jonathon Steffan hasn't gotten back to me about what his ideal outcome is yet.
<jwb> nirik, wait..
abadger1999, he's at RH Summit.  so is jeremy
i say we lock them in a damn room
<abadger1999> Ah.  And he probably has a revisor talk to give.
<jwb> already did that yesterday
<tibbs> I would like to write up something that separates out the salient issues there and try to address them individually.
<jwb> tibbs, i think that's a good diea
er, idea
<abadger1999> tibbs: +1
<bpepple> tibbs: I'm fine with that.
<nirik> tibbs: +1
<tibbs> I'm away this weekend while my wife walks for her Masters degree; we'll see if I have time to work something up by next week.
I'm curious if anyone read any of the xu4 review traffic.  It's an interesting case.
* bpepple hasn't.
<jwb> tibbs, i read it this morning
tibbs, i think Hans has a point
* knurd has to leave now; have fun everyone!
<jwb> thanks knurd
<bpepple> knurd: later.
* abadger1999 looking
<knurd_afk> bpepple, btw, you skipped the "EPEL?"topic itself afaics
<knurd_afk> but I send the report to the list; if you guys dislike something just yell ;-)
<bpepple> knurd_afk: no problem.
<tibbs> xu4 is basically a game engine; the game itself is "freely obtainable" (meaning you can get it from sourceforge) but we can't manage to get redistribution permission.
<tibbs> xu4 itself is free software, and will (given autodownloader and Hans's patches) download the game files for you.
<jwb> tibbs, for you or at your command?
<tibbs> Not sure, actually.
<bpepple> hmm, sounds a bit like some of the codec solutions.
<tibbs> I think it offers to do it the first time you start the game but I haven't built it myself.
<jwb> if it's user initiated that's one thing.  if it just does it automagically, that's another
<bpepple> jwb: agreed.
<jwb> bpepple, right.  which is what Hans has compared it to
<tibbs> I see little differrence between this and Codec Buddy, honestly.
<jwb> tibbs, hinges on whether it's user initiated i think
tibbs, other than that, i agree
<tibbs> Quote from the review:
When you start xu4 for the first time it will
offer to download the datafiles for you.
<abadger1999> Actuallly... I think the difference between this and something that offered to get you non-free codecs is that non-free codecs are illegal whereas this appears to be legal.
(It is free to download, just not legal for us to redistribute.)
<tibbs> Heh.
<bpepple> tibbs: If that is the case, it sounds like it would be ok in my opinion.
<notting> it's legal for *SF* to distribute it?
<tibbs> They gave redistribution rights to several people.
(Members of a fan club, basically.)
Some of the xu4 authors are members of that club.
<notting> so, fedora needs to join the club
<f13> well, fedora, and every single potential fedora user
sounds like osme people get 'distribute' rights, but not 'redistribute' rights
<jwb> notting, f13: why?
we aren't distributing the data files...
<notting> jwb: 'if we were to distribute it'
<nirik> jwb: we need to allow people who do distros based on fedora to redistribte the bits, right?
<jwb> notting, which nobody is suggesting we do
nirik, no... fedora isn't distributing the data files
i'm not seeing a problem here
nirik, this is identical to the situation we had with iwp2200 in fc6
we had a driver for it, but no firmware (because firmware wasn't in the guidelines at that point)
<nirik> how so? this isn't firmware, and we aren't shipping the non distributable data.
I think it's much more like codec buddy and xtide
<jwb> that's what i'm saying...
xu4 is akin to the "driver" and the data files are akin to the "firmware"
there was no problem in fc6 with just shipping the driver
<tibbs> More from the review:
...
I created a python gtk gui app todo the
downloading, which will explain to the user that a download is necessary, why
and asks his permission todo the actual download.
<jwb> that's even better
<tibbs> So really, Hans is taking every precaution here.
<jwb> i see no issues with this
* bpepple agrees.
<nirik> yeah, I would think it would be ok... (IANAL)
<bpepple> anything else regarding xu4?
<abadger1999> jwb: +1
<bpepple> f13: Is the cvs branching going to be next Thursday?
<f13> theoretically
<bpepple> Anything else people want to discuss before we wrap up for this week?
<tibbs> Nothing from me; I'll update the xu4 review ticket.
<bpepple> ok, /me will end the meeting in 60
* bpepple will end the meeting in 30
<jwb> wait
quick one
did i miss the broken upgrade paths thing?
<tibbs> (screeching tires)
<jwb> just a note that we need to remind people to get their f7 builds tagged with f7-final
<nirik> once we have a rawhide we can see how bad it is...
<bpepple> jwb: I'll add that to my summary.
<jwb> bpepple, thanks
<jwb> nirik, yeah
<nirik> I hope not too bad...
<bpepple> jwb: anything else?
<jwb> not at the moment
<nirik> is lmacken around for a bodhi update? thats the only other thing I can think of.
<bpepple> nirik: is he at the RH summit?
<nirik> not sure
<jwb> bpepple, no he's taking exams
<nirik> ah... ok. nevermind then
* bpepple will end the meeting in 30
bpepple will end the meeting in 15
<bpepple> -- MARK -- Meeting End
Thanks, everyone!
<lmacken> gah
i always get back from class right when this meeting ends :(
<bpepple> lmacken: anything you wanted to bring up?
<nirik> thanks bpepple
<nirik> lmacken: any update on bodhi? looks like we will probibly need it for epel sooner rather than later.
<lmacken> a handfull of stuff needs to get done with bodhi.  I'm locking myself in my room this weekend until it gets done :)
it will be deployed this weekend.
<nirik> awesome! :)
<bpepple> lmacken: cool.  I'll mention that in my summary.
<nirik> if you need any assistance testing, I should be around this weekend...
<lmacken> sounds good.. I'll need as many people to bash on it as possible