Extras/SteeringCommittee/Meeting-20070118

= 2007 January 18 FESCo Meeting =

Present

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

Absent

 * Andreas Bierfert	(awjb)

EPEL Update

 * Most of the outstanding issues are waiting on RedHat IS.
 * It was brought up that EPEL should have separate guideline (e.g. latest and greatest vs. a more stable approach), and that the EPEL community should make this decision.

Opening Core

 * FAB accepted thl's proposal on the FESCo/Core cabal merge. Welcome to FESCo Jesse & Bill!
 * f13, notting, and max will be added to the fesco-list.

FESCo-successor name issue

 * It was decided to keep the name 'FESCo' after the Core/Extras merge. thl will send an e-mail to the mailing lists announcing this.

Encourage co-maintainership

 * thl is going to send an e-mail to the mailing lists with his proposal.

Firefox updates in stable often breaks packages

 * Will look at automating rebuilds of effected packages, though this won't before F7.
 * For now, bpepple is going to form a group with other maintainers with packages effected by Firefox updates so rebuilds are handled more quickly.

Disallow cvs-import for everything but the initial import

 * It was discussed how using cvs-import quite often overwrite previous changes done by other maintainers.
 * The initial thought on how to fix this was to modify cvs-import to prevent this behavior, but many issues need further discussion before acting. Further brain-storming will occur on the mailing list, so as not to waste meeting time.

What do we want like to see in the approved-message in a review bug

 * People seeking sponsorship should definitely use checklist of items reviewed, so there is documentation of the knowledge of the packaging guidelines.
 * If there is a discussion on issues in the review, then an APPROVED only is probably ok.

Syslog-ng Patent Problems

 * RedHat Legal is currently reviewing this issue.

Misc

 * FESCo meeting in the future will take place in #fedora-meeting beginning on 2007-01-25.

Log
--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process - starts in 5 minutes. c4chris is here I'm just wolfing down something unhealthy. bpepple is going to grab a pot of green tea quick. hmm, coffee... FESCo meeting ping -- abadger1999, awjb, bpepple, c4chris, dgilmore, jeremy, jwb, rdieter, spot, nirik, thl, tibbs, warren Hi everybody; who's around? spot is here still here :-) me too :-) here here -- but I have a sick kid so I may abruptly disappear Ok, we'll start slowly. --- bpepple has changed the topic to: FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update still waiting for internal RH IS on pretty much everything right now need to get a location to host the master mirror I need to work out who to bug for bugzilla notting: any word nope whatcha need in bz? we're just waiting on RH IS right? notting: a sync the same as we do for extras a new product and components notting: have you spoken with the mirror admins yet to see if epel will be picked up? sorry for being late, we have a storm here the_conley thl dgilmore: no. was waiting for confirmation on the location from IS first notting: :) bpepple: so there is not really alot to report right now dgilmore: ok, thanks. I can lend my pointy stick if anyone needs it. (: --- bpepple has changed the topic to: FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- EPEL doesn't really lift of -- what do? bpepple: i think once we get those last bits in place things will take off dgilmore: I tend to agree. We can probably drop this item. yeah, once people can use the packages there will be a lot more interest, I suspect. dgilmore, what about policies how to manage packages in EPEL? if you build it, they will come. e.g. latest and greates vs. a more stable approach? We've been waiting on a few specific parts for literally months. packages peobably need some guidelines how to manage those thl: I would think it would have to be a stable approach. we need to be much more stable bpepple, sure :) but the packages need to know that i dont think we want to offer RHEL type guarantees imo, up2maintainer. rdieter, I disagree we can't do what rhel4 does, that's umteen years' worth of backports,support to try to offer. Is there somewhere on the wiki we should be have packaging guidelines for EPEL? rdieter, having a repo that is in parts maintained with a stable approach and in parts with latest and greates is the worst thing we can do quite often the latest wont build on RHEL so it cant be thl: worksforme wrt kde-redhat... (: rdieter, sure, but we should not update to the latest if there is no need to IMHO thl: +1 thl: upstream rarely supports anything non-latest either, then what? then don't update? upgrades, just for upgrades' sake is plain silly, regardless of the target (extras or epel) thl: no updates -> no bug fixes then either? bug fixing is good We can really only have guidelines, shoulds and should nots. It will be difficult to enforce things once a package is accepted. that's why I said up2maintainer mmcgrath: agreed. maintainers are likely the one best informed to make that hard decision, between supportability, bug fixes vs backporting, etc... notting: that's what some people seem to want (I don't, personally) that's my $0.02 anyway. We should probably treat it separate from Extras and let the EPEL community decide as we go along. mmcgrath, +1 mmcgrath: +1 common sense rears its ugly head once again. (: but we should work out some guidelines soon IMHO I think we should encourage the end (bug fixing) but leave the means (upgrade / backport) to the maintainer's judgement c4chris: and that's different than Extras' existing policy, how? (: c4chris: sounds fairly sane Ok, anything else we need to discuss regarding this? bpepple: nope ok, moving on. bpepple, nope Regarding speed: rdieter, plenty of new features get added in Fedora --- bpepple has changed the topic to: FESCO-Meeting -- Opening Core -- rdieter, jeremy, warren -- FESCo future? Did the board acceppt what thl proposed? thl: I'll just copy the extras guidelines verbatim right now and we'll change stuff as we need to. bpepple: rubber stamp of approval, "just do it". (: rdieter: good deal. --- bpepple has changed the topic to: FESCO-Meeting -- Opening Core -- rdieter, jeremy, warren -- Should we put f13, notting and max on the fesco-list Should we give people who have packages in EPEL some room to work? I think having a updates system for release versions will help a lot... so people have to figure out what reason they are updating for... bpepple: Any drawbacks? +1 for adding notting, f13 and max to the fesco list abadger1999: I don't see any. +1 +1 (was my idea in case somebody wonders) +1 bpepple: +1 +1 +1 +1 do it Ok, consider it approved. --- bpepple has changed the topic to: FESCO-Meeting -- Opening Core -- jeremy/warren -- plans for the mass review seem to be really needed soon! abadger1999, --verbose on th eroom thing ? bpepple, can we please discuss the FESCo-successor name issue after this topic? I forgot to put it on the schedule... (sorry) Maybe: "Join the EPEL SIG and start discussing these Policies" thl: sure. bpepple, yes, I need to post that bpepple, nothing new to report yet, just move forward Or some such. ok, we'll move on then. abadger1999, ah ok. Yes, that would be good --- bpepple has changed the topic to: discuss the FESCo-successor name issue thl? FTC wasn't acceptable? Basically give the EPEL contributers notice that they can start making their own technical decisions. well, what names do people like? Cabal! spot thinks FESCO is fine, its easy enough to make it keep working. abadger1999, nope, I don#t want cabal Fedora Technical Cabal no reason to change, move on. spot, what does it stand for? warren: :-) Federal Trade Commission FEdora Steering Committee Leaving it FESCo would be easier. abadger1999, look up cabal in the dictionary -- "secret" is found there quite often how about "Gnome desktop"? :) +1 whatever I honestly don't care as long as I can type it. the_conley thl tibbs: so not klasdfjalksdfj ? thl: Yeah -- it's kind of a long-running community vs Red Hat joke. spot, "FEdora Steering Committee" can be easily confused with the board :-/ jeremy, see, that was easy to typy.... once abadger1999, well, I got the impression some people meant that seriously :) thl: i don't see "Board" in there anywhere? :) <-- Sonar_Guy has quit ("Sonar_Guy has Left the Building!!") thl: has FESCo *ever* been confused with the Board (not afaik anyway). it didn't get confused with the board when the E stood for Extras FeDiStCo -- Fedora Distribution Steering Committee ? i think it will be ok now rdieter, I'm just playing devils advocate ;-) spot: should we do a quick vote to see if we should keep FESCo? +1 for FESCO If it's confusing we could change it to Fedora Engineering Steering Committee or some other unwieldy thing. sure +1 +1 to FESCo abadger1999, +1 Otherwise FESCo as FEdora Steering Committee has my +1 +1 to keep fesco... path of least resistance. +1 for FESCO -- Fedora Engineering Steering Committee ok, I don't see anyone voting against it, so we'll remain FESCo. FeSCo <_andy_at_work> +1 for fesco, but I think the naming of the commite isn't significant vs. real work bpepple, k, I'll post to the list thl: great, thanks. --- bpepple has changed the topic to: FESCO-Meeting -- Encourage co-maintainership -- c4chris, thl -- thl wrote something up; It's not completely finished, but do people like it? _andy_at_work: if we dont manage to argue over pointless things like naming, how will we ever defeat debian? just FYI, I slightly enhanced the policy proposal one hour ago but I'd like to get feedback soon thl: I just finished reading it before the meeting, and thought it was good. Haven't read your revisions, though. I'll probably send it to the list if I don#t hear anything from the other FESCo members soon that okay for everybody? thl: sound good. I'll probably send it out on Sunday/Monday looked good to me. The package db would help a lot... but that will come with time. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- firefox updates in stable often breaks quite some packages (galeon, liferia, ...); do we need some kind of task force that steps up to rebuild the stuff? Is this something the QA SIG should look at handling? <_andy_at_work> spot, is it rhetorical question? _andy_at_work: yes. ;) possibly... there is going to be a gap until the core/extras merge tho. ie, new firefox comes out and we have to wait until it's pushed before we can build extras stuff. There will be a gap even after the merge. in theory after the merge someone could build while firefox is just in needsign and hasn't been pushed... The only real way to eliminate it is to not push the distro if it has broken dependencies. of course that would requre notice that it's there. nirik: there will be no need for a gap once merged I think the most important thing to do for now is: have a group that rebuilds all depending packages as soon as possible right now we have no choice we need it to break  before we can build against new updates e.g. a list in the wiki with packages that need a rebuild and someone that kicks those rebuilds perhaps we could get all the folks that maintain those affected packages to band together to do it? nirik, +1 nirik: +1, since I'm one of those people due to liferea. dgilmore: yeah, but if firefox gets pushed before other packages notice it's been updated there is still a gap where packages are broken. a small gap is better than what we have now nirik: yes  unless we design the new build system/push scripts to handle it thl: agreed. shall I mail all those folks and see if they are interested in forming some group to do it? or bpepple, do you want to? Yeah -- for the generic case of missing notification... libburn/brasero also happened in the last week. someone just needs to create a list in the wiki, send some mails to the maintainers IMHO nirik: what id like to see is automated rebuilds for brokeness like that dgilmore, that should be a long term goal, nothing for now IMHO nirik: That sounds fine. If you don't want to send the e-mail, I can. yeah, but it's hard to say if the depending update breaks the package in some way... thl: it shoudl be a short term goal. i.e we should put it in soonish thl: +1 dgilmore, well, I requires massive changes to the buildsys afaics dgilmore, I don#t think that will be easy it probably wont be in for FC-7 but hopefully soon after and we have a lot to do already... I think drjeff made a list of all affected packages for firefox. thl: we are getting a whole new buildsys Well there's a bomb I don't recall being dropped before. How about we plan on implementing nirik's suggestion, with the plan of eventually automating it sometime after F&? dgilmore, then we should ask those guys that build it to consider adding that feature -- I don't even know who those guys are -- could you manage that maybe? s/F&/F7/ bpepple, +1 thl: im not sure who it will be yet. probably dcbw, f13, me and a few others f13: how is brew/wart's code release comming along tibbs: The release of brew as open source. bpepple: ok, I can send the email or you can, I don't care. Do you have drjeff's list of firefox dependent packages? bpepple: thats fine dgilmore, well, then we should all try to keep it in mind for now :) nirik: no, I don't have the list. abadger1999: There's a difference between brew being released and all of Fedora switching to it. Ok, let's move on. tibbs: It's been mentioned a couple times but it might have been more tangential. tibbs: True. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- disallow cvs-import for everything but the initial import? cvs-import would self-enforce this? Well, I'd vote for it. what was the issue here? that cvs-import is overwriting changes that were made in the repo? maintainers not paying attention nirik: correct. It's pretty much incompatible with development by multiple people. nirik, that and not looking at the diffs before committing What are we trying to accomplish? ok, I'm all for stoping that... warren: It would be nice if cvs-import didn't allow anything but the initial import. With CVS at least you can't commit unless your tree is up to date. cvs-import just overwrites everything. yes, so cvs-import would be modified to self-enforce that? I feel uncomfortable making mandates, would/could it be sufficient to strongly discourage it? warren: that's what I would like to see. rdieter: No... But maybe we couldmodify cvs-import?  [backroom noise] The java guys will hate it People can always edit the script or just do the steps themselves. rdieter, people who don't pay enough attention in order to screw up cvs-import would also ignore a mandate. rdieter, err.. ignore a discouragement. ok, fair enough. i would be happy if cvs-import at the least did a diff and show what was going to change dgilmore, +1 dgilmore: And a cvs update? abadger1999: yeah I don't like cvs-import after initial import. There is no meaningful cvs comment. of course if we change it in cvs-import that means people will need to update to that new version to get the check. ;) the main problem is think like the one packager who put a .repo file in his package  but even a diff might not stop him warren: very true Just give folks who really want it an environment variable to set to disable the check. by default, disable it warren: but if we change how cvs-import works  so it does updates and diff's  etc  then we could also get a better changelog Is anyone opposed to disallowing cvs-import for everything? bpepple: -0.1 I'm definitely for modifying cvs-import Like rdieter, not sure about mandating "you must not use this script for updates" I like the "cvs update" idea, and tibbs idea too modifying cvs-import is fine with me, who will do it though? :) Maybe this is something we can brain-storm about on the mailing list? I'm for modifying the cvs-import, but we probably need to decide what that exactly entails. and exactly what is, and is not reasonably (technically) possible. rdieter: agreed. Perhaps some additional scripts to make maintenance easier would also help. bpepple, sounds fine Some people use cvs-import to propagate a package unchanged between branches. Another tool to do that would be helpful. tibbs: maybe we need to expand upon the scripts we offer Ok, I'll send an e-mail to the list, and we can work from there. cvs-clone cvs-update Anything else on this before moving on? --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- "what do we want like to see in the approved-message in a review bug" -- https://www.redhat.com/archives/fedora-maintainers/2006-December/msg00214.html bpepple: something that shows a review happened if there is a disccussion on issues then an APPROVED only is probably ok dgilmore: agreed. just saying 'APPROVED' is sufficient to me. if there is no need for a discussion something s/is/isn't/ nirik, yes nirik: Pretty much my view. nirik: agreed. I still this we should encourage new contributors to post more then approved the more relevant info in the review the better  it will help new people see what they need to do If you want to gain further trust for being knowledgable about packaging, you have to document your knowledge. tsk tsk
 * jeremy is around
 * nirik is here... time to get another cup of coffee.
 * dgilmore is here
 * thl now around
 * notting wonders if this will then stray into the somewhat different upgrade/backport policies currently for core and extras :)
 * warren back
 * dgilmore like FTC
 * bpepple thinks FTC is acceptable.
 * dgilmore is fine with whatever
 * nirik really doesn't care.
 * c4chris has no strong opinion, but keeping FESCO kinda makes sense, and is easy...
 * jeremy abstains
 * nim-nim cheers abadger1999
 * nirik things checklists should be encouraged, but not required. People seeking sponsorship should definitely be encouraged to use checklists to show what they checked.
 * spot thinks it should be obvious that i agree with nirik on this
 * nirik hangs his head in shame for not doing his full checklist on the updated package in the recent postgresql-dbi-link package. ;(

if something is not applicable for a review leave it off the checklist not required. dgilmore: or say n/a we dont want too much noise dgilmore: agreed. Is there anything else people want to say regarding this topic? Or should we move on? move on --- bpepple has changed the topic to: FESCo-Meeting -- MISC -- the "syslog-ng patent problems" https://www.redhat.com/archives/fedora-maintainers/2007-January/msg00015.html as somewhat of an aside, when checking core packages we should suggest reviewers look at the open core bugs for the package. Might be some good things worth addressing when moving the package in. nirik is on fire! I'll add that. nirik: fear the kernel review! heh yeah... might take until fc8 to just read all the bug reports. ;) So, patent problems. Doesn't this need to go to RH legal? I think hinting at patent problems is nto really our concern. Has legal had a chance to comment? until there are actual known problems instead of just threats, I dont' think we need to take heed. f13++ Is the plan to switch wholesale to syslog-ng? the plan is to evaluate syslog-ng and if favorable, switch. f13: +1 Adding it to the repo can't be a problem; using it as a fundamental part of the OS might warrant more careful concern. Ok, I don't think there is much else to add to this now, so we can probably move on. though i switch all my machines to syslog-ng first thing What about our committment to only ship open source software? tibbs: its in extras now is it not opensource? Is it somehow not open source? patents! PATENTS! BOO SCARY! If the patent is being granted only to implement the standard then it's not opensource. but do we have any information about said patent, or when said patent would be applied? I know that this is in the legal queue, I'm not sure if it's been discussed with legal yet perhaps the folks who will evaluate if it should replace syslog wil look further into it? abadger1999, FOSS is a licensing issue. the software in question is FOSS abadger1999: Until legal has looked at it, I don't think there's much we can do right now. bpepple, right we can continue to evaluate it on a technical level. f13: agreed. f13: Not really. I read the "granted to implement the standard" thing on another blog so no idea of wha the company actually intends. abadger1999, take RCU. it's patented. yet it's still open source maybe even do a test release with it. bpepple: +1 Moving on...... --- bpepple has changed the topic to: FESCo-Meeting -- MISC -- kernel-naming https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00581.html so right now kerenl is named on the tarball I think this is waiting to hear back from davej, right? and he's going to talk to linus/alan? yep. last I heard, davej has not reported back from his fact finding mission correct he's still in .au though, so it's not too surpising... jwb, didn't IBM grant that patent? f13: Ok, we should probably skip this till next week then. warren, yes but my point was it's irrelevant to the _license_ of the software --- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop jwb, nod ok. http://fedoraproject.org/wiki/PackagingDrafts/Conflicts was approved via email vote barring veto from FESCO, i'll send it out to fedora-maintainers today so everyone knows how it works spot: It seemed fine to me. Well, by policy FESCo gets another week to comment. tibbs: sure. no rush on my part. Has everyone in FESCo read it? jeremy hasn't read it yet fine here ... I thought policy was a week or until the next Packaging Meeting.. (has to do some research now) s/(has/(I have/ Anything else from the Packaging Committee? abadger1999, we changed that slightly some months ago bpepple: we're working on trying to resolve the jpackage naming but we don't have anything final to report there thats it from the PC spot: thanks for the update. --- bpepple has changed the topic to: FESCo meeting -- Maintainer Responsibility Policy -- bpepple this is me. I'm going to send an e-mail out to f-e-l tomorrow looking for additional suggestions. and hopefully have something to present at next weeks meeting. This won't include responsibilities for EPEL branches, right? tibbs: correct. tibbs: do you think we should address EPEL in this? Perhaps only to say that the policy doesn't completely apply to EPEL. bpepple, no, I don't think so tibbs: agreed. I'll add that to the wiki. we should probably work on seperating EPEL and FEdora a bit more now that Core and Extras merge thl: agreed. bpepple: what is this policy? And since we're merging, we're suggesting policy for RH employees too? (Not a bad thing, just something to consider) f13, look in the wiki ;-) Might be worth looking at the debian version of this sort of thing and see if they have any good ideas to add. ;) f13: http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy f13, then please also take a look at the co-maintainer policy proposal ;-) Moving on...... --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora Extras Anything people want to talk about? are we meeting in fedora-devel next week? or here? where do we reconvene? bpepple: ok, that seems reasonable. nirik: thanks for reminding me. Someone needs to kick chanserv first, though. gah, nirik must've a red keyboard... Does anyone have a problem with meeting in #fedora-devel next week? c4chris: ? I'm wondering if should have a fedora-meeting channel for meetings could be used by different projects nirik, you type much faster than me... an red cars are the fastest... ;-) thl: might be better bpepple: i asking in #fedora-devel on monday if it was ok and no one said no thl: that might be a good idea. fine with me, but tibbs is right that we need to kick chanserv gahh bpepple i asked thl: interesting, then normal channel business wouldn't have to be put on hold. Can we get the ops issue figured out as well? I don't want to discourage people from using #fedora-devel for development discussion thl: no overlapping meetings tho. wejust need to annouce the meetings in the approciate channel to make sure people know about it dgilmore: yeah, I saw that. Thanks. thl: that works what is it about chanserv ? It won't let you change the topic. chanserv won't let you change the topic in fedora-devel oh I like thl's proposal, does anyone object to holding it in #fedora-meeting? thl: +1 c4chris: someone with admin privliges needs to fix that bpepple:  nope someone should register the channel bpepple: +1 someone should register that channel fedora-meeting sounds good, as long as the ops/chanserv is seutp ok on it. dgilmore, :) Another tab to keep open, or remember to open before the meeting. That's the only real downside. tibbs, I hope to get rid of #fedora-board then again :) somebody already owns it anybody here? I hope the board could use it, too warren: not me. personally, I'd like to see a switch to jabber-based chat rooms thl: +1, I like #fedora-meeting gregdek owns it warren, gregdek owns it makes it easier to remember where to go. warren: gdk owns it let's check with gdk, and see if he has a problem with us using it for our meetings. thl: the board can easily switch to it jcollie, what? jeremy, I'd like that btw, where do we discuss policy changes for the near future? fedora-devel (open), fedora-maintainers (closed), fedora-extras (some red hat people might not be around)? jwb, jabber/xmpp can do chat rooms similar to IRC... thl: fedora-devel For now, let's plan on meeting next week at #fedora-meeting. Is that ok with everyone? jcollie: the question is, why? yep ok bpepple, +1 +1 bpepple: +1 +1 +1 bpepple: +1 bpepple: +1 Ok. Anything else people want to discuss before calling it quits? bpepple: not from me f13, jwb, IRC is so 20th century, plus no dealing with chanserv/nickserv freenode.net vs. gimp.net or whatever jcollie: +1 jcollie, and enforcement? jcollie, OTOH, barrier of entry, when everyone already uses this. bpepple will end the meeting in 15 -- MARK -- Meeting End
 * f13 agrees with nirit's post.
 * bpepple tends to agree with f13 on this.
 * jwb is finally here
 * thl likes it
 * nirik just as scanned it, but it looks ok from a quick glance.
 * dgilmore doesnt
 * jwb thinks it was a chanserv info race :)
 * bpepple will end the meeting in 60
 * bpepple will end the meeting in 30