From Fedora Project Wiki

2007 March 29 FESCo Meeting

Members

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)

Summary

Packaging Committee Report

EPEL

Feature Freeze Policy

  • 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
* tibbs here
nirik is here.
jwb is here
jeremy is here
<bpepple> Hi everyone.
* rdieter steps out from the rabble seats, here.
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
* cweyl_ takes his rabble seat
<tibbs> Three PC issues to consider today:
<bpepple> tibbs: you want to take this? I believe spot won't be here today.
<tibbs> Yes, I'll run these.
First is non-numeric post-releases:
<warren> We might be missing a few people... they're in training and stuff.
<tibbs> http://fedoraproject.org/wiki/PackagingDrafts/PostRelease
If I should wait or delay these, please let me know.
<bpepple> tibbs: I believe your alright.
<tibbs> This draft basically codifies one possible way for dealing with upstreams that use some classes non-sane versioning.
<nirik> looks like we have 8/13 here...
* dgilmore is here
<tibbs> Sometimes upstream appends alphanumeric tags which do not sort properly, and the draft codifies a method for making that work without resorting to epoch.
<jeremy> seems like a sane thing to do
<tibbs> Of course, use of Epoch is always there to solve weird ordering problems; this draft doesn't attempt to prevent that.
<abadger1999> Sorry.  I'm here.
<nirik> seems like it makes sense to me... do we have many packages that do that?
<tibbs> Unfortunately there are some java ones which provide the example used in the draft.
<bpepple> nirik: I just had this occur with liferea today.
<tibbs> The whole GA1, CP1, SP1 stuff is from a real example although I don't know the name of the package.
<ixs> 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.
<nirik> 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... ;)
<bpepple> +1. Seems pretty sane to me also.
<c4chris> +1
<jeremy> +1
<tibbs> 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?
<ixs> 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.
<warren> 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?
<abadger1999> 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.
<bpepple> warren: that sounds like a good idea.
<tibbs> It might not be a bad idea to request that packagers describe weird upstream versioning schemes.
<rdieter> commenting exceptions goes without saying...
<tibbs> 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.
<c4chris> rdieter, +1
<tibbs> 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?
<warren> cool
<bpepple> tibbs: I don't see anyone opposing this one.
<warren> generally +1
<tibbs> 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
* jwb has to step away for a minute
<tibbs> 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.
<nirik> what package has those macros in it? rpm?
<tibbs> I think it's buildsys-macros.
<dgilmore> nirik: i guess buildsys-macros
<warren> I like it, but only if RHEL adopts it too.
<ixs> tibbs: these macros would go into buildsys and not general rpm macros? That much is clear, right?
<dgilmore> which f13 proposed we do away with and put in redhat-rpm-config
<rdieter> warren: the original request came from epel.. :)
<nirik> looks fine to me... +1 here.
<dgilmore> +1 from me also
<bpepple> +1
<c4chris> +1 here too
<tibbs> 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.
<dgilmore> i have some packages where i conditionalise things on fedora release
<tibbs> Would this make it easier for you?
<saadsaidi> SaadaldineAlsaidi
<dgilmore> it would be cleaner
<saadsaidi> Sorry pretty late
<nirik> so could someone also drive getting RHEL to add these? who?
<warren> we would need buy-in from base OS
I can act as liason
<rdieter> it would make things easier for me (too)...
<jeremy> nirik: if we approve it for fedora, it'll follow at least for rhel5 pretty quickly
<warren> or jeremy
<jeremy> there's been an internal thread about it for rhel which also helped to push the "should we ship the macros" thread along
<dgilmore> warren: intrim i owuld be ok with doing a epel-rpm-config package with them
<warren> RHEL might not be comfortable in obsoleting epel-rpm-config in the future
<warren> unless you have some other way of getting rid of it
* thl would prefer to solve the problems at hand without such a special per-repo-marco-rpm
<nirik> rhel would likely add that to 5? or 4 also?
<dgilmore> warren: the other way to get rid of it would be in epel-release
<nirik> epel-release could obsolete/provide the epel-rpm-config if it needed to go away later?
<jeremy> nirik: 5 (in 5.1)
<warren> why not just include it in epel-release temporarily?
<dgilmore> nirik: 4 and 5 would need it
<nirik> so we would be out of luck in epel-4 for those macros... ;(
<jeremy> nirik: it'd just go into epel-release/epel-rpm-config.  which would be fine
<dgilmore> warren: we could include it in epel-release
ill get them added to epel-release
<nirik> yeah, seems like a good way to go...
* rdieter doesn't care where the macros go, as long as they do go in.
<tibbs> So I'm getting the sense that people like these but it's down to implementation issues which still need to be worked out.
<warren> epel-release is good enough, avoids a future obsoletes that would slow down transactions
<dgilmore> epel-release it is
<bpepple> tibbs: agreed.
<tibbs> Should I move on?
<jeremy> tibbs: yep
<warren> +1 to the idea, I want to see actual implementation
<dgilmore> tibbs: yes
ill work on implemting them
<tibbs> Next item: Mandating that filenames in RPMs be utf8
http://fedoraproject.org/wiki/PackagingDrafts/Utf8Filenames
<warren> buildsys-macros of fedora currently has it?
<dgilmore> warren: no  it will need adding
<tibbs> Not much more to say about this one.
<nirik> tibbs: +1 from me. I suspect it's a corner case, but good one to get a guideline on.
<bpepple> +1 here also.
<c4chris> +1
<dgilmore> +1 from me
<tibbs> abadger1999: Did you run into an actual problematic package here?
<jeremy> +1
<nirik> as a side note, someone might want to run a check against all the filenames and make sure they meet this guideline/file bugs?
<abadger1999> There was an aspell one.
aspell-is
<jwb> +1 to all of the above
<tibbs> Also rpmlint will be growing a check for this one if approved.
* jwb is back
<warren> +1
<tibbs> 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.
<bpepple> tibbs: thanks.
<ixs> how does a UTF-8 filename look on a non utf-8 system, that is LANG=en_US or similar?
(sorry, bit late. :)
<c4chris> ixs, bad ?
:-)
<bpepple> 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
<abadger1999> I believe filenames that are in the wrong encoding will get "?" instead of characters.
<bpepple> thl you about?
* thl is around
<thl> 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
<tibbs> I've no objections or desire to obstruct how EPEL chooses to organize itself.
<thl> so the question is: is FESCo okay with it?
<jwb> +1
<bpepple> thl: I don't see any problems with it.
* c4chris is not yelling...
<rdieter> ok: +1
<abadger1999> +1
<c4chris> +1
<nirik> +1
<jeremy> +1
* dgilmore will abstain as ill be on EPEL steering committie if its accepted
<bpepple> thl: I don't see any '-1', so consider it approved.
<thl> bpepple, thx
<bpepple> is there anything else regard EPEL?
<thl> don't think so
<bpepple> ok, thanks.
moving on....
--- bpepple has changed the topic to: FESCo meeting -- Feature Freeze Policy -- katzj
* rdieter thinks they might want the keys/access-codes to the orbital laser...
<dgilmore> rdieter: i just need to borrow it for an hour or two
<c4chris> nah, we keep those just in case they grow too bold...
<nirik> draft url I think is: http://fedoraproject.org/wiki/JeremyKatz/FeatureFreezeDraft ?
<rdieter> that's what they all say.
<jeremy> nirik: yep
<abadger1999> jeremy: Is the intention to freeze everything on a spin or everything in the repository?
<jeremy> I updated it this morning with the comments from cweyl and also adding a "disputes to fesco" bit
<nirik> I like it a lot... but how do we enforce freeze on extras type people? peer presure? turn off buildsys? ?
<abadger1999> (The first draft seemed like "on a spin" but the second draft is different.)
<dgilmore> im ok with the proposal
<jwb> nirik, one sec
<jeremy> 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
<rdieter> nirik: pointy sticks.
<jeremy> nirik: peer pressure is really the best approach I think
nirik: since people still need to be able to build fixes!
<nirik> yeah.
<warren> Extras slush?
<c4chris> peer pressure +1
<warren> Anybody want to be enforcer?
<bpepple> +1 to peer pressure.
<dgilmore> i like peer presure
<jwb> peer pressure doesn't work
<dgilmore> warren: ill be enforcer
<rdieter> 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.
<bpepple> dgilmore: cool.
<abadger1999> jeremy: Hmm.. That sounds good.  We should maybe write that down in the email that announces the freeze policy.
<warren> peer pressure works, but do we have simple automated means to see infractions quickly?
<jeremy> rdieter: I expect that in general, we'll be a little lenient overall with f7
<dgilmore> warren: xml-rpc  queries of package tags
<rdieter> jeremy: thanks.
<jeremy> abadger1999: can do
<dgilmore> warren: koji will help us alot with it
<jwb> warren, peer pressure only works if people are paying attention
<abadger1999> jwb: ++
<jeremy> abadger1999: and I'm volunteering to be the bad guy to send the mail
<jwb> warren, and it only catches things _after_ they're broken
<c4chris> warren, f13 starts yelling is the signal ?
<abadger1999> jeremy: :-)
<ixs> rel-eng should make sure to annoucne these freezes loud and clearly.
<jeremy> 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
<tibbs> jwb: We can always not push unapproved things to the repos.
<nirik> 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.
<jeremy> ixs: yeah, I'm going to yell from the rooftops.  including fedora-announce-list probably
<ixs> jeremy: good idea.
<jeremy> nirik: when we move to koji, we may move to more automated pushes much like rawhide is today
<bpepple> jeremy: +1
* jeremy has seen attempts to try to enforce freezes like this via technology instead of peer pressure
<warren> those attempts locked down far too m u9ch
<jeremy> it ends up being lots of crap to wade through and if you really want to, you can still slip things in
<warren> much
holding people back
<nirik> well, we can always try it and see. ;)
(peer pressure that is... )
<c4chris> yes
<warren> we'll be in much better shape for F8 freeze, with more flexibility in koji
<nirik> so, +1 to the draft from me.
<jwb> draft is fine with me
<bpepple> +1 here also.
<c4chris> +1
<abadger1999> +1
<tibbs> +1
<rdieter> +1
<bpepple> jeremy: Is there anything else in regard to the feature freeze?
<warren> +1
<jeremy> I think that's it
<jwb> so to clarify
_everything_ is under a general freeze, right?
with the exception of adding new packages?
<jeremy> if anyone else wants to join the release team and help approve/disapprove things, more eyes make lighter work
<bpepple> jwb: correct.
<jwb> k
* jeremy looks at rdieter for a delegate of the KDE contingent :)
<nirik> yeah. "no new features or major version bumps are allowed "
<abadger1999> Is FE<devel still on the rolling model?
<rdieter> jeremy: make it so, it will be done.
<nirik> jeremy: how many requests are typical for stuff after feature freeze?
<abadger1999> That would mean that we also have to be vigilant about people releasing packages with EVR problems.
<jeremy> abadger1999: there's been another draft floating around there about changes there, but it hasn't made any headway afaik
<ixs> nirik: uh? no new features? that contradicts the draft.
nirik: the draft says, new additions to the repo are okay
<tibbs> Actually, if we're in freeze, shouldn't we branch the extras tree now?
<warren> jeremy, does jesse decide who goes into release team?
<jeremy> nirik: not that many
<nirik> ixs: I copied that from the draft... I guess I should have copied more for context. ;)
<jeremy> tibbs: that discourages work on stabilization is the problem
<ixs> nirik: whoaps :)
<jeremy> tibbs: plus diluting testing
<tibbs> I'm not understanding how, but OK.
<abadger1999> jeremy: k.  Can we run EVR check before pushing packages?
<nirik> "no new features or major version bumps are allowed for packages already in the Fedora collection"
<warren> jeremy, did we decide on branching at freeze time?
<jeremy> 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
<abadger1999> Because we want to catch people doing this: 5.fc7, 5.fc6  => 6.fc6  And have them do this instead: 5.fc6.1
<warren> nirik, also "No new changes that impacts things in the spins."
jeremy, nod, ok
<jeremy> abadger1999: could probably be added.  send a mail and mschwendt will probably jump on it
<bpepple> ok, we should probably move on.  Everyone ok with that?
* rdieter (still) wonders how one joins rel-eng exactly.
<abadger1999> Hmm.... But that doesn't take care of updated upstream versions....
<dgilmore> rdieter: ask f13
<rdieter> fair nuf.
* nirik wouldn't mind helping with rel-eng either...
<jeremy> 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)
<abadger1999> bpepple: +1.
<ixs> abadger1999: 5.fc6.1? I've never seen that before. I'd fear that would break some scripts which expect .dist.arch.rpm names.
<abadger1999> ixs: It's in the guidelines and has been used.
<rdieter> ixs: too late, lots of packages are slready using that scheme. :)
<ixs> abadger1999: okay then...
--- bpepple has changed the topic to: FESCO-Meeting -- sponsor nominations -- David Lutterkort, nominated by Spot
<nirik> 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. ;)
<ixs> like I said, haven't seen it yet. But I haven't looked that closely.
<tibbs> +1 lutter
<abadger1999> +1 lutter
<bpepple> +1 here also.
<jeremy> +1 lutter
<nirik> +1 lutter
<rdieter> +1 lutter
<dgilmore> +1
<c4chris> +1 lutter
<warren> +1
<abadger1999> nirik: *grin* but we all know the expectations for Extras pushing in <7 is different.
<tibbs> Hope lutter doesn't have an audio-enabled IRC client running at the moment.
<bpepple> ok, I think we can consider lutter approved.
Moving on...
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- cvs-import changes - c4chris
<lutter> haha .. I do .. kepp saying my name, I like it
<c4chris> ixs, there's a dash in front of release, not a dot...
<bpepple> c4chris: had a chance to look at this at all?
* warren upgrades lutter
bpepple thanks warren for doing that.
<c4chris> bpepple, not me, but someone did in cvs-admin list
<warren> done
<c4chris> his patch looks good to me
<warren> Jens Petersen's patch?
<c4chris> warren, yup
<abadger1999> lutter: Feel the luv baby!
<c4chris> who will apply this ?
I think it solves all the requirements
<warren> Jens has the ability to apply it
we could ask him?
<c4chris> fine with me
<abadger1999> +1
<bpepple> +1 here also.
<warren> +1
* warren writes mail to Jens.
<dgilmore> im fine with his patch
<nirik> I haven't seen the patch, but I trust everyone to have looked it over. ;)
<dgilmore> since i asked jens to do it and forwarded on to c4chris
<jeremy> looks fine to me also.  if jens doesn't want to have touched it last, I'll commit it ;)
<warren> sent mail to jens
I'll do it if he doesn't want to
oh.  or jeremy =)
<dgilmore> jeremy, warren, others:  i check in some changes to Makefile.common  adding make koji.  I would like som extra eyes on it
* dgilmore notes it works for him
<bpepple> we should also send a message to the maintainer's list informing them of the change.
<warren> dgilmore, make koji is a temporary test command?
<dgilmore> warren: no it will stay
<c4chris> bpepple, right
<dgilmore> warren: we still have make plague
when we move make build will use the make koji call  but both will be available
<jeremy> sounds sane
<c4chris> dgilmore, sounds fine
<warren> plague (production) and koji (test)
merge... that flip flops?
<dgilmore> yes and no
<warren> both in production?
<dgilmore> for a little while
we will need to  import builds into koji
both will be available for awhile
<warren> ah
didn't expect this.  If that works, then fine.
<bpepple> anything else on this, or should we move on?
<dgilmore> 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
<c4chris> move++
<bpepple> 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?"
<jeremy> in the cases that are currently present, it really feels like an obsolete should be there
<nirik> a list or pointer to a list in the release notes would be a good start.
<dgilmore> something should obsolete them
<tibbs> This is tough.
<dgilmore> even if its fedora-release
<jeremy> but without the corresponding provides since the same functionality _isn't_ provided
dgilmore: fedora-release obsoleting things is not a scalable solution to anything
<c4chris> can one of the *repo* tools detect those old packages ?
<tibbs> If I build the package myself because I still need it, then the distro is working against me.
<rdieter> 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)
<nirik> yeah, but in some cases there isn't a clear package that should obsolete them is there?
<dgilmore> jeremy: i agree but it would ensure that old versions are removed if functionality is not provided elsewhere
<jeremy> nirik: if that's the case, it's more "this is an orphan package" than "this functionality isn't needed"
<c4chris> some global repo check that flags all installed packages that are not in any of the repos?
<rdieter> s/fedora-obsoletes/fedora-orphans/
<c4chris> then the user chan choose to selectively remove some of them...
<skvidal> jeremy: how icky would it be to have a orphaned-pkg metadata in yum metadata
<nirik> c4chris: 'yum list extras' ?
<skvidal> 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
<jeremy> skvidal: maintaining it is still painful.  but I'd rather see that than a package
* c4chris tries
<nirik> do we have a list of these packages? I guess ones that were listed on that wiki page for removal?
<c4chris> nirik, yes, 'yum list extras' is a good place to start I think
<c4chris> skvidal, what do you mean with "too much churn" ?
<skvidal> c4chris: if a pkg ver leaves a repo
but is still installed
<nirik> perhaps this needs more discussion on the list to see if someone can write up a proposed policy?
<skvidal> then it will show up in yum list extras
<tibbs> Could be done in a firstboot module after an upgrade; "you have these packages installed which are no longer part of the distribution".
<skvidal> extras isn't just looking at name.arch
<c4chris> hmm
<skvidal> it's looking at nevra
that's all
so a user might get a lot of false positives
<c4chris> k
<tibbs> Was the idea to keep a separate list of packages somewhere?
<c4chris> but I think something in that vein woul dbe good
<skvidal> c4chris: I agree
* jwb hates work sometimes
<jwb> +1 on lutter btw
<c4chris> beep :-)
<bpepple> Hmm, so where are we on this.  More discussion on the mailing list?
<c4chris> 'fraid so
<bpepple> ok, we can probably move on then.
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
<bpepple> Anything else people want to talk about regarding Fedora?
<tibbs> I like the PC report at the beginning, FWIW.
<bpepple> tibbs: same here.
<c4chris> we should name one of the future releases Pony, so that spot can get one eventually...
<rdieter> pony +1
<wwoods> haha1
<bpepple> +1 here also
<tibbs> This pony belongs to Zod.
<bpepple> ok, if there is nothing else we can probably wrap up the meeting.
* bpepple will end the meeting in 60
<wwoods> And that pony's name is... General Whispertail von Gallopton
* bpepple will end the meeting in 30
<c4chris> sounds nice
<tibbs> For that matter, ALL ponies belong to Zod.
* bpepple will end the meeting in 15
<warren> We're in pretty good shape if we're talking about ponies now.
<abadger1999> wwoods: You read the final decision on Extras and freezes?
<c4chris> all your bases are belong to us
<bpepple> -- MARK -- Meeting End
Retrieved from "https://fedoraproject.org/w/index.php?title=Extras/SteeringCommittee/Meeting-20070329&oldid=11617"