Extras/SteeringCommittee/Meeting-20070301

2007 March 01 FESCo Meeting

Members

Present

• Brian Pepple (bpepple)
• Jason Tibbitts (tibbs)
• Christian Iseli (ch4chris)
• Josh Boyer (jwb)
• Rex Dieter (rdieter)
• Toshio Kuratomi (abadger1999)
• Kevin Fenzi (nirik)
• Dennis Gilmore (dgilmore)
• Bill Nottingham (notting)
• Jesse Keating (f13)
• Jeremy Katz (jeremy)

Absent

• Tom Callaway (spot)
• Warren Togami (warren)

Summary

repo-creation using new createrepo

• f13 is currently working on using the new createrepo in the development branch.
• There is no plan to use the new createrepo in FC6.

Sponsor Nominations

• Fernando Nasser was nominated and accepted as new sponsors.

Extras 7 preparation

• the plan is not to do a mass rebuild.
• nirik is going to setup a page on the wiki to track other preparation issues that we need to track for F7.

Packaging Committee Report

• FESCo approved the Packaging Committee's guidelines regarding:
• Initscripts proposal: http://fedoraproject.org/wiki/PackagingDrafts/InitScripts
• Buildroot proposal: http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot

Log

--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
<bpepple> FESCo meeting ping -- abadger1999, awjb, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren
<tibbs> urp
<bpepple> Hi everybody; who's around?
<tibbs> Just finishing lunch.
<jwb> here
* jeremy is here
<bpepple> tibbs: same here.
<abadger1999> here
* nirik is here.
c4chris is here
thl is on the rabble seats
nirik goes to grab some more coffee.
XulChris hands thl his nachos and coke
<bpepple> Ok, we'll start slowly as more people show up.
<f13> I'm here, just running to the kitchen to get my lunch
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- extras repo-creation using new createrepo - skvidal
<bpepple> I believe f13 said that they are planning to use this in the devel repo.  Am I correct on this?
<f13> bpepple: we tried, ran into a failure that is perhaps due to RHEL4 NFS code and creating the sqlite blob over NFS
bpepple: but that is a very narrow case, we weren't able to dupe in many other scenarios, so it should be safe for Extras to do this
<notting> ... depending on how the extras push is done, of course.
<bpepple> f13: That's fine.  I belive Seth was just looking to see if we planning on doing this.
<f13> notting: I'm pretty sure it is done on local file system then rsynced around.
<jeremy> it is
* bpepple doesn't see warren around.
<bpepple> I guess we can go to the sponsor nomination since warren isn't currently here.
--- bpepple has changed the topic to: FESCO-Meeting -- sponsor nominations -- Fernando Nasser
<nirik> so is this going to happen for extras/devel? or extras/fc6 too?
<bpepple> nirik: createrepo?
<nirik> yeah.
<f13> nirik: should only be devel
<notting> nirik: devel only, afaik
<jeremy> nirik: devel yum is the only thing that benefits currently
<nirik> ok, just making sure.
<dgilmore> im here
<jeremy> and we're not really planning on backporting to yum 3.0.x afaik
<tibbs> So, I've no issues with fnasser.
* rdieter shows up tardy, took too long getting the 2-year-old to take a nap.
<bpepple> Ok, we should probably vote on making Fernando Nasser a sponsor.
+1.
<jeremy> +1
<c4chris> +1
<rdieter> +1
<nirik> I don't know much about his work, but will go with warren's reccomendation, so +1
<f13> +1
fnasser has been doing a great job taking our guidelines and applying them to jpackage.org too
* jwb throws a +1 there too
<abadger1999> +1 with f13's recommendation.
<bpepple> Ok, Fernando is a sponsor.
moving on....
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- cvs-import changes
<bpepple> Does anyone want to own this task?
* rdieter notes fnasser is a real trooper, for trying to discuss rpm with jbj on rpm-devel ml too. (:
<jwb> bpepple, remind me what the changes are?
<jwb> sorry, i missed the last two meetings and i'm trying to catch up
<nirik> I think we decided to modify cvs-import.sh to do several things...
<f13> show a diff w/ conformation before committing, prompt for a commit message
<bpepple> jwb: To provide a warning, a diff, and to add a comment.
that's a simplified list btw.
* c4chris is on vacations 'til next week... if noone steps in 'til then, I'll take it.
<bpepple> Anyone else interested?
c4chris: consider it yours.  thanks.
<c4chris> k
:-)
<bpepple> ok, we can move on.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Extras 7 preparation
<bpepple> nirik: did you talk to mschwendt about this a bit this week on the mailing list?
<nirik> yeah, let me find the thread.
<notting> what sorts of preparation are we talking about?
<bpepple> I believe he had some concerns.
notting: things like roadmap, broken deps, key packages (wxGTK2 issues solved?), rebuilds, FE7Target bug, mail to all package owners.
<f13> so there should be no need for a mass rebuild.
<nirik> https://www.redhat.com/archives/fedora-devel-list/2007-February/msg01369.html
<bpepple> f13: that
<f13> I'd like broken deps resolved by Test4
<nirik> starting around there.
<bpepple> d'oh! stupid keyboard.
<tibbs> I think that we should consider dropping packages with lonstanding broken deps from the distro.
<nirik> I worked on bugging maintainers for packages with broken deps this weekend.
<bpepple> tibbs: I'm thinking the same thing.
<jwb> what about the issue with the freezes?
<notting> unilaterally orphan packages with broken deps?
<nirik> A lot of them are fixed now.
<tibbs> And we need to come up with a plan for dealing with the broken upgrade paths as well.
<f13> jwb: the Freeze for test2 worked fairly well.
tibbs: "fix them by Test4" (:
<tibbs> Aren't there still core packages with bad update paths?
<nirik> csound, and paraview I know are still broken. I think almost all the others are fixed, but I haven't run repoclosure.
<jwb> f13, i meant the fact that rawhide and extras progress, but could be divergent once released...
f13, since there's no "needsign" repo for rawhide
<notting> jwb: that will be 'fixed' once we merge
<tibbs> Also, we should consider asking mschwendt to turn the mandatory daily report back on.
<bpepple> tibbs: +1
<f13> tibbs: if there are, they should be fixed.
<jwb> notting, yes.  but it could cause more of these other things to happen
<nirik> so if we are not doing mass rebuild, we will ship some packages that are .fc6 in f7?
<jwb> like broken deps
<notting> nirik: sure
<f13> I'd like to have less and less different treatement for core/extras.  Rules about things to be fixed should just be unilateral.
nirik: yep, happens all the time.
<notting> nirik: i'm unconvinced that 'make everyone rebuild' is the proper way to find inactive maintainers
<nirik> agreed.
<tibbs> packagedb, save us!
<bpepple> is there an ETA on the packagedb?
<f13> bpepple: "soon"  (:
bpepple: somewhat dependent upon koji
<f13> as the two will interact
<mmcgrath> re 'inactivemembers': We'll be doing password rotation with the new account system.  People will expire.
<bpepple> f13: that makes sense.
<nirik> Do we have any of this written in the wiki? ie, all deps must be fixed by test4, all broken upgrade paths must be fixed by test4, etc?
<f13> nirik: nope, care to add it to somewhere?
<bpepple> nirik: I don't think so.  Where on the wiki should we put it?
<nirik> sure, if someone could tell me where... I have no idea. ;)
<tibbs> Somewhere under Policy, I'd suppose.
<f13> We probably need a page that chronologs what each stage of a release needs
<bpepple> f13: +1
<f13> Policy/DevelopmentProcess
or something like that.
<nirik> yeah, part of the roadmap for f7?
<f13> nirik: more a generic roadmap
<nirik> ok, another issue is orphans... when do we cull them?
and do we cull from devel only, or all branches?
<bpepple> nirik: Do you want to start on setting up that page?
nirik: I would think devel only.
<nirik> Sure, shall I try and write up one under my space, we can review it next week and move it in somewhere offical?
<jwb> nirik, sounds good.  if you want someone to review it, ping me
<bpepple> nirik: that sounds fine.
<f13> nirik: packages once shipped should not be removed.
<nirik> ok. will do.
<f13> they can be removed from the next release
<c4chris> yea, remove from devel only
<nirik> ok, the downside is then that fedora-orphan or whatever gets the bug reports which never get an answer.
<notting> you can watch extras-orphan in bz
<jwb> yeah
<nirik> yeah, but does anyone do that?
<jwb> who's doing that?
<abadger1999> We should gate extras-orphan to some real people.
<notting> but that probably needs gating through the account system as well, for cvs commits, etc.
<bpepple> jwb: I think mschwendt does a bit.
<notting> jwb: i get it, i don't really pay attention to it
<nirik> it would be nice to have some way to tell end users "hey, not supported anymore, would you like to come and maintain it?"
<notting> jwb: mschwendt does most of the answering
<nirik> mschwent said he stopped, it was too much.
<jwb> i'll watch it for a while
<nirik> at least I thought he said that somewhere.
<bpepple> nirik: I think your right.
<jwb> nirik, i think he said he's going to stop doing the orphan report
<tibbs> Surely bugzilla could be hacked to just present a message, or some automated process could come by and drop a comment in each ticket.
<nirik> tibbs: yeah, thats what I was getting at... if possible that would be better than making humans have to deal with it.
<notting> it looks bad to have stuff in maintained releases that are 'sorry, no one is dealing with that', though
bad pr, etc.
<f13> nod
somebody should be watching especially for security stuff.
<bpepple> notting: agreed.  maybe this is something for the QA team?
<jwb> we're diverging a bit from the topic
<f13> maybe "This package is no longer actively mantained.  Security updates will still be issued, but no other updates.  If you wish to take over this package, see blah..."
<nirik> notting: yeah, but it also looks bad when their report is in NEW for ages with no response
<notting> we do that for maintained stuff!
<abadger1999> nirik: +1.  IMHO, looks worse to be unresponded to than to hae a definite answer.
<nirik> sadly true. ;(
<f13> notting: *shrug*
<bpepple> Ok, we should probably move on.
I don't see warren, so we should skip talking about Tracker Bugs this week.
--- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop
<bpepple> Anything to report from the Packaging commitee?
<tibbs> I don't see that spot is here.
<f13> I can give some update
although I don't have good notes in front of me :/
<bpepple> f13: that's fine/
<f13> We approved the init sript draft
<dgilmore> spot was in ohio yesterday
* notting sees abadger1999, rdieter, tibbs on the channel
<f13> http://fedoraproject.org/wiki/PackagingDrafts/InitScripts
<dgilmore> f13: a big +1 from me for the init script proposal
<tibbs> This has caused some discussion on the lists, but it doesn't seem to be going anywhere.
<nirik> +1 from me.
<bpepple> +1 here also.
<notting> +1, if we're voting
<tibbs> +1 from me, but I'm on the PC.
<c4chris> +1
<jwb> one sec
<rdieter> +1
<jeremy> the only thing I'm not sure if I'm comfortable with is the "migrate by this date"
<f13> THere was a buildroot change too again, let me find it.
<jeremy> but that's far enough away that it could change again before then :-)
* bpepple shudders at the thought of talk of buildroot.
<f13> jeremy: I wasn't too comfortable with that either.  I think that belongs more in a Release Feature rather than in guidelines.
<jwb> f13, right
<tibbs> http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot
<jwb> otherwise +1 from me on the initscript deal
<f13> http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot
<jeremy> f13: exactly
<f13> ah, tibbs beat me too it.
<nirik> +a lot from me on buildroot.
<tibbs> The new buildroot guideline is significantly easier to comply with than the old one.
<jwb> wait hang on
<bpepple> so there are bacically 3 acceptable buildroots?
<jeremy> big +1 to the new buildroot guideline
<abadger1999> -1 on the buildroot.
<jwb> wait....
<notting> +1
<nirik> there are 3 preferred ones...
<f13> bpepple: there are any number of acceptable buildroots, there are 3 suggested ones.
<bpepple> nirik: ah, ok.
<tibbs> bpepple: Those are examples.  I was unhappy with the wording there.
<dgilmore> -1 from me
* jwb sighs
<f13> jwb: what did you ant us to wait on?
<jwb> i'm trying to figure out if we just approved the initscripts thing or not
* nirik waits to hear why abadger1999 and dgilmore don't like it.
<f13> oh sorry.
**** STOP *****
<dgilmore> jwb: we approved it
<jwb> or if the changes that were suggested by you and jeremy would get rolled in
<f13> jwb: no changes just yet.
jwb: I'll try to work with lutter (who wanted me to add that text) to get it cleaned up.
<jwb> do we have to go back and ratify those changes?  that seems like a pain in the ass
<f13> jwb: mostl ikely not
<bpepple> jwb: I don't think so.   It's a pretty minor point.
<jwb> k
i'll trust you f13 ;)
<tibbs> So where do you want to put that text?
<jwb> ok, proceed.  sorry, just wanted to clarify
<bpepple> ok, back to buildroot....
<jwb> tibbs, the suggestion was in a release schedule
<dgilmore> nirik: basiclly i see it as axel being pushy.  his one objection i see as valid is building 2 arches on one box at once.   i say to resolve that add %{arch} in the build root we already approved and use that
<tibbs> Do we actually have a release schedule?
<f13> tibbs: It would be a Release/Feature
tibbs: for whichever release we want to target that cleanup for
<abadger1999> dgilmore: +1.  Either that or use the mktemp format.
<rdieter> dgilmore: it was more than just axel... (unfortunately).
<dgilmore> rdieter: well he was loudest
<nirik> I'm tired of otherwise good packages getting blocked by this... does it really matter? why?
<f13> look, the buildroot is so incredibly silly.  The buildsystem will override it anyway so we don't really care
* bpepple agrees with f13.
<f13> local folks can override it with an rpm macro
<jwb> right
<abadger1999> Things can break for local packagers so it's a regression.
<f13> I _really_ don't want to spend time on this.  If it follows a few simple guidelines, GOOD ENOUGH.
<rdieter> f13++
<tibbs> The primary issue is that it's there for folks building locally, but they can override it easily.
<bpepple> f13: +1
<abadger1999> The thing that racor is right about is that leaving off the %(%{__id_u} -n) allows you to break other peoples local builds.
<f13> abadger1999: I really don't care.
<nirik> should we really care about people building locally? don't they have other issues like not having our min build set of packages, etc?
<abadger1999> Whereas leaving off anything else (even name-ver-rel) can be cleaned up by the person doing the packaging.
<f13> there are any number of ways you can shoot yourself in teh foot with local building.
<jeremy> abadger1999: I can _STILL_ break your build if I want to
<dgilmore> f13: fine
<jwb> right.  and "joe user" probably needs to learn the hard way if he's really going to do local building
<f13> and really, we suggest people use mock, where this isn't an issue.
<abadger1999> jeremy: Can you do it through negligence or do you have to work at it? :-)
<notting> abadger1999: you can't remove another users buildroot
<abadger1999> notting: Exactly.
<jeremy> abadger1999: all I have to do is change the buildroot line in something I want to build
<abadger1999> That's the point.
<jeremy> abadger1999: it's absolutely trivial
<notting> abadger1999: so, you can override it with the macro on the commandline
<tibbs> Or in .rpmmacros, I think.
<f13> yep
<abadger1999> But it is something that just works with "id" whereas now you have to work around the brokenness.
<tibbs> Which means that you can and should set it to what you prefer and never care about what the package itself specifies.
<f13> its just waaaay to silly to spend any more time on this trivial thing which has NO bearing on how we build our packages for the distribution.
* rdieter covers ears, wishing never to hear about buildroots ever... ever again.  stop the madness.
<nirik> so, if we reject this again, it's just going to result in many more weeks of wasted rangling?
<dgilmore> so fine let them have there three lets move on
<abadger1999> But I was in the minority in the PC.  And I can be the minority here as well.
<rdieter> nirik: !!
<bpepple> Ok, before we drag this on forever, where are we on the packaging committee's draft?
<abadger1999> Like everyone else, I'm truly tired of this :-)
<f13> +1
* dgilmore has to go in 3 minutes
<bpepple> abadger1999: agreed.
<jeremy> +1
<bpepple> +1
<notting> +1
<jwb> 0
<nirik> +1 approve.
<tibbs> 0 (as I was on the PC vote)
<abadger1999> -1 :-)
<c4chris> +1
<rdieter> +1
<dgilmore> -1 still
but looks approved to me
<jwb> maybe it'll motivate axel to not break things with his repo
* jwb ducks
<bpepple> ok, I count 7 +1's, one 0, and two -1.  I consider this approved.
<f13> ok, can we never bring this up again?  Please?
<bpepple> f13: I'm all for that.
<rdieter> seconded.
<jeremy> f13: board action item! :)
<dgilmore> f13: sure
<c4chris> aye
<nirik> can we move on to something more meaningfull? :)
<bpepple> Ok, anything else from the packaging committee?
<notting> nirik: ok. tabs vs. spaces in spec files.
* f13 stabs notting
<rdieter> bpepple: that's it (I think).
<f13> I can't recall anything else.
<bpepple> rdieter: great, let's move on/
--- bpepple has changed the topic to: FESCO-Meeting -- EPEL
<bpepple> anything to report on from the EPEL sig?
<thl> bpepple, not much afaics
<dgilmore> bpepple: we have bugzill aand owners.epel.list sync up
<thl> bpepple, we had a meeting and talked a bit
<nirik> looks like some good discussion on the list, and we had a meeting and will have another this weekend.
<thl> and I didn#t finish the summary yet
<bpepple> sounds good.
<dgilmore> bpepple: i want to push out whats currently built this weekend as a testing repo
<notting> an epel question
<dgilmore> notting: ill need your help on that
<rdieter> dgilmore: yay!
<dgilmore> notting: sure
<notting> if we want to build a package for epel that depends on a package in core that's not in RHEL, do we need to wait on the core merge review? :)
<thl> notting, I'd say yes
<dgilmore> notting: no  but we will need to move it to our cvs
<thl> all packages in the repo should be reviewed
<nirik> I'd like to see all epel packages come from reviewed packages.
<notting> ok. note to self: bribe reviewer
<thl> nirik, +1
<rdieter> notting: that's the spirit!
<dgilmore> notting: add me to the cc list
<nirik> I'd be happy to look too.
<dgilmore> notting: i need to setup a sync for epel same as for extras
<bpepple> anything else, otherwise we can move on.
* thl hasn#t anything else regarding epel
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
* dgilmore has to go. catch you all latter
<bpepple> dgilmore: later.
<nirik> I have an item... per discussions with mschewnt on the list, I made a sponsor responsabilities shell...
<thl> I just posted to the fedora-extras-list asking for comments to shut that list down now
<nirik> http://www.fedoraproject.org/wiki/Extras/Schedule/SponsorResponsibilityPolicy
<thl> what is the FESCo opinion regarding closing the list now?
<nirik> I would appreciate comments/changes before it's ready to really vote on or the like.
<bpepple> thl: I'm fine with closing it.
<tibbs> I see no reason to keep the list around.
<jwb> kill it dead
<rdieter> die die die.
<notting> my only concern is what to do with extras users for fc5/fc6
-> fedora-list?
<bpepple> nirik: I'll give it a look this weekend.
<thl> notting, yes
<f13> gah.
* f13 isn't going to read fedora-list
<jwb> really?
<thl> notting, fedora-extras-list was never for really users iirc
<nirik> thanks bpepple, perhaps we could push the maintainer responsabilities at the same time.
<jwb> f13, me either
<bpepple> nirik: yeah, I've been dragging my feet long enough on that.
<nirik> did the mailing list reorg get stalled?
<tibbs> fedora-list is already filled with extras questions.  And livna and atrpms questions too.
<thl> nirik, waiting for hardware
<nirik> if we are shutting down extras, perhaps we could wait and do it at the same time as all the other changes?
<thl> so for now it is stalled
nirik, well, I would have prefered that, twoo
<nirik> is there an eta?
<thl> too
nirik, for the hardware: mid april afaik
and then it will take some more time to sort the details out
so I'd say that takes to long
kill f-e-li now
<nirik> ah, bummer. I'd be ok with shutting down fedora-extras now... should have a last post that points user questions at fedora-users and devel to fedora-devel?
<notting> mmcgrath: thl: you have a plan/rfresources/etc for this list thing on the wiki somewhere?
<tibbs> While doing merge reviews, we've seen some packages that Red Hat is essentially forking.
<rdieter> tibbs: details?
<thl> notting, only what got discusses months ago
<tibbs> Is this a cause for any real concern.
<notting> thl: ah, ok. afaik, mmcgrath was doing all the internal followup on that
<thl> notting, nothing about concrete plans; I'll chat with mmcgrath about it another time; maybe we can put something into the wiki then
* notting points thl and mmcgrath at each other :)
<tibbs> rdieter: for example, the nc package carries 17 patches that are twice as large as the upstream source.
<notting> tibbs: ipv6?
<tibbs> It doesn't support ipc6.
<thl> notting, I know that mmcgrath is doing the work, but yes, I should poke mmcgrath more often to get a status update ;-)
<nirik> tibbs: also sysklogd is a redhat version... sysklogd-rh... upstream is dead tho, so...
<sharkcz_work> also mc was "attacked" from the upstream for modifying default behaviour
<notting> tibbs: isn't upstream nc very very dead?
<tibbs> Not that I know of.
<rdieter> in cases of dead upstream, perhaps maintainer could ressurect at hosted.fedoraproject.org
* thl will wait for further comments regarding closing f-e-l on the list;
<tibbs> The point is, there are instances of this around and we should decide what needs to happen.
If we're going to keep with the core value of keeping close to upstream whenever possible, there will be conflicts.
* thl interprets this FESCo discussion as agreement to close the list soon
<notting> rdieter: i think that's overkill. not every maintainer wants to become the upstream just because they're packaging it
<jeremy> tibbs: it only looks like the nc package applies 9 patches.  none of which are large
<rdieter> imo, maintainer should work with upstream, and if not, give *very* convincing arguments to justify.
<bpepple> thl: I agree.  I didn't see any '-1'.
though we should probably have a vote for clarification.
<tibbs> jeremy: nc itself isn't large.
<thl> bpepple, we should also wait for the discussion on the list before we move on
<nirik> is upstream for nc openbsd?
<tibbs> And there are 17 patches in CVS; I guess some need to be nuked.
<rdieter> notting: I said 'perhaps', it would be nice to give back to oss community, if possible.
<bpepple> thl: agreed.
<thl> bpepple, I just wanted a ACK from FESCo for the direction, and I got that; that's enough
<thl> (for now)
<abadger1999> notting: Current guidelines are that if upstream is dead you have to be prepared to act out the role of upstream.
* thl makes room on the rabble seats
<thl> cu
<tibbs> I mean, if nobody has any problems with just keeping forks of packages in an SRPM then OK, but it sure sounds like that's against the goals of the project.
<rdieter> tibbs: it is against project goals, and be strongly discouraged (I won't say forbidden).
<tibbs> Last commit to upstream nc was nine days ago, BTW.  Doesn't seem dead to me.
<nirik> so upstream doesn't want any of those patches?
<rdieter> of course, depends on your definition of "fork".
<notting> nirik: it's openbsd. i expect them to be hostile. ;)
<tibbs> nirik: Well, that's the question.  I can't tell from the srpm whether anyone ever tried to send them.
<rdieter> I mean, see fedora/rh's libtool, for example. (:
<f13> technically anything with a patch applied is a "fork"
<nirik> yeah, at least an effort should be made....
<abadger1999> notting: From http://www.fedoraproject.org/wiki/Extras/OrphanedPackages    "Several reasons can also led to a package being retired: package has no upstream maintenance and has release critical bugs package's [or]  upstream no longer exists"
<tibbs> In the case of nc, it would probably be smarter to switch to one of the other variants.  But this isn't the only package that is just accumulating patches that nobody wants to rebase.
<nirik> I know spot was pushing the perl patches we were carrying upstream... which is great.
<abadger1999> "If you really want to maintain a retired package, then the process is much the same as claiming an orphaned package. However, you need to be aware that fixing release critical bugs etc becomes your responsibility."
<notting> abadger1999: *that's* fine. i just considering 'becoming upstream' to be announcing a project, hosting SCM, etc....
<nirik> tibbs: right, like sysklogd... hopefully it will get replaced by syslog-ng... but we need to keep carrying it until it does I fear.
<jeremy> I think that trying to get too caught up on this is kind of a doomed discussion
<abadger1999> notting: k.
<bpepple> jeremy: +1
<notting> tibbs: i'd suggest asking the maintainer if they've considered moving to the more active upstream
<nirik> yeah... perhaps more suited to mailing list? or will that generate too much flame?
<notting> tibbs: oddly, in the nc case, most of the patches are user-contributed via bugzilla
<c4chris_> looks like my other connection went boink...
<rdieter> buildroot! (that should do it)
<jeremy> (... having maintained a package that's got substantial amounts of changes from upstream)
* jwb glares at rdieter
<tibbs> The point is that since we do have project goals, we should at least document the places where we deviate from them by necessity and indicate what we intend to do about those deviations.
<abadger1999> tibbs: +1.
<tibbs> Some of these packages are simply ancient.  Things were different back then.
<jeremy> tibbs: indeed
<notting> abadger1999: along those lines, time to WORKSFORME some bugs on packages of mine ;)
<rdieter> buildroot, buildroot, buildroot!  It's not working.
<abadger1999> Forking is valid but we should document why it is being done.
<jwb> have we talked about koji yet?
<abadger1999> jwb: No.  And dgilmore had to leave :-(
<jwb> damn
<abadger1999> f13 is also involved, though.
<jwb> yes, but i already know what f13 will say
<tibbs> Does anyone know what's supposed to happen to new core packages that have passed review?
<bpepple> jwb: do you want an item on next weeks schedule about koji?
<f13> tibbs: bug closed when rebuilt into rawhide?
<tibbs> cdrkit ended up getting imported into extras, and it was a core package.
<notting> tibbs: new packages -> extras
<tibbs> "it was supposed to be a core package"
<jwb> bpepple, couldn't hurt.  i'd like to know where we stand on switching to it
<tibbs> So now we have a package in extras that obsoletes packages in core.
<abadger1999> tibbs: That makes more sense to me.  (Import into Extras)
<jwb> why does this matter?
<bpepple> jwb: I'll add an item for next week on that.
<f13> tibbs: and?
<jwb> bpepple, thanks
<notting> tibbs: that's ok. if cdrkit is built, f13 needs to do brew-voodoo
<tibbs> And, that was always completely against the rules and nobody's rewritten the rules yet.
<f13> tibbs: the package it obsoletes should probably be bounced from Core, and it needs to obsolete the package from previous COres
tibbs: there is a chicken/egg problem.
tibbs: new package has to exist before old package can get nuked
and nobody has sent me the mail to nuke the old package that cdrkit replaces.
<bpepple> Ok, we should probably start to wrap-up the meeting.
<tibbs> cdrkit is in the extras needsign queue; Harald built it eight hours ago.
<bpepple> tibbs: we can probably have this pulled then.
<jwb> cdrkit is the cdrecord fork?
<tibbs> Essentially, yes.
<jwb> k
<f13> pulled?
why pulled?
<bpepple> f13: sorry, was it a different conversation and didn't follow this thread fully.
<f13> ok.
<bpepple> I think that's about it... so if no one objects lets call it quits for this week.
* bpepple will end the meeting in 60
<nirik> thanks bpepple
<c4chris_> bpepple, fine with me
* bpepple will end the meeting in 30
<notting> thanks everyone
* nirik wishes we were able to get to the removing blocker bugs thing... oh well.
bpepple will end the meeting in 15
<bpepple> -- MARK -- Meeting End