Extras/SteeringCommittee/Meeting-20070329

= 2007 March 29 FESCo Meeting =

Present

 * Brian Pepple 	(bpepple)
 * Jason Tibbitts	(tibbs)
 * Christian Iseli	(ch4chris)
 * Rex Dieter  	(rdieter)
 * Toshio Kuratomi	(abadger1999)
 * Kevin Fenzi 		(nirik)
 * Dennis Gilmore	(dgilmore)
 * Warren Togami	(warren)
 * Josh Boyer		(jwb)
 * Jeremy Katz		(jeremy)

Absent

 * Jesse Keating	(f13)
 * Tom Callaway		(spot)
 * Bill Nottingham	(notting)

Packaging Committee Report

 * FESCo approved the Packaging Committee's guidelines regarding:
 * http://fedoraproject.org/wiki/PackagingDrafts/PostRelease
 * http://fedoraproject.org/wiki/PackagingDrafts/ExtraDistTagConditionalMacros
 * http://fedoraproject.org/wiki/PackagingDrafts/Utf8Filenames

EPEL

 * FESCo approved the formation of a steering committee for EPEL. http://fedoraproject.org/wiki/ThorstenLeemhuis/EPELSteeringCommittee

Feature Freeze Policy

 * FESCo approved the Feature Freeze Policy. jeremy will send an e-mail regarding this to the appropriate lists. http://fedoraproject.org/wiki/Releases/FeatureFreezePolicy

Sponsor Nominations

 * David Lutterkort was nominated and accepted as a new sponsor.

cvs-import changes

 * Jens Petersen's patch will be applied to the current cvs-import script.

Log
FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren nirik is here. jwb is here jeremy is here Hi everyone. warren here wwoods rings the bell and cracks the beers - meeting over! c4chris is here --- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop Three PC issues to consider today: tibbs: you want to take this? I believe spot won't be here today. Yes, I'll run these. First is non-numeric post-releases: We might be missing a few people... they're in training and stuff. http://fedoraproject.org/wiki/PackagingDrafts/PostRelease If I should wait or delay these, please let me know. tibbs: I believe your alright. This draft basically codifies one possible way for dealing with upstreams that use some classes non-sane versioning. looks like we have 8/13 here... Sometimes upstream appends alphanumeric tags which do not sort properly, and the draft codifies a method for making that work without resorting to epoch. seems like a sane thing to do Of course, use of Epoch is always there to solve weird ordering problems; this draft doesn't attempt to prevent that. Sorry. I'm here. seems like it makes sense to me... do we have many packages that do that? Unfortunately there are some java ones which provide the example used in the draft. nirik: I just had this occur with liferea today. The whole GA1, CP1, SP1 stuff is from a real example although I don't know the name of the package. tibbs: besides the impression that the draft is maybe trying to micromanagement it looks sane. I'm not sure if the amendment is needed at all. ugh. :( I think the draft looks fine, +1... but also might be nice to ping upstream and tell them why they shouldn't do that... ;) +1. Seems pretty sane to me also. +1 +1 ixs: The problem is that unless we permit this, Epoch: or eliminating the alpha tags altogether is the only way to handle this, and both are proplematic to various parties. This isn't a requirement; it's just allowing another possibility. I don't see how any micromanagement is involved, really. Move on? tibbs: got that. It's just that I'm reading the current guidelines as not disallowing your draft. But as I said the draft looks good. one possible amendment Perhaps if the packager uses one of these weird corner cases, there should be an appropriate comment in the spec above Version so other packagers aren't confused? ixs: It's a "How does a novice packager tell that upstreams versions could cause problems/what should they do in that case?" -- Best practice rather than guideline. warren: that sounds like a good idea. It might not be a bad idea to request that packagers describe weird upstream versioning schemes. commenting exceptions goes without saying... The problem comes in when you don't actually know what upstream is going to do since they're making it up on their own. But I don't think we can ever deal with that with guidelines. rdieter, +1 warren: I'll pass your comment on to spot, who is driving this draft. Any other comments? How should I note FESCo's disposition here? cool tibbs: I don't see anyone opposing this one. generally +1 OK, I'll move on; I don't expect that spot or PC will have any objections to adding warren's comment. Next item: Additional dist-related macros http://fedoraproject.org/wiki/PackagingDrafts/ExtraDistTagConditionalMacros This requires actual implementation in order to be useful, of course. And I admit to not actually needing any of this stuff in my packages so I'm not the best one to comment on the details here. what package has those macros in it? rpm? I think it's buildsys-macros. nirik: i guess buildsys-macros I like it, but only if RHEL adopts it too. tibbs: these macros would go into buildsys and not general rpm macros? That much is clear, right? which f13 proposed we do away with and put in redhat-rpm-config warren: the original request came from epel.. :) looks fine to me... +1 here. +1 from me also +1 +1 here too There's a thread ongoing about getting buildsys-macros into end-user installs so people building packages outside of the buildsys can also use these things. i have some packages where i conditionalise things on fedora release Would this make it easier for you? SaadaldineAlsaidi it would be cleaner Sorry pretty late so could someone also drive getting RHEL to add these? who? we would need buy-in from base OS I can act as liason it would make things easier for me (too)... nirik: if we approve it for fedora, it'll follow at least for rhel5 pretty quickly or jeremy there's been an internal thread about it for rhel which also helped to push the "should we ship the macros" thread along warren: intrim i owuld be ok with doing a epel-rpm-config package with them RHEL might not be comfortable in obsoleting epel-rpm-config in the future unless you have some other way of getting rid of it rhel would likely add that to 5? or 4 also? warren: the other way to get rid of it would be in epel-release epel-release could obsolete/provide the epel-rpm-config if it needed to go away later? nirik: 5 (in 5.1) why not just include it in epel-release temporarily? nirik: 4 and 5 would need it so we would be out of luck in epel-4 for those macros... ;( nirik: it'd just go into epel-release/epel-rpm-config. which would be fine warren: we could include it in epel-release ill get them added to epel-release yeah, seems like a good way to go... So I'm getting the sense that people like these but it's down to implementation issues which still need to be worked out. epel-release is good enough, avoids a future obsoletes that would slow down transactions epel-release it is tibbs: agreed. Should I move on? tibbs: yep +1 to the idea, I want to see actual implementation tibbs: yes ill work on implemting them Next item: Mandating that filenames in RPMs be utf8 http://fedoraproject.org/wiki/PackagingDrafts/Utf8Filenames buildsys-macros of fedora currently has it? warren: no  it will need adding Not much more to say about this one. tibbs: +1 from me. I suspect it's a corner case, but good one to get a guideline on. +1 here also. +1 +1 from me abadger1999: Did you run into an actual problematic package here? +1 as a side note, someone might want to run a check against all the filenames and make sure they meet this guideline/file bugs? There was an aspell one. aspell-is +1 to all of the above Also rpmlint will be growing a check for this one if approved. +1 OK, I'll report back to PC. The first (plus warren's addition and third items will become guidelines next week) if there are no further issues. The second one will await implementation. That's all from PC. tibbs: thanks. how does a UTF-8 filename look on a non utf-8 system, that is LANG=en_US or similar? (sorry, bit late. :) ixs, bad ?
 * tibbs here
 * rdieter steps out from the rabble seats, here.
 * cweyl_ takes his rabble seat
 * dgilmore is here
 * jwb has to step away for a minute
 * thl would prefer to solve the problems at hand without such a special per-repo-marco-rpm
 * rdieter doesn't care where the macros go, as long as they do go in.
 * jwb is back

I'm going to skip to the EPEL topic for this week, so folks don't have to wait to the end of the meeting for this. --- bpepple has changed the topic to: FESCO-Meeting -- EPEL -- discuss and (if there is no disagreement) approve the proposal for the EPELSteeringCommittee https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00753.html http://fedoraproject.org/wiki/ThorstenLeemhuis/EPELSteeringCommittee I believe filenames that are in the wrong encoding will get "?" instead of characters. thl you about? well, the porposal is in the wiki it was discussed on epel-devel-list and fedora-maintainers some small adjustments were made but no one yelled so seems people are okay with it I've no objections or desire to obstruct how EPEL chooses to organize itself. so the question is: is FESCo okay with it? +1 thl: I don't see any problems with it. ok: +1 +1 +1 +1 +1 thl: I don't see any '-1', so consider it approved. bpepple, thx is there anything else regard EPEL? don't think so ok, thanks. moving on.... --- bpepple has changed the topic to: FESCo meeting -- Feature Freeze Policy -- katzj rdieter: i just need to borrow it for an hour or two nah, we keep those just in case they grow too bold... draft url I think is: http://fedoraproject.org/wiki/JeremyKatz/FeatureFreezeDraft ? that's what they all say. nirik: yep jeremy: Is the intention to freeze everything on a spin or everything in the repository? I updated it this morning with the comments from cweyl and also adding a "disputes to fesco" bit I like it a lot... but how do we enforce freeze on extras type people? peer presure? turn off buildsys? ? (The first draft seemed like "on a spin" but the second draft is different.) im ok with the proposal nirik, one sec abadger1999: for the purposes of keeping things simple, I think the idea is to say that no new features in general. and if people propose exceptions, if it's a package that's not in a spin, then it's going to be a lot easier to say yes nirik: pointy sticks. nirik: peer pressure is really the best approach I think nirik: since people still need to be able to build fixes! yeah. Extras slush? peer pressure +1 Anybody want to be enforcer? +1 to peer pressure. i like peer presure peer pressure doesn't work warren: ill be enforcer for the record, wrt kde spin... we ask for leniency. We'd like to add a bunch of Extras' BR's, and package splits soon. dgilmore: cool. jeremy: Hmm.. That sounds good. We should maybe write that down in the email that announces the freeze policy. peer pressure works, but do we have simple automated means to see infractions quickly? rdieter: I expect that in general, we'll be a little lenient overall with f7 warren: xml-rpc queries of package tags jeremy: thanks. abadger1999: can do warren: koji will help us alot with it warren, peer pressure only works if people are paying attention jwb: ++ abadger1999: and I'm volunteering to be the bad guy to send the mail warren, and it only catches things _after_ they're broken warren, f13 starts yelling is the signal ? jeremy: :-) rel-eng should make sure to annoucne these freezes loud and clearly. jwb: one of the jobs of the release team is watching for those sorst of things. and there isn't any way technologically to enforce it jwb: We can always not push unapproved things to the repos. The only other step where things could be caught is before push... but it's not easy to look at all packages before a push I am sure. ixs: yeah, I'm going to yell from the rooftops.  including fedora-announce-list probably jeremy: good idea. nirik: when we move to koji, we may move to more automated pushes much like rawhide is today jeremy: +1 those attempts locked down far too m u9ch it ends up being lots of crap to wade through and if you really want to, you can still slip things in much holding people back well, we can always try it and see. ;) (peer pressure that is... ) yes we'll be in much better shape for F8 freeze, with more flexibility in koji so, +1 to the draft from me. draft is fine with me +1 here also. +1 +1 +1 +1 jeremy: Is there anything else in regard to the feature freeze? +1 I think that's it so to clarify _everything_ is under a general freeze, right? with the exception of adding new packages? if anyone else wants to join the release team and help approve/disapprove things, more eyes make lighter work jwb: correct. k yeah. "no new features or major version bumps are allowed " Is FE<devel still on the rolling model? jeremy: make it so, it will be done. jeremy: how many requests are typical for stuff after feature freeze? That would mean that we also have to be vigilant about people releasing packages with EVR problems. abadger1999: there's been another draft floating around there about changes there, but it hasn't made any headway afaik nirik: uh? no new features? that contradicts the draft. nirik: the draft says, new additions to the repo are okay Actually, if we're in freeze, shouldn't we branch the extras tree now? jeremy, does jesse decide who goes into release team? nirik: not that many ixs: I copied that from the draft... I guess I should have copied more for context. ;) tibbs: that discourages work on stabilization is the problem nirik: whoaps :) tibbs: plus diluting testing I'm not understanding how, but OK. jeremy: k. Can we run EVR check before pushing packages? "no new features or major version bumps are allowed for packages already in the Fedora collection" jeremy, did we decide on branching at freeze time? warren: definitely not at feature freeze time. maybe when we get to critical bugfixes, but I think any discussion there is kind of in limbo while we try to get things merged + koji rolled out Because we want to catch people doing this: 5.fc7, 5.fc6 => 6.fc6  And have them do this instead: 5.fc6.1 nirik, also "No new changes that impacts things in the spins." jeremy, nod, ok abadger1999: could probably be added. send a mail and mschwendt will probably jump on it ok, we should probably move on. Everyone ok with that? Hmm.... But that doesn't take care of updated upstream versions.... rdieter: ask f13 fair nuf. rdieter: I think we just add you to the alias. I'll talk to jesse when he pops online. (he's in summit speaker training today) bpepple: +1. abadger1999: 5.fc6.1? I've never seen that before. I'd fear that would break some scripts which expect .dist.arch.rpm names. ixs: It's in the guidelines and has been used. ixs: too late, lots of packages are slready using that scheme. :) abadger1999: okay then... --- bpepple has changed the topic to: FESCO-Meeting -- sponsor nominations -- David Lutterkort, nominated by Spot abadger1999: yeah, if they are minor updates with no new features and just bugfixes they could push for devel too, right? if they are major, they should probibly not push any of them. ;) like I said, haven't seen it yet. But I haven't looked that closely. +1 lutter +1 lutter +1 here also. +1 lutter +1 lutter +1 lutter +1 +1 lutter +1 nirik: *grin* but we all know the expectations for Extras pushing in <7 is different. Hope lutter doesn't have an audio-enabled IRC client running at the moment. ok, I think we can consider lutter approved. Moving on... --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- cvs-import changes - c4chris haha .. I do .. kepp saying my name, I like it ixs, there's a dash in front of release, not a dot... c4chris: had a chance to look at this at all? bpepple thanks warren for doing that. bpepple, not me, but someone did in cvs-admin list done his patch looks good to me Jens Petersen's patch? warren, yup lutter: Feel the luv baby! who will apply this ? I think it solves all the requirements Jens has the ability to apply it we could ask him? fine with me +1 +1 here also. +1 im fine with his patch I haven't seen the patch, but I trust everyone to have looked it over. ;) since i asked jens to do it and forwarded on to c4chris looks fine to me also. if jens doesn't want to have touched it last, I'll commit it ;) sent mail to jens I'll do it if he doesn't want to oh. or jeremy =) jeremy, warren, others: i check in some changes to Makefile.common  adding make koji.  I would like som extra eyes on it we should also send a message to the maintainer's list informing them of the change. dgilmore, make koji is a temporary test command? warren: no it will stay bpepple, right warren: we still have make plague when we move make build will use the make koji call  but both will be available sounds sane dgilmore, sounds fine plague (production) and koji (test) merge... that flip flops? yes and no both in production? for a little while we will need to  import builds into koji both will be available for awhile ah didn't expect this.  If that works, then fine. anything else on this, or should we move on? move on --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Retired Package Policy - https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00700.html move++ mschwent wanted me to bring this up here. "Can FESCo or the FPC perhaps come up with an official policy on retired packages which have been published before for multiple releases of the dist, but which are not obsoleted in any new package?" in the cases that are currently present, it really feels like an obsolete should be there a list or pointer to a list in the release notes would be a good start. something should obsolete them This is tough. even if its fedora-release but without the corresponding provides since the same functionality _isn't_ provided dgilmore: fedora-release obsoleting things is not a scalable solution to anything can one of the *repo* tools detect those old packages ? If I build the package myself because I still need it, then the distro is working against me. I thought the consensus was to (pretty much) do nothing? (I had pushed for something like a fedora-obsoletes to automatically remove these, but that wasn't well-received) yeah, but in some cases there isn't a clear package that should obsolete them is there? jeremy: i agree but it would ensure that old versions are removed if functionality is not provided elsewhere nirik: if that's the case, it's more "this is an orphan package" than "this functionality isn't needed" some global repo check that flags all installed packages that are not in any of the repos? s/fedora-obsoletes/fedora-orphans/ then the user chan choose to selectively remove some of them... jeremy: how icky would it be to have a orphaned-pkg metadata in yum metadata c4chris: 'yum list extras' ? jeremy: and a plugin, perhaps, that could figure it out to tell a user what to get rid of nirik: too much churn in a repo for that to be terribly reliable skvidal: maintaining it is still painful. but I'd rather see that than a package do we have a list of these packages? I guess ones that were listed on that wiki page for removal? nirik, yes, 'yum list extras' is a good place to start I think skvidal, what do you mean with "too much churn" ? c4chris: if a pkg ver leaves a repo but is still installed perhaps this needs more discussion on the list to see if someone can write up a proposed policy? then it will show up in yum list extras Could be done in a firstboot module after an upgrade; "you have these packages installed which are no longer part of the distribution". extras isn't just looking at name.arch hmm it's looking at nevra that's all so a user might get a lot of false positives k Was the idea to keep a separate list of packages somewhere? but I think something in that vein woul dbe good c4chris: I agree +1 on lutter btw beep :-) Hmm, so where are we on this. More discussion on the mailing list? 'fraid so ok, we can probably move on then. --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora Anything else people want to talk about regarding Fedora? I like the PC report at the beginning, FWIW. tibbs: same here. we should name one of the future releases Pony, so that spot can get one eventually... pony +1 haha1 +1 here also This pony belongs to Zod. ok, if there is nothing else we can probably wrap up the meeting. And that pony's name is... General Whispertail von Gallopton sounds nice For that matter, ALL ponies belong to Zod. We're in pretty good shape if we're talking about ponies now. wwoods: You read the final decision on Extras and freezes? all your bases are belong to us -- MARK -- Meeting End
 * thl is around
 * c4chris is not yelling...
 * dgilmore will abstain as ill be on EPEL steering committie if its accepted
 * rdieter thinks they might want the keys/access-codes to the orbital laser...
 * jeremy has seen attempts to try to enforce freezes like this via technology instead of peer pressure
 * jeremy looks at rdieter for a delegate of the KDE contingent :)
 * rdieter (still) wonders how one joins rel-eng exactly.
 * nirik wouldn't mind helping with rel-eng either...
 * warren upgrades lutter
 * warren writes mail to Jens.
 * dgilmore notes it works for him
 * c4chris tries
 * jwb hates work sometimes
 * bpepple will end the meeting in 60
 * bpepple will end the meeting in 30
 * bpepple will end the meeting in 15