Extras/SteeringCommittee/Meeting-20070308

= 2007 March 08 FESCo Meeting =

Present

 * Brian Pepple 	(bpepple)
 * Jason Tibbitts	(tibbs)
 * Christian Iseli	(ch4chris)
 * Rex Dieter  	(rdieter)
 * Toshio Kuratomi	(abadger1999)
 * Kevin Fenzi 		(nirik)
 * Dennis Gilmore	(dgilmore)
 * Jesse Keating	(f13)
 * Warren Togami	(warren)
 * Tom Callaway		(spot)

Absent

 * Bill Nottingham	(notting)
 * Jeremy Katz		(jeremy)
 * Josh Boyer		(jwb)

Closing fedora-extras mailing list

 * FESCo approved the closing of the f-e-l. thl will will work on this.

Sponsor Nominations

 * Jarod Wilson was nominated and accepted as new sponsors.

Packaging Committee Report

 * FESCo approved the Packaging Committee's guidelines regarding:
 * Firmware packaging guidelines: https://www.redhat.com/archives/fedora-packaging/2007-February/msg00292.html
 * http://fedoraproject.org/wiki/PackagingDrafts/UsrConfigs

fedora-usermgmt

 * FESCo had a long discussion on this. RedHat BaseOS folks need to be involved.  It is to late to have a solution for this by Fedora 7, will target Fedora 8.

Tracker Bugs

 * The main blockers FE-NEW, FE-REVIEW, FE-ACCEPTED will be changed to flags.

Log
FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren  I'm here. Hey everyone, who's around? nirik is here. I'm here I'm here Ok, let's start slowly... --- bpepple has changed the topic to: FESCO-Meeting -- sponsor nominations -- Jarod Wilson, nominated by Dennis Gilmore I noticed quite a few '+1' for Jarod on list. Any here have a problem with making him a sponsor? +1 from me... anyone who can do a pretty good job dealing with the mess that is beryl gets my vote. ;) +1 here also. +1 +1 +1 +1  nirik: good point :) Ok, I don't see anyone giving a '-1', so Jarod is a sponsor in my opinion. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- closing fedora-extras list thl mentioned on the mailing list that he wanted FESCo to give a vote on whether to close the f-e-l list. +1 to closing, once we fix all the automated reports that go there +1 here also. f13: +1 closing +1 +1, yeah, need to make sure the reports all go to devel or whatever.  will we be automagically subscribing those on -extras but not on -devel to -devel? Please no automatic subscriptions. no. Possibly we could invite them? cweyl|work, mailman inites was the plan (see the list discussion) tibbs: +1 yes, invite  thl: ok, cool. Best to just send one announcement and let people deal with it if they want. tibbs: an invite helps, it's reasonable IMHO thl: I don't see anyone in favor of keeping f-e-l open, so consider it approved. ok, so who can do this? someone in infrastructure ready to drive it forward? bpepple, thx nirik, I'll poke the neccessary people just remind me if I'm to slow thl: excellent. Thanks. --- bpepple has changed the topic to: FESCO-meeting -- MISC -- garbage-collector rpm -- https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00089.html nirik, I need warren first, as he is the list admin for fedora-devel Speak of the devil. tibbs, :) thl: also, can you mail mschwent about the reports? might also mention to him that we should like to see them on every push? warren: can you do the auto-invite of all folks currently on fedora-extras and point them at fedora-devel ? warren, you were traveling atm, or am I wrong with that? thl, I got extremely sick while traveling and went home yesterday. I'm a bit worse today. warren, k, it's not urgent; ping me please when you are okay again adn have some spare minutes bpepple, I'd say move on please thl: np thl, what do you need? warren, we need to discuss some details for closing fedora-extras-list --- bpepple has changed the topic to: FESCO-Meeting -- Core Package Review Process - Tracker Bugs -- warren not sure about garbage collecting.  It's certainly desirable to inform people of unmaintained software but I don't know if we actually want to remove it. thl, ah, ok that can wait. but we don#t have to do that now; it's not urgent --- bpepple has changed the topic to: FESCO-meeting -- MISC -- garbage-collector rpm -- https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00089.html abadger1999: agreed. yeah, the garbage collection package has upsides and downsides. nirik, agreed we don't want to remove people's locally installed or other repo packages. Thats evil. but doing something IMHO is better then doing nothing in this case  I'd definitely be irked if I upgraded a box and suddenly a package I was using "disappeared". I can only imagine what an end user would think... then a yum plugin would be best afaics cweyl: even if that package is orphaned and/or no longer maintained?  (just my $0.02) rdieter: yes. rdieter, +1  c4chris: it's a great way to shoot other people in the foot, as well :) yes I'd be more afriad of having orphaned packages myself, but that's just me. rdieter, +1 I really don't like the garbage collector idea as a package. how do other distros deal with this? yum list extras + some local thought on what to do with it. anyway, if it's disliked let's ignore it but I'd like to see the problem solved... a yum plugin would be ideal, but I have no time or skills to write it atm fwiw, I like it (for lack of a better solution) think about what anaconda does  rdieter: if the package still works, I don't really care if it's maintained or not. if I did, I'd either go maintain it or figure out some other way to achieve what I needed...  but I don't like the idea of a package going away just because someone else has decided I don't need it anymore I don't like the idea of removing somebody's software just because we no longer ship it wouldn't people be upset if anaconda removed things during an upgrade that broke deps? the one that I had recently is bmp-xosd... bmp is no longer shipped, so I disabled that subpackage, but now people with it installed get a broken dep on upgrade. Should I add a Obsoletes? doesn't mean they don't want to keep using it. anaconda just ignores those right? forcefully ignores and now you may have broken deps, yuck. Maybe some kind of plugin that notified users of packages that weren't being maintained? bpepple: yum list extras bpepple: yeah, that could get nasty depending on the interface tho. bpepple: sure, but what about *now* until such a mythical plugin exists. as a small step, perhaps logwatch could add a 'yum list extras' report... but I bet most users don't read logwatch reports. "package-cleanup --orphans" does most of the stuff we need maybe we could steal some ideas there? rdieter didn't know about package-cleanup --orphans (cool) or for now: tell users to run it before and after a big dis update? s/dis/dist/ I like that much better what package is that in? yum-utils? c4chris, well, but it doesn't solve the problem at hand nirik, I think so well, there are problems with that  thl: I'm still not sure that it's an actual problem :) it'll whack anything it doesn't find in your configured repos, so anything you've hand installed... boom  (it == orphaned packages installed on someone's system) cweyl|work, it seems it is one for a lot of people... cweyl|work, maybe it would be less a problem if the yum errors would be easier to interpret if those packages break, users get mad, report bugs which are ignored. thl: somehwat nature of hte beast doing continual upgrades vs fresh installs.  thl: and the other way for others :) I might feel more comfortable if it were optional. errors easier to interpret? f13, sure what errors? skvidal: I'm assuming broken deps due to orphaned package Both anaconda and yum refuse to choose what to do about this, which is probably wise? (Except anaconda and yum refuse in different ways.)  e.g. this hypothetical "orphan death package/plugin" isn't required by any base package on any system, so it can be removed easily. so, bottom line is that a fedora-orphans package doesn't seem like something we want now without a lot more thought... so perhaps we shoudl move on?  nirik: +1 for more thinking :) cweyl|work: I'm strongly against using a package for this. skvidal, if a yum updates fails because locally installed package foo was in f6, but is not in f7 anymore, and you aborts because foo has a dep that is not fullfilled by f7  f13: you won't get an argument from me :) cweyl|work: UI in add/remove software and/or yum to show you orphans and let _you_ decide what to do with them is best IMHO skvidal, even I get sometimes confused by the yum output skvidal, but afaics it's actually the putput from rpm f13: +1 yes, it is  f13: +1. f13: yeah, perhaps in anaconda too someday for upgrades? f13: +1 Ok, we should probably move on, since this is going to need more discussion. sgtpepper has quit ("switching from wireless to cable...") nirik: maybe, but that would require kickstart love to do SOMETHING non-interactively good point. need a 'remove orphans' or 'ignore orphans' flag perhaps? anyhow, talk for another day --- bpepple has changed the topic to: FESCO-Meeting -- Core Package Review Process - Tracker Bugs -- warren nirik, the problem is that somebody needs to code the stuff; and I see nobody doing this nirik: thl probably should be driven through yum-devel and anaconda-devel lists. f13, agreed warren must have stepped away. moving on.... --- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop Did everyone see the summary? tibbs: Thanks a bunch! tibbs: yup, thanks for the summary. yeah, thanks tibbs. There were two items I believe we need to vote on ratifying today. So there are two issues up for ratification. Firmware packaging guidelines: https://www.redhat.com/archives/fedora-packaging/2007-February/msg00292.html Not much there, really. +1 +1 +1 +1 +1 +1 Fedora board decided they should, so we just have to define how. +1 f13: Yes, the PC doesn't want to wade into that quagmire. indeed If anyone has any comments about the proposal, please let us know before next Tuesday, when this will get written into the guidelines. Next was this: http://fedoraproject.org/wiki/PackagingDrafts/UsrConfigs Disallowing %config under /usr. I'll quote the entire proposal: Don't use %config or %config(noreplace) under /usr. /usr is deemed to not contain configuration files in Fedora. +1 from me... it does affect a merge review I am currently doing, but I think it's the right thing to do (a2ps) ;( +1 +1, seems reasonable to me. +1 (though kde is currently borked wrt this) (though fixable) +1 as long as kde is fixed +1 I think everything is fixable with symlinks at least; that's rather ugly, but most of PC thinks %config in /usr is uglier. +1 How does that effect upgrades? (replace file with a symlink) it's the replace dir's with symlinks that get ugly. warren: file <-> symlink isn't a problem. I think an rpm expert should answer that question; I'm not one. In any case, symlinks are just one solution. I replaced some files in squirrelmail with symlinks to move configs out of /usr before. There were no complaints. But I also suspect there are no users. =) +1 So I suppose if there are dissenting opinions or finds something that would hold up implementation of this guideline, please let fedora-maintainers know so that PC can address it. tibbs: thanks. Those were the only guideline proposals. Of interest, PC will hold its meetings in this channel starting Tuesday. And #fedora-packaging is gone. That's about it. tibbs: cool. what time do you usually meet? I have to convert to UTC... Tue 17:00 BTW, is the perl-devel thing something we should discuss? It seems controversial. 9AM Pacific Time... It was Daylight savings adjusted.. But I don't know now that the US has changed its DS laws... warren: not really relavent here yet Crap, that's right; we need to decide if the meeting time stays at 1700 or shifts an hour to deal with US DST. --- bpepple has changed the topic to: FESCO-Meeting -- EPEL -- fedora-usermgmt? I hate DST. Is this really something for FESCo right now? fedora-usermgmt upsets people, but he's the only one actually trying to solve the problem. warren: +1 If people don't like fedora-usermgmt, could we PLEASE figure out a real and standard solution? it seems to be a general problem afaics I don't want to wade into the usermgmt debate, but I do wonder if there's some easy way to just remap users post-installation. thl: +1 thl: it's not, I just threw it there so I would remember. yes, EPEL brought that topic up, but it should be soled for Fedora and EPEL bpepple, k :) We don't have to figure out usermgmt today, but we have to stop ignoring it. warren, +1 I'd say build a group of people that work out a solution thl: +1. I#d say those people that are complaining about it should do that thl, that worked well for kernel module standards. =( warren, kmods work for a lot of people *CORE* (or whatever becomes of it) must have a standardized usermgmt solution shipped by default it's not perfect, but they work it has to be ratified and used or people wont accept it nirik, +1 yes We have to have something like it. Is there anyone willing to drive the issue, and a solution? without a driver, this car is going nowhere fast. rdieter: agreed. rdieter, +1 Who here has the biggest problem with fedora-usermgmt? We need to communicate 1) what is the problem? 2) what negative effects are there of ignoring it? 3) what exactly the solution entails And it shouldn't be called fedora-usermgmt. :-) It should just be a standard part of the distro. abadger1999: mmcgrath and thimm seemed to rdieter, thimm seems to really dislike fedora-usermgmt, but seems he doesn't want to have that job thl: and he *still* doesn't understand why it exsits or how it works. ): And thimm doesn't see value in static assignment at all.... rdieter, :) Could we have FESCO at least agree that we have to stop ignoring this? warren: and do what exactly? And the base distribution should provide this kind of functionality as a standard? yes, we need a standard. We could push it to the packaging folks? :) The exact implementation details have to be discussed. If people aren't willing to discuss it, then whoever works on it gets to decide. warren: ok, +1. standard +1 warren: +1 to a standard. and we should get Red Hat's BaseOS group involved since it would affect many of those packages which add users. nirik, +1 for the packaging folks ;-) f13, +1 as well f13, nod f13:++ f13, maybe we could even assign driving to one of them =) f13: agreed. Are some of them likely to have more time soon when 5 is out the door? nirik: hopefully. +1 from me I have to step away for a moment. f13, I'll talk with my manager and see if there are any obvious ways to drive this in baseOS. This goes all the way to the installer (which will need to allow configuration of this stuff before package installation) so many people will need to be involved. man, I really hope we don't have to ask the user a questiona bout this. The end result wont be called fedora-usermgmt. I'd be ok with a static mapping, or with more configurability with useradd or whatever, we just need everyone to have to use the same thing. It should have known defaults that doesn't require asking the user. any such systme should have a reasonable default and just use it, letting "experts" override the reasonable default somehow. f13, +1 agreed. ok, so does this go to the packaging committee to be worked on? so, who is driving this? warren? packaging folks? mailing list? bpepple: No. abadger1999: who should be driving this then? we need multiple people buying in If it's going to be incorporated into baseOS then packaging committee needs to stay hands off for a while. yeah, but if we want it to go anywhere we need a few people or a person to push for it to happen, right? abadger1999: as long as the proposals are brought by baseOS folks, it should be ok. perhaps mmcgrath would like to? He doesn't like the current solution, but understands it? :) mmcgrath ? buhh, rdieter: +1. I'd be very happy if they brought the solution to the table. rdieter see's the quote of the week, mmcgrath: buhh,  :) heh :) is there no way to make fedora-usermgmt transparent? IE not in the specfile in any way? mmcgrath, is the specfile overhead really problematic? thats where my issue with it is. and thats where the EPEL issues are as well. So warren, do you think you can get feedback on whether there's someone within the base OS engineers that will commit to pushing this forward by next week?  Or have some idea of timeframe? Make useradd consult a table of suggested uid assignments. if part of the install process was "copy fedora usermgmt to /usr/sbin/useradd" we'd be all set abadger1999, already talking with my manager about this Cool. I'm glad to help with what needs to be done but I think I'm a bit too emotional with this particular topic to be honest. perhaps too passionate, I just think without full integration it feels like a hack. Ok, maybe while warren is talking to his manager we should move on. bpepple: +1 --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora any other items people want to discuss? bpepple: Do we want to go back to tracker bugs now? did the sponsor vote happen? how long should cvsadmin branch requests take (2+ days?). (: I haven't done anything on the SponsorResponsabilities or the Roadmap for release cycles. ;) dgilmore: yes. Jarod was approved. rdieter: not that long rdieter: ill get onit when i have lunch soon I'm still waiting (unless I did something wrong): http://bugzilla.redhat.com/230071 warren: if you are still there, can we do the discussion about the cvs flags? would be very nice to get that done and solved... dgilmore: thanks, np. abadger1999: Yeah, but since warren was driving it, didn't make much sense to talk about while he's away. i'm here what is the issue with cvs flags? --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora - Tracker Bugs warren: i dont think the admins get all the emails sorry, tracker bugs. should we get someone to replace all of them with flags? or only some? or leave them all as they are? ah hm Since the migration turned out to be fully a one-to-one mapping, do you see any theoretical issues in an auto-migration that didn't send mail? c4chris: do you have thoughts? since you deal with them for your status report? dgilmore, I haven't seen any signs of not receiving flag e-mails not really I'd be ok with changing them all if it can be done without 2billion emails. We still need NEEDSPONSOR and DEADREVIEW, but the rest go away? or even deadreview? dgilmore, are you sure your filters aren't hitting and throwing into other folders? I'm fine if they are gone warren: its possible NEEDSPONSOR and DEADREVIEW are small enough to keep DEADREVIEW should be fedora-review ="-", shouldn't it? the troublesome bit is how to get the approval date for packages... tibbs, I thought so tibbs: yes c4chris, we have the approval date for packages now? warren: not exactly, it's just the date of last change for the ticket... can you get flag change time? Can flags have more states than ? + - and " " ? which will all change if we remove the blocker on all those tickets... nirik: dunno Legal needs to stick around. (Regarding usermgmt, it is too late for fedora 7, so we should target a standard in base OS for Fedora 8?) tibbs: yeah, but a bunch of the merge reviews are in - now from when the procedure was to set that to get the maintainer to do something. nirik: but I'd like to know tibbs, no more states are possible nirik: Those should be easily fixable. flags can optionally be assigned to specific people, but we haven't used that anywhere yet. you can query on 'flag setter' If you can think of a good reason to use assign to specific person, we can try it. warren: It's unfortunate that flags have only four values. can we get flags in column output in any way ? It would make more sense for them to have real textual values. anyhow, we can look at that at some point... are we agreed to change all the blockers to flags? The main blockers anyhow FE-NEW, FE-REVIEW, FE-ACCEPTED? warren: +1 First we must change '-' to '?' as appropriate. yeah, +1 on those. Or at least if we want to deal with DEADREVIEW, I guess. tibbs, unless the reviewer gave up, then it should go back to blank there are currently 52 merge reviews in - Regarding the merge reviews, I think we should clearly communicate a realistic policy at this point. Merge Review is not a gatekeeper into Fedora 7, but just a cleanup sweep. The cleanup will continue toward Fedora 8. warren: +1 warren: agreed. Definitely. sure f13, should the Merge Review cleanup stop at test4? We're making progress, but any pre-F7 goal is just hilarious at this point. well, either we need to agree to release f7 with core/extras in diffrent VCS'es or we need to agree that all of them aren't going to be reviewed and just merge them at some poitn. f13, (further cleanups of spec files stop at test4 so we have a more predictable result in F7) tibbs: agreed. nirik, when infrastructure is ready, they will just be merged yeah, makes sense. I'm lacking food and oxygen, so I'm going for now. warren: ok. So you will see about getting those changed? I guess that should be all on that topic... ;) --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora ok, anything else before we call it quits? nothing here -- MARK -- Meeting End
 * c4chris|w here
 * f13 marks his calendar to remember this more often
 * rdieter waves
 * warren adds this channel to auto-join
 * c4chris is afraid the garbage collector package is a great opportunity to shoot oneself in the foot...
 * warren sees this as bordering on the lunatic requests of people wanting the ability to upgrade when deps are broken.
 * thl fears that skvidal will show up and say "send patches"
 * thl will stop now; new topic
 * rdieter thanks tibbs for taking one for team by volunteerting to do summaries. (:
 * f13 notes that this is about how to package them, not whether or not they shoudl be packaged.
 * bpepple is clueless when it comes to kde.
 * nirik wonders now that warren is back around if we should go back to the flags item to deal with it?
 * thl wonders why this topic is EPEL specific
 * rdieter thinks we should just ignore those who are complaining... (:
 * nirik uses it in one of his packages. I really don't care either way, but we need a standard here.
 * f13 looks at RHEL4 and RHEL3 update releases...
 * warren goes to talk to his manager.
 * spot is more than content to let someone else step on this landmine
 * mmcgrath reads up
 * dgilmore was late
 * bpepple will end the meeting in 60
 * bpepple will end the meeting in 30
 * bpepple will end the meeting in 15