From Fedora Project Wiki

< Extras‎ | SteeringCommittee

Revision as of 16:30, 24 May 2008 by Ravidiip (talk | contribs) (1 revision(s))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

2006 December 21 FESCo Meeting

Members

Present

  • thl
  • bpepple
  • tibbs
  • warren
  • ch4chris
  • abadger1999
  • dgilmore
  • spot
  • awjb
  • rdieter (late)

Absent

  • jwb
  • jeremy
  • scop

Summary

EPEL

  • warren: We internally talked about providing the entire RHEL5 and various levels of stack products on top of it to the EPEL buildsys. And multiple trees and channels of EPEL can be built into repos automatically based upon which dependencies they pulled in during build, or comps.
  • CentOS should have access to the additional stack products as well so Fedora conributers should still be able to test and develop against CentOS.
  • Still waiting for mirror space before pushing packages live.
  • disttag again. RH support currently works from rpm -qa lists of packages. So .el5 would confuse support.
  • Work needs to happen on tools to show NEVR.arch VendorName and GPGStatus. That will allow support to stop depending on disttag.
  • f13 has no problems with this now.
  • spot still considers it an abuse of the disttag: disttag is supposed to identify which distribution the package is built for. he thinks other repositories may start using disttag similarly if we start to do this.
  • Can we have .epel5 and .el6 (so tools have a chance to get better).
  • Only if NEVR bumps properly between RHEL5 and RHEL6.
  • This could be confusing to users of the repositories.
  • Vote: Use .epelX as disttag
  • +1: warren
  • -1: spot
  • 0: thl, c4chris, awjb, tibbs, abadger1999
  • warren: Another issue, we also discussed opportunities for RH engineers to participate in EPEL in formal ways. For example, there were some cool tools for Xen or Selinux management that were too late to make it into RHEL5. They would be great in EPEL5.

FESCo Workflow

  • thl starts discussion by noting that EPEL progress has been slow and in some ways is not well communicated. Is this a general issue for FESCo?
  • Things get discussed and forgotten and have to be discussed again.
  • Communication and drivers:
  • EPEL decision to open branching for sponsors and people with 5+ packages was not announced.
  • Do we need to enumerate the responsibilities of a driver for an issue?
  • Make sure progres is being made on an issue.
  • Recruit people to do work for the issue.
  • Working on it yourself.
  • tibbs: I never saw FESCo's job as being one that would produce any huge changes. Perhaps I'm just aiming too low, but I think the current level of progress is amazing.
  • cweyl: FESCo is in certain respects glue, not gasoline :)
  • FESCo provides guidance and helps to facilite people who have the time and energy to drive a project.
  • Accomplishments:
  • Extras methodology has subsumed Core.
  • Some of FESCo projects interface with Infrastructure. Perhaps we need better coordination there.

Opening Core

  • This is official and will happen. However, Red Hat people who are working on things from the Core end are on vacation due to the holidays.
  • FESCo's role in the new Core will be clearer as we close in on FUDCon/Fedora Hackfest.
  • warren is working on an announcement for Core packagers to start getting their packages into the review queue.

Comaintainers

Rebuilds

  • tibbs pushed a bunch of python packages.
  • tibbs: Most of the stuff that's left needs actual work due to API differences.
  • New updates system from lmacken may make it easier to catch changes to major components sooner.
  • nirik will send a list of EVR problems in Core package to jeremy.

Packaging Committee Report

  • Report went to the list.
  • iconcache has been vetoed by Core and is withdrawn for further revisions.

Maintainer Responsibility

  • bpepple will solicit feedback on fedora-extras-list for what's on the wiki.
  • Builders for FC <= 4 are still set to be closed on Jan 1.

Free Discussion

  • clement issue: Package has not been updated yet. We'll step in and fix it after the meeting.
  • rdieter to take a "No yum repo files in packages" rule to the Packaging Committee.
  • Possibly create a make clone-branch command that can safely replace cvs-import for updating branches.
  • nirik: FYI, I see extras has 980 bugs open. Of those 611 are in the NEW state. Thats 62% where no one has stepped up and assigned the bug to themselves.

Log

(10:00:10 AM) thl has changed the topic to: FESCo meeting -- Meeting rules at [WWW]  http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
(10:00:13 AM) thl: FESCo meeting ping -- abadger1999, awjb, bpepple, c4chris, dgilmore, jeremy, jwb, rdieter, spot, scop, thl, tibbs, warren
(10:00:16 AM) thl: Hi everybody; who's around?
(10:00:17 AM) ***bpepple is here.
(10:00:22 AM) tibbs: I'm here.
(10:00:24 AM) warren: here
(10:00:25 AM) ***c4chris is here
(10:00:29 AM) ***abadger1999 here
(10:00:47 AM) ***dgilmore is kinda here
(10:00:49 AM) thl: jwb said he'll be afk
(10:00:50 AM) dgilmore: mostly not
(10:00:56 AM) thl: mmcgrath ?
(10:01:25 AM) thl: seems not
(10:01:31 AM) thl has changed the topic to: FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update
(10:01:43 AM) thl: dgilmore, could you give a quick status update?
(10:01:44 AM) ***spot is here
(10:01:46 AM) ***awjb is here
(10:01:52 AM) thl: otherwise we'll simply skip epel
(10:02:10 AM) thl: (that would mean yet another week without real progress for EPEL)
(10:02:11 AM) thl: :-(
(10:02:17 AM) ***c4chris got yum to run on my ia64 box
(10:02:33 AM) warren: I have EPEL news.
(10:02:38 AM) c4chris: next is mock, then plague...
(10:02:57 AM) thl: warren, shoot
(10:03:02 AM) c4chris: then see how to integrate it with the rest (if at all possible...)
(10:03:14 AM) warren: We internally talked about providing the entire RHEL5 and various levels of stack products on top of it to the EPEL buildsys.
(10:03:39 AM) devrimgunduz [n=Devrim]  entered the room.
(10:03:40 AM) ***mmcgrath is here
(10:03:43 AM) mmcgrath: sorry.
(10:03:44 AM) warren: And multiple trees and channels of EPEL can be built into repos automatically based upon which dependencies they pulled in during build, or comps.
(10:03:57 AM) mmcgrath: I think we're still waiting on notting and the mirror space.
(10:04:07 AM) warren: Oh, there was another issue.
(10:04:33 AM) warren: Red Hat officially requests that .epelX be used as a disttag.  The reasons for this have changed slightly.
(10:04:43 AM) warren: Jesse has changed his mind and supports this.
(10:04:52 AM) ixs: warren: sounds good. only problem I'm still seeing there, the packagers might not have the whole stack available for testing purposes, depending on how good the rebuilds are coming along. Do you see a potential problem with that?
(10:05:10 AM) warren: ixs, not if CentOS does so.
(10:05:25 AM) warren: ixs, in any case, CentOS and users today are not using most of that stack at all, will it really be missed?
(10:05:26 AM) mmcgrath: warren: is it fine with RH if we have no dist tag at all on some packages?
(10:05:36 AM) ixs: warren: I'm no centos guy but last time I checked, they were not even sure themselves how they are offering the stack.
(10:05:36 AM) c4chris: so we build against CentOS ?
(10:05:39 AM) warren: mmcgrath, good question.
(10:05:41 AM) mmcgrath: Namely the ones that don't specify a dist tag :-)
(10:05:44 AM) warren: mmcgrath, it works like this:
(10:05:53 AM) warren: No disttag: fine in both RHEL5 and EPEL5.
(10:06:06 AM) warren: disttag: .el5 in RHEL5, .epel5 in EPEL5
(10:06:20 AM) thl: c4chris, the packages should be usable on centos; without that the whole stuff IMHO does not make to much sense for us
(10:06:23 AM) ***spot is still against this
(10:06:27 AM) ixs: warren: but I always thoguth that the whole stack (cluster, devel et al) is at least available for centos4
(10:06:44 AM) c4chris: thl, makes sense
(10:06:54 AM) warren: The legal, product and support guys were more worried about claiming ".el5" and what that implies.
(10:07:10 AM) warren: because support especially works from rpm -qa style lists, not deeper queries.
(10:07:34 AM) cgTobi_away [n=cgTobi]  entered the room.
(10:07:34 AM) ixs: sounds sensible IMHO.
(10:07:40 AM) warren: We also talked about improving future tools to mitigate this problem, some tool that outputs listings like:
(10:07:48 AM) ixs: no sense making work for support harder then it is.
(10:07:48 AM) warren: N-V-R VendorName GPGStatus
(10:07:57 AM) cgTobi left the room (quit: Nick collision from services.).
(10:08:01 AM) c4chris: then I can set my ia64 builder to build using CentOS I guess...
(10:08:05 AM) warren: foo-1.0-2.el5  Red Hat OK
(10:08:09 AM) thl: c4chris, nope
(10:08:13 AM) warren: bar-2.0-3.epel5  EPEL  OK
(10:08:30 AM) thl: c4chris, that will just confuise everything; we can't build some archs on rhel and others on centos
(10:08:33 AM) warren: listing tools would do this, and GUI tools would also do it
(10:08:33 AM) warren: oh
(10:08:37 AM) warren: N-V-R.arch
(10:08:54 AM) c4chris: thl, so th eother ones use RH ?
(10:09:01 AM) thl: c4chris, yes
(10:09:01 AM) warren: We suspect a combination of improving these tools plus unique disttags will help in support differentiation.
(10:09:04 AM) c4chris: s/th e/the /
(10:09:11 AM) c4chris: hmm
(10:09:16 AM) abadger1999: warren: Re: "providing the entire RHEL5 and various levels of stack products on top of it "  Will CentOS have access to those additional stack products?
(10:09:27 AM) warren: Red Hat does not *require* that EPEL accepts this.
(10:09:39 AM) warren: abadger1999, I think so, I will need to ask.
(10:09:41 AM) spot: abadger1999: they're all available in SRPM format, so they should be able to make their own bits
(10:09:45 AM) warren: abadger1999, it might be required for GPL compliance
(10:09:54 AM) c4chris: so I still have the issue of making sure I have the latest RH stuff online...
(10:10:22 AM) warren: Another issue is technical
(10:10:24 AM) spot: abadger1999: and if for some unknown reason, RedHat doesn't make the source available, i will. ;)
(10:10:33 AM) warren: .epelX as a disttag has no actual drawback.
(10:11:10 AM) thl: we will replace z00dax packages as .epel is higher than .el
(10:11:19 AM) warren: As long as it is understood....  no disttag is fine.  or use a  unique differentiating disttag in order to aid support.
(10:11:33 AM) warren: thl, repository mixing, not supported anyway.
(10:12:03 AM) thl: spot, your opinion on .epel?
(10:12:11 AM) warren: I understand that people have reservations about this.  But the vocal opponents in past discussions have changed their mind.
(10:12:23 AM) warren: spot, what reasoning do you dislike about this?
(10:12:59 AM) ixs: spot: I might take you up on that source offer soon...
(10:13:00 AM) spot: Honestly? I think we're misusing dist to cover up the fact that Red Hat support has shitty tools.
(10:13:10 AM) mmcgrath: At this point I don't care what its called, so if someone else does care (RH) then I say we accomidate.
(10:13:20 AM) spot: the dist tag was designed to identify the dist for which a package is built for
(10:13:26 AM) thl: spot, +1
(10:13:29 AM) spot: that dist is EL5, not EPEL5
(10:13:44 AM) mmcgrath: though spot does have a point ;-)
(10:13:49 AM) spot: you're hacking the use case, and i don't like it. not one bit.
(10:14:22 AM) mspevack left the room (quit: "Leaving").
(10:14:32 AM) ixs: ack. spot does definitly have a point. However, as stated above, if we can compromise and it's not a problem but solves a problem for others, we maybe should do that... however, I have no opinion about it anyways... ;>
(10:14:37 AM) warren: spot, the folks in the RH EPEL meeting generally agreed.
(10:14:51 AM) warren: spot, however, there is also no real technical detriment to using .epel as a disttag.
(10:15:01 AM) bpepple: ixs: agreed.
(10:15:08 AM) warren: There is today a *REAL* difference in support perception and confusion though.
(10:15:22 AM) spot: warren: so rather than apply yet another bandaid, perhaps building better support tools?
(10:15:24 AM) warren: Thus the people in the meeting agreed to do both.
(10:15:27 AM) thl: can I get some -1, 0, +1 for "use .epel as disttag" please? Consider that not as voting, I just want to know what people think about it currently
(10:15:38 AM) thl:  "use .epel as disttag" -- 0
(10:15:41 AM) c4chris: 0
(10:15:42 AM) spot: warren: we're trying to somehow embed formal supportability in the name, and i think thats awful.
(10:15:44 AM) awjb: 0
(10:15:44 AM) spot: -1
(10:15:48 AM) warren: 1) Use a differentiating disttag because there is no technical reason not to.
(10:15:51 AM) mmcgrath: 0.0000001
(10:15:54 AM) warren: 2) Improve the support tools as we move forward.
(10:15:55 AM) tibbs: 0
(10:15:56 AM) warren: +1
(10:16:09 AM) c4chris: can we have epel5 but el6 ?
(10:16:09 AM) abadger1999: 0
(10:16:28 AM) warren: c4chris, does epel5 < el6 in rpmvercmp?  I don't think so.
(10:16:31 AM) warren: whatever we pick now we have to stick with.
(10:16:32 AM) ixs: c4chris: -1. confusion ensues.
(10:16:32 AM) tibbs: I'm having trouble understanding both the pros and cons.  Is there any technical reason for one choice over another?
(10:16:42 AM) c4chris: ack
(10:16:48 AM) tibbs: Or is this entirely political?
(10:16:50 AM) ixs: warren: how long would waiting for the better tools delay epel?
(10:17:00 AM) abadger1999: warren: If we make sure we rebuild all packages between releases we can change dist tag.
(10:17:03 AM) warren: tibbs, support today largely uses rpm -qa style lists, which confuses the issue too much.  This is not support tools, but rather what customers perceive.
(10:17:17 AM) warren: ixs, not one bit
(10:17:25 AM) thl: warren, but the packages from epel are not even in el
(10:17:38 AM) warren: ixs, either way, .el5 or .epel5 in EPEL, EPEL can just move forward, and folks just have to deal with it.
(10:18:09 AM) spot: warren: RHAT support uses sysreport, it would be rather trivial to improve sysreport to compare rpm -qa output against, say, comps from RHEL 5
(10:18:21 AM) spot: i'd rather see the time spent there than abusing dist tags.
(10:18:30 AM) warren: spot, why is that necessary?  just look at the Vendor and GPG status instead.
(10:18:47 AM) cweyl: random thought: wouldn't the vendor tag be different between rhel and epel packages?
(10:18:49 AM) tibbs: If this is about customer perception, we already have a test case.
(10:19:00 AM) spot: warren: exactly. we're talking a few additional lines of code to avoid having to misuse dist tag
(10:19:03 AM) thl: cweyl, yes, it should be different
(10:19:07 AM) ixs: warren: in that case I would probably agree with spot. his point is solid and .epel would be a misuse of the dist-tag.
(10:19:15 AM) tibbs: Has anyone seen confusion over the fact that we use "fc6" for Fedora Extras packages?
(10:19:29 AM) warren: Is it really misuse when there really is no technical detriment to .epel5?
(10:19:40 AM) spot: warren: yes.
(10:19:57 AM) spot: you can wear a barrel as a shirt, but that ain't what it is for.
(10:20:00 AM) ixs: warren: the idea behind the dist was to identify the distro it was built for. we have fc6 and el5 and not fe6.
tibbs tibbs|h
(10:20:16 AM) warren: OK, if folks here are against changing, that's fine.  Red Hat cannot mandate this.  Red Hat only requested it.
(10:20:18 AM) cweyl: thl: then why not use that for differentiation? :)
(10:20:38 AM) abadger1999: tibbs: Not sure if it's a fair comparison... we (the community) support FC and FE equally.
(10:20:41 AM) spot: i think there are lots of ways to tell whether a package came from Red Hat (tm) or not. :)
(10:20:44 AM) ixs: warren: identifying the source of the package by the disttag was never planned as far as I understand it.
(10:20:54 AM) ixs: (even though thirdparty repos do that)
(10:21:01 AM) warren: ixs, folks were not concerned about .fc6 vs .fe6 because they have similar levels of support expectations.  RHEL5 and EPEL5 are quite different in that regard.
(10:21:17 AM) spot: this opens a pandora's box for other repos to start abusing dist tags
(10:21:22 AM) warren: ixs, RH does desire EPEL to be seen as a 3rd party repo.
(10:21:33 AM) tibbs: abadger1999: different mailing lists, different people to blame.  "Red Hat sucks because I couldn't get help with <random extras package>".
(10:21:39 AM) spot: "EPEL tags their name in their packages, why is it bad for me to put DAG or yoMommA in mine?"
(10:21:50 AM) spot: or jpp
(10:21:54 AM) warren: Another issue, we also discussed opportunities for RH engineers to participate in EPEL in formal ways.
(10:22:05 AM) ixs: warren: i was talking about fedora repos in general (at, lvn etc.) from the technical point of view epel is just another build target for the fedora-buildsys.
(10:22:13 AM) warren: For example, there were some cool tools for Xen or Selinux management that were too late to make it into RHEL5.  They would be great in EPEL5.
(10:22:36 AM) thl: warren, the usual extras rules should work to get  a pacakge into EPEL
(10:22:41 AM) ixs: spot: that's actually being done by 3rdparty repos.
(10:22:42 AM) warren: thl, nod
(10:22:53 AM) spot: ixs: yes, but we're trying to set a standard here. :)
(10:23:00 AM) ixs: I know.
(10:23:03 AM) thl: well, we run quite late already
(10:23:05 AM) warren: If folks here are against .epel disttag, that is fine.
(10:23:14 AM) thl: I'd like to generally discuss how to proceed with EPEL
(10:23:15 AM) warren: spot, please help to improve the support reporting tools OK?
(10:23:21 AM) thl: it starts only slowly
(10:23:24 AM) spot: warren: sure.
(10:23:40 AM) thl: and is missing a real person that drives the whole thing forward
(10:23:45 AM) thl: do we like that?
(10:24:10 AM) thl: for example the "open epel to sponsors and people with 5 packages or more" thing
(10:24:15 AM) thl: it got decided last week
(10:24:22 AM) ixs: warren: I do see the problem with customer expectations. That's one of the reasons the unsupported kernel modules were dropped from el3 to el4 (shame!!!). But do you really think that el tags from rh and epel tags from epel would change customer expectations? if they do not understand unsupported in the rpm name, why should they grok epel?
(10:24:26 AM) thl: but no one annouced it to the world properly
(10:24:36 AM) thl: it was just mentioned in the summary
(10:24:47 AM) warren: ixs, " unsupported kernel modules were dropped from el3 to el4" means what?
(10:24:49 AM) thl: that's not enough for something like that
(10:25:04 AM) bpepple: thl: yeah, I'm guessing most of the extra contributors missed that announcement.
(10:25:05 AM) spot: warren: there used to be a kernel-unsupported
(10:25:08 AM) ixs: warren: there was a kernel-modules-unsupported package in el3. it was not included in el4 anymore.
(10:25:23 AM) spot: people blew right past it. :)
(10:25:26 AM) ixs: warren: there were lots of nice drivers for hardware, not supported by rh. cyclades e.g.
(10:25:26 AM) c4chris: thl, right.  Call for a volunteer to step forward?
(10:25:34 AM) cgTobi_ [n=cgTobi]  entered the room.
(10:25:44 AM) Redhat71 [n=ChatZill]  entered the room.
(10:25:52 AM) ixs: warren: I fear customers expecting support for 3rd party from rh is a problem not being solved by a different dist-tag.
(10:25:57 AM) thl: c4chris, the thing it; that a general problem in fesco imho
(10:26:03 AM) thl: we discuss a lot of things
(10:26:19 AM) thl: but there is often only slow progress; things get forgotten again and discussed anew
(10:26:29 AM) thl: and I more and more think we suck
(10:26:36 AM) thl: and I'm wondering if that's my fault...
(10:26:41 AM) spot: ok, so epel needs someone to lead the charge
(10:26:42 AM) c4chris: thl, agreed.  So let's start to put a driver in the seat...
(10:26:44 AM) warren: thl, you can only do so much.
(10:26:53 AM) bpepple: warren: agreed.
(10:27:00 AM) c4chris: thl, don't blame yourself
(10:27:01 AM) spot: dgilmore and mmcgrath seem to have been most interested in it to date
(10:27:01 AM) thl: c4chris, well, dgilmore and mmcgrath are the drivers normally
(10:27:16 AM) thl: they are listed as owners of the task
(10:27:20 AM) c4chris: thl, sure, but let's make it a bit more formal
(10:27:24 AM) mmcgrath: we've been pushing foward slowly, we're just waiting on things like the mirror to get created.
(10:27:32 AM) thl: but, as I said, it's a general thing that applies to other talsks as well
(10:27:38 AM) spot: ok, so now they're formally in charge of epel. if you want more packages, harass the lists.
(10:27:42 AM) mmcgrath: c4chris: you mean like a wiki page? http://fedoraproject.org/wiki/EnterpriseExtras
(10:27:43 AM) spot: make sure people know they can do it.
(10:27:50 AM) thl: that's btw the reason why I put
(10:27:52 AM) thl has changed the topic to: FESCo meeting -- Improve FESCo's workflow
(10:27:56 AM) mmcgrath: people have been branching for weeks, creating builds.
(10:28:02 AM) ***mmcgrath runs off to lunch and is hungry :-)
(10:28:02 AM) thl: on the schedule (but we have reached it already)
(10:28:05 AM) warren: I don't have control over mirror layout
(10:28:13 AM) c4chris: mmcgrath, I mean make a bit more noise on the ml
(10:28:13 AM) ***spot assumes that unless people are screaming, its working ok. :)
(10:28:19 AM) abadger1999: Hmm.. so ideally tasks should have a driver who is responsible for all the legwork.
(10:28:31 AM) thl: c4chris, what do you mean by "make it a bit more formal"
(10:28:45 AM) thl: abadger1999, well, that's how it should work already
(10:28:51 AM) thl: that's how it was meant always
(10:28:54 AM) c4chris: thl, attach a name to each project that needs driving forward
(10:29:05 AM) thl: c4chris, the names are there already
(10:29:11 AM) thl: just look at the shedule
(10:29:46 AM) thl: that why I'm always saying "please look at the schedule and look out for your name" ;-)
(10:29:50 AM) abadger1999: Do we need to enumerate what "legwork" means?
(10:29:57 AM) abadger1999: Or is the bottleneck something else?
(10:30:32 AM) thl: well, the name IMHO means: driving the whole think forward and taking care of it
(10:30:44 AM) thl: that can mean: get others to do the hard work
(10:30:55 AM) thl: just getting it sone somehow
(10:31:25 AM) thl: or does anyone have a better idea?
(10:31:28 AM) ixs: ahhh. a project manager?
(10:31:36 AM) nirik: thl: so you are thinking that epel is moving too slow? or ?
(10:31:52 AM) tibbs: When you put someone's name next to a task in the schedule, make sure they know that they're expected to drive it forward.
(10:32:02 AM) thl: nirik, well, epel: yes, but it's a general thing
(10:32:14 AM) thl: nirik, what did FESCo achieve in the past six months?
(10:32:30 AM) c4chris: thl, I'm not sure what can reasonably be done
(10:32:32 AM) thl: was there anything big we can proud off?
(10:32:57 AM) tibbs: We can be proud of the entire project, I'd think.
(10:33:05 AM) thl: tibbs, I put those names there only after I asked people if they take care of it
(10:33:27 AM) thl: tibbs, well, it's okay, biut there is still a lot to improve IMHO...
(10:33:28 AM) tibbs: I never saw FESCo's job as being one that would produce any huge changes.
(10:34:17 AM) cgTobi_away left the room (quit: Connection timed out).
(10:34:21 AM) thl: tibbs, well, it seems  some people expect it
(10:34:31 AM) thl: they told me in private that they dislike FESCo
(10:34:45 AM) tibbs: Perhaps I'm just aiming too low, but I think the current level of progress is amazing.
(10:34:46 AM) thl: and I partly agree; FESCo should driver the project forward
(10:34:51 AM) c4chris: thl, that's not very productive
(10:34:55 AM) cweyl: from a rabble view, to me FESCo has always guided, facilitated and enabled those with motivation/energy in their particular quests
(10:35:05 AM) cweyl: FESCo is in certain respects glue, not gasoline :)
(10:35:07 AM) c4chris: thl, why don't they try to help drive things forward?
(10:35:10 AM) thl: and currently we are only more maintaining than improving it
(10:35:15 AM) tibbs: Lord, how much more forward can the project be driven?
(10:35:51 AM) c4chris: thl, being grumpy is always easy
(10:35:57 AM) tibbs: I mean, the Extras methodology has subsumed Red Hat.  Core is being dissolved.  It wouldn't have happened if Extras was a festering pit.
(10:36:09 AM) c4chris: thl, doing something constructive about it is much harder
(10:37:06 AM) thl: so in other words: most people like the way how everything works currently?
(10:37:16 AM) c4chris: we are supposed to help and provide direction
(10:37:27 AM) c4chris: not necessarily do the whole work ourselves
(10:37:36 AM) jlayton left the room (quit: "leaving").
(10:37:42 AM) thl: c4chris, no, we really should not do all the work ourselves
(10:37:52 AM) thl: definitely not
(10:37:55 AM) bpepple: thl: I agree we can do some things better, but we can't do all the heavy lifting.
(10:38:32 AM) thl: we for example still have no stable webinterface for packages with a URL that does not change
(10:38:41 AM) thl: co-maintainership is lingering around for a long time
(10:38:47 AM) Redhat71 left the room.
(10:38:53 AM) thl: most of the stuff that's on the schedule is there for a long time already
(10:39:05 AM) thl: anyway, while I'm talking about hte schedule
(10:39:28 AM) thl: let's stop here and get back to it to get to some of the other topics
(10:39:30 AM) tibbs: Note that we have to interface with infrastructure on the first two things you listed.
(10:39:37 AM) nirik: perhaps this is good discussion for the list? people can bring up their concerns there?
(10:39:44 AM) bpepple: thl: part of the problem why some of the items have been there so long is that they are dependent of other issues (I'm thinking of co-maintainership)
(10:39:51 AM) tibbs: Are you saying that we were lax in our interfacing with the infrastructure team?
(10:40:28 AM) thl: nirik, yeah, maybe; let's see what people say when they read the summarie of this meeting
(10:40:33 AM) ***rdieter arrives panting, late.  sorry folks.
(10:40:40 AM) thl: bpepple, well, that does not stop us from working out rules
(10:40:52 AM) bpepple: thl: agreed.
(10:41:01 AM) thl: e.g. primary-maintainer and co-maintainers or are all equal?
(10:41:13 AM) thl: or even a more wiki-style approach for packages
(10:41:15 AM) thl: ?
(10:41:32 AM) thl: anyway, it's getting late
(10:41:36 AM) thl: let's move on
(10:41:37 AM) thl has changed the topic to: FESCo meeting -- Opening Core - (warren, jeremy, rdieter) -- status update
(10:41:44 AM) thl: warren, jeremy, rdieter ?
(10:42:07 AM) thl: is the "Core gets merged into Extras" now official?
(10:42:21 AM) rdieter: no news here (from me anyway)
(10:42:39 AM) warren: thl, it has been official as the plan since the summit
(10:42:48 AM) warren: thl, it will happen, no questions asked
(10:42:53 AM) warren: thl,  just a question of when
(10:43:02 AM) warren: thl, company is pretty much shut down now
(10:43:08 AM) rdieter: jeremy said good things at the last Board meeting, but I'll let him say so (if he wants). (:
(10:43:42 AM) warren: thl, today core maintainers have the option of asking for reviews to prep for moving.
(10:43:43 AM) thl: warren, k; when do we and/or the board clarify the FESCo future and it's position in the whole game?
(10:44:20 AM) rdieter: when?  now.  Who?  FESCo, imo.  Just do it.
(10:44:24 AM) warren: thl, that picture will become clearer as we approach the fedora developer meeting in late january.
(10:44:44 AM) warren: thl, meanwhile... just do it
(10:44:57 AM) thl: okay :)
(10:45:00 AM) rdieter: warren: fed dev meeting?
(10:45:05 AM) thl: anything else regarding the merge?
(10:45:12 AM) warren: rdieter, all the fab list discussion?
(10:45:13 AM) bpepple: rdieter: FUCcon I assume.
(10:45:21 AM) rdieter: Ah, early Feb, then. (:
(10:45:40 AM) rdieter: FUDConBoston2007.
(10:45:42 AM) bpepple: s/FUCcon/FUDcon/
(10:45:43 AM) warren: current proposed is Jan 26th for FUDCON, 27-28th for developer meeting
(10:45:56 AM) thl: ?
(10:45:57 AM) rdieter: hmm... changed dates on me?
(10:46:01 AM) c4chris: so should we post to maint telling core packagers to submit their stuff for review?
(10:46:03 AM) thl: yet another week earlier?
(10:46:06 AM) ***warren looks again
(10:46:11 AM) bpepple: warren: wasn't it Feb 2-4
(10:46:18 AM) thl: bpepple, yeah, I think so
(10:46:30 AM) warren: i'm confused
(10:46:45 AM) rdieter: website still says Feb 2., http://barcamp.org/FudconBoston2007
(10:46:53 AM) thl: warren, https://www.redhat.com/archives/fedora-announce-list/2006-December/msg00005.html
(10:47:05 AM) nman64 left the room (quit: Remote closed the connection).
(10:47:08 AM) warren: ok, same idea
(10:47:16 AM) warren: one day of talks with public invited
(10:47:28 AM) rdieter: and, btw, we need to get as many FESCo folks there as possible, esp thl. (:
(10:47:29 AM) warren: the two following days are by-invite only developer hackfest
(10:47:36 AM) warren: rdieter, yes, I'm working on that.
(10:47:45 AM) awjb: rdieter, so should I swim?
(10:48:06 AM) ***thl wonders if that's really worth flying across the ocean...
(10:48:13 AM) rdieter: awjb: Do what ya gotta do man.  I bet we can find some better way though.
(10:48:21 AM) thl: awjb, that will take some time, I suggest you start soon ;)
(10:48:22 AM) warren: We can't afford to fly everyone, but we'll try.
(10:48:26 AM) bpepple: thl: yeah, pretty long trip.
(10:48:32 AM) awjb: thl, kk ;)
(10:48:56 AM) c4chris: so, do we need to make noise about reviewing core packages ?
(10:49:05 AM) c4chris: or is the noise going already ?
(10:49:11 AM) thl: c4chris, yeah, why not
(10:49:23 AM) thl: c4chris, but I suggest a RH employee should post that
(10:49:26 AM) ***nirik thinks the sooner the better for reviewing.
(10:49:33 AM) bpepple: nirik: +1
(10:49:43 AM) c4chris: please 1 step forward :-)
(10:49:57 AM) thl: nirik, +1
(10:50:17 AM) tibbs: Hmmm.
(10:50:21 AM) c4chris: so who is RH here ?
(10:50:52 AM) thl: warren, jeremy, could you do that?
(10:51:17 AM) tibbs: It doesn't really have to be done by a RH employee.
(10:51:30 AM) thl: tibbs, agreed, but it might be better...
(10:51:39 AM) warren: thl, that is already the plan.
(10:51:44 AM) thl: warren, k, thx
(10:51:47 AM) thl: let's move on
(10:51:49 AM) thl has changed the topic to: FESCO-Meeting -- Encourage co-maintainership -- c4chris
(10:51:50 AM) warren: I'll make it clearer with announcements and such...
(10:51:53 AM) thl: c4chris, any news?
(10:52:03 AM) c4chris: I saw a patch
(10:52:06 AM) warren: btw, is initialcc workinG?
(10:52:12 AM) nirik: warren: yes. ;)
(10:52:14 AM) tibbs: That's the rumor.
(10:52:23 AM) c4chris: initialcc sholuld be working now
(10:52:42 AM) c4chris: anybody tested this?
(10:52:48 AM) nirik: I can confirm it worked on a package that has me as maintainer and someone else in cc.
(10:52:57 AM) rdieter: nice
(10:52:57 AM) thl: nice :)
(10:52:57 AM) c4chris: cool
(10:53:14 AM) thl: k, so now we need some rules around co-maintainership
(10:53:23 AM) thl: c4chris, do you have something prepared already?
(10:53:33 AM) c4chris: thl, no
(10:53:39 AM) thl: otherwise I can do that between christmas and new year
(10:53:45 AM) thl: I should have a bit of free time then
(10:53:48 AM) ***warren must leave for chiropractor now.
(10:53:49 AM) c4chris: but I should have some time over new year
(10:54:02 AM) tibbs: We should probably brainstorm on-list or after the meeting.  I have a few ideas.
(10:54:16 AM) rdieter: ok
(10:54:17 AM) c4chris: tibbs, sounds good
(10:54:20 AM) bpepple: tibbs: +1
(10:54:28 AM) thl: tibbs, can you add some ideas to the wiki?
(10:54:35 AM) tibbs: Sure.
(10:54:36 AM) thl: it'll simply try to work out spomething
(10:54:50 AM) thl: together with folks that are around on IRC
(10:54:51 AM) tibbs: Under EncourageComaintainership?
(10:55:06 AM) thl: and then I'll send it to the list for further discussions
(10:55:13 AM) thl: tibbs, yes please
(10:55:33 AM) thl: k, so let's move on
(10:55:34 AM) thl has changed the topic to: FESCo meeting -- MISC -- lots of python stuff still needs rebuilding -- any better this week
(10:55:39 AM) thl: nirik, tibbs ?
(10:55:43 AM) tibbs: It should be much better.
(10:55:54 AM) nirik: I didn't get much chance to work on it... but tibbs did push a bunch
(10:56:06 AM) tibbs: Most of the stuff that's left needs actual work due to API differences.
(10:56:21 AM) nirik: there is a new broken dep in release repos... rpy... R was rebuilt and rpy needs rebuilding.
(10:56:28 AM) nirik: if jose doesn't do that soon I will do so.
(10:56:32 AM) tibbs: xmldiff even passes when I run it in my local mock but dies in the buildsys.
(10:56:48 AM) tibbs: And of course there's plenty of bustedness unrelated to Python.
(10:56:57 AM) thl: well, I'm wondering if we should have a rule to prevent stuff like that in the future
(10:57:04 AM) nirik: yeah, there is the wx stuff
(10:57:07 AM) tibbs: The libwx_* stuff is really bloating the list.
(10:57:17 AM) thl: e.g. a "if you change something that breaks other packages you have to queue rebuilds for them" ?
(10:57:33 AM) nirik: thl: with the new updates system I think it will not let you push broken updates... lmacken ?
(10:57:37 AM) c4chris: thl, maybe a bit too tough
(10:57:40 AM) thl: (that's just a rough quick-and-dirty-rule)
(10:57:51 AM) thl: c4chris, I know ;-)
(10:57:53 AM) tibbs: I personally don't believe in queueing rebuilds without at least testing in local mock first.
(10:58:07 AM) thl: tibbs, why? does it hurt anyone?
(10:58:16 AM) thl: builders are often idle in any case
(10:58:17 AM) nirik: for release I would say you should coordinate with maintainers of packages that need rebuild and push all of them at once when they are rebuilt.
(10:58:27 AM) thl: nirik, sure, that was just meant for devel
(10:58:39 AM) tibbs: I don't want to commit something that's broken, so I always test first.  It's just courtesy.
(10:58:55 AM) ***nirik also tests in local mock before committing.
(10:59:01 AM) ***thl does not
(10:59:14 AM) ***rdieter does sometimes. (:
(10:59:28 AM) ***bpepple tests in mock normally first also.
(10:59:36 AM) ***awjb does test in mock
(10:59:46 AM) ***c4chris too <aol/> :-)
(10:59:47 AM) nirik: in any case, I can poke at some more python/wx issues and that rpy problem...
(11:00:01 AM) thl: nirik, that would be great
(11:00:07 AM) nirik: there are still some core packages with EVR issues... I filed bugs, but no activity Ican see.
(11:00:29 AM) rdieter: nirik: maybe they're stalling/waiting for merge?
(11:00:30 AM) thl: nirik, send a list with bug numbers to jeremy and ask him to poke people
(11:00:40 AM) c4chris: nirik, ah, comaintainers :-)
(11:01:04 AM) thl: rdieter, well, the merge is only for devel, but stuff often needs to be fixed in FC5 or FC6 afaics
(11:01:07 AM) nirik: I dunno. I can mail whoever can light a fire... if it will help
(11:01:32 AM) thl: it afaics often helps if jeremy pokes people ;)
(11:01:39 AM) thl has changed the topic to: FESCo meeting -- Packaging Committee Report
(11:01:42 AM) rdieter: nirik: be careful, someone might accuse you of being rude.
(11:01:43 AM) rdieter: (:
(11:01:54 AM) nirik: device-mapper, lvm2, mozilla and xen all have EVR issues in release versions.
(11:01:55 AM) tibbs: I take it everyone received the summary.
(11:02:02 AM) bpepple: tibbs: yup.
(11:02:27 AM) ***thl is just searching for it again
(11:02:29 AM) nirik: rdieter: sure. I have a pretty good +5 flameproof suit tho. ;)
(11:02:29 AM) tibbs: The iconcache proposal has been withdrawn by Rex pending more discussion.
(11:02:52 AM) rdieter: nirik: glad to hear it.
(11:02:54 AM) ***thl found it
(11:02:55 AM) bpepple: tibbs: yeah, that had quite a bit of discussion. ;)
(11:03:18 AM) tibbs: Well, there's are a few fundamental disagreements, but no matter.
(11:03:27 AM) thl: Looks all fine to me
(11:03:39 AM) thl: or does anyone dislike something from the PCs report?
(11:03:43 AM) tibbs: Point by point:
(11:03:57 AM) tibbs: The Provides:/Obsoletes: draft.
(11:04:07 AM) tibbs: scop isn't here today.
(11:04:19 AM) tibbs: http://fedoraproject.org/wiki/PackagingDrafts/ProvidesObsoletes
(11:04:32 AM) tibbs: Or will this take too much time?
(11:04:50 AM) thl: tibbs, probably
(11:05:00 AM) thl: tibbs, that what the report is for IMHO
(11:05:12 AM) thl: if people don#t look at it it's there fault
(11:05:16 AM) bpepple: thl: agreed.
(11:05:21 AM) tibbs: Indeed, but I wasn't sure if folks would want an up or down vote on each change.
(11:05:22 AM) thl: their
(11:05:40 AM) rdieter: any screams of horror? no?  good. (:
(11:05:43 AM) thl: tibbs, no, people IMHO should just yell if they dislike something
(11:06:00 AM) tibbs: Well, screams of horror over iconcache, but no complaints otherwise.
(11:06:08 AM) c4chris: no yell here
(11:06:18 AM) thl has changed the topic to: FESCo meeting -- Maintainer Responsibility Policy -- bpepple -- EOL plans
(11:06:23 AM) thl: bpepple, any news?
(11:07:13 AM) thl: seems bpepple is afk
(11:07:13 AM) bpepple: Just need to write-up something to post to f-e-l to get community feedback on the suggestions on the wiki.
(11:07:23 AM) thl: bpepple, k
(11:07:29 AM) cgTobi_ is now known as cgTobi
(11:07:37 AM) bpepple: Hopefully, I can get to it before the new year.
(11:07:38 AM) thl: bpepple, but the plan remains to close the builders on Jan 01 ?
(11:07:43 AM) bpepple: thl: yes.
(11:07:53 AM) thl: bpepple, k
(11:08:00 AM) thl has changed the topic to: FESCo meeting -- Free discussion around Fedora Extras
(11:08:03 AM) thl: anything else?
(11:08:04 AM) bpepple: I didn't hear any screaming on the mailing list about it.
(11:08:14 AM) thl: bpepple, that's a good sign :)
(11:08:51 AM) thl: what about the clement issue? the pacakge with the repo file in it?
(11:09:00 AM) thl: did anybody watch that further?
(11:09:22 AM) thl: do we want to prevent that in the future? Do we need a rule "no yum.repo files are allowed" ?
(11:09:24 AM) cgTobi: ixs: how was your class?
(11:09:24 AM) nirik: he replied back to the list, but I haven't seen anything from him since then.
(11:09:33 AM) tibbs: The package has not been updated.
(11:09:55 AM) thl: hans (his sponsor) in moving to another house and thus a bit busy
(11:09:57 AM) bpepple: thl: Yeah, we should put something explicitly forbidding it on the wiki.
(11:10:01 AM) c4chris: thl, I think we should have such a rule
(11:10:05 AM) rdieter: just checked cvs, reference to repo file is still there.  grr..
(11:10:29 AM) thl: who will handle that? FESCo or PC?
(11:10:34 AM) tibbs: We can't just ban packages adding repositories; that might be actually useful.
(11:10:37 AM) bpepple: someone needs to step-in and fix it if Hans isn't around.
(11:10:43 AM) c4chris: at least, the package is not in the repo (according to PackageStatus)
(11:11:01 AM) rdieter: tibbs: Oh, I think we can (or should)
(11:11:02 AM) thl: tibbs, for eample?
(11:11:07 AM) thl: rdieter, +1
(11:11:07 AM) graveyard [n=graveyar]  entered the room.
(11:11:21 AM) bpepple: rdieter: agreed.
(11:11:29 AM) rdieter: I'll do the followup cluestick whacking after the meeting.
(11:11:35 AM) tibbs: Well, you might have a package that adds, say, dribble or whatever.
(11:11:50 AM) tibbs: It would be a big political issue over whether that's allowed and wanted, etc.
(11:12:02 AM) thl: tibbs, yeah, but why should such a package be in Extras?
(11:12:10 AM) rdieter: tibbs: stuff like that needs to have explicit permission, if ever.
(11:12:22 AM) tibbs: Because it would be useful.
(11:12:38 AM) tibbs: It's tough to make up a hypothetical in 30 seconds that you can't easily shoot down for some other reason.
(11:12:46 AM) thl: tibbs, if we can enable a repo that we could put it contents into Extras...
(11:12:50 AM) c4chris: tibbs, I'd rather have a rule that says we don't want them, and have a few exceptions granted where useful
(11:13:00 AM) rdieter: tibbs: let's just stick with simple "no way", unless good reasons can be made for exceptions.
(11:13:04 AM) nirik: if a usefull case comes up, then the guidelines could be changed?
(11:13:10 AM) thl: rdieter, +1
(11:13:18 AM) thl: nirik, sure
(11:13:32 AM) rdieter: and I'm pretty sure there won't ever be any exceptions. (:
(11:13:44 AM) thl: rdieter, so will the PC handle it?
(11:13:54 AM) tibbs: It's FESCo's decision, IMHO.
(11:14:07 AM) rdieter: thl: I will wearing my PC/FESco/Board badge, whatever. (:
(11:14:10 AM) bpepple: tibbs: actually I think PC would be a better place.
(11:14:11 AM) c4chris: tibbs, I tend to agree
(11:14:12 AM) ChanServ left the room (quit: Shutting Down).
(11:14:20 AM) thl: argh
(11:14:44 AM) thl: we need a better scheme in the merged world to make sure what's PCs job, and what FESCo job
(11:14:54 AM) c4chris: let's put it this way: FESCo asks the PC to make a rule...
(11:14:57 AM) ChanServ [ChanServ]  entered the room.
(11:14:57 AM) mode (+o ChanServ ) by irc.freenode.net
(11:15:05 AM) rdieter: right, I see PC more as legislative, FESCo more executive branch.
(11:15:06 AM) thl: tibbs, the rule would need to exists under the packaging namesapce afaics
(11:15:45 AM) rdieter: this one is case of common sense, and security implications.
(11:15:48 AM) thl: rdieter, I see a shitload of work for FESCo oin the future and we need a way to say "SIG/Foo/PC/Bar, you need to hanle that"
(11:16:01 AM) thl: handle
(11:16:11 AM) rdieter: thl, no disagreement there.  We certainly need more delagation, and SIGs.
(11:16:12 AM) bpepple: thl: +1
(11:16:26 AM) c4chris: sounds fine to me
(11:16:34 AM) thl: anyway, regarding the issue at hand
(11:16:40 AM) tibbs: Whatever committee does this must be certain not to ban fedora-release.
(11:16:47 AM) thl: the rule would need to live in the wiki below Packaging/ afaics
(11:16:55 AM) thl: thus IMHO the PC need to accept it
(11:16:55 AM) rdieter: tibbs: you found the one exception! (:
(11:17:10 AM) abadger1999: This is a "what to package" rather than a "how to package" question which usu. means FESCo.
(11:17:21 AM) blarney [n=blarney]  entered the room.
(11:17:44 AM) thl: abadger1999, but there are no special "what to package" rules anywhere
(11:17:54 AM) tibbs: Umm, we're just making one.
(11:18:00 AM) thl: and it needs to be checked in the review guidlines and those are owned by the PC
(11:18:00 AM) blarney: spot: ping
(11:18:04 AM) c4chris: abadger1999, well, it's a bit like: don't package .la and .a files...
(11:18:10 AM) abadger1999: kmods
(11:18:11 AM) thl: c4chris, +1 ;)
(11:18:35 AM) thl: well, it's late
(11:18:37 AM) tibbs: In any case, if FESCo wants to expand PC's mandate, I won't object.
(11:18:49 AM) rdieter: I'll take it to PC too, this one should be easy to pass without pissing off anyone else... (I haven't filled my quota this week).
(11:18:56 AM) abadger1999: rdieter:  :-)
(11:18:59 AM) thl: rdieter, thx
(11:19:16 AM) thl: tibbs, we need to adjust that in any case for the new merged worlds order afaics
(11:19:19 AM) spot: blarney: yes?
(11:19:29 AM) thl: k, so anythign else we should discuss?
(11:19:30 AM) tibbs: thl: I believe we do.
(11:19:49 AM) ***c4chris needs to attend to a few family things soon...
(11:19:52 AM) thl: what about the "don#t use cvs-import after the initial import" ?
(11:20:09 AM) ***thl will end the meeting in 60
(11:20:11 AM) rdieter: some folks really like using that afterwards..
(11:20:15 AM) blarney: spot: any chance you could update rpy (no word from jmatos): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220403 it's blocking the R upgrade
(11:20:18 AM) blarney: ?
(11:20:19 AM) tibbs: I never use it myself.
(11:20:20 AM) bpepple: thl: Maybe we can modify the script not to even allow that usage.
(11:20:25 AM) jcollie: rdieter, because ther don'
(11:20:31 AM) tibbs: Someone once proposed a "make clone-branch" command,
(11:20:35 AM) jcollie: er because they don't want to learn cvs
(11:20:46 AM) nirik: blarney: I will if spot won't. Did you see that there are newer versions available?
(11:20:50 AM) tibbs: which would copy, say, the files in "devel" into "FC-6"
(11:20:56 AM) rdieter: tibbs: that would help (I'd like that)
(11:21:00 AM) blarney: nirik: yes, I saw that
(11:21:12 AM) spot: blarney: i'll rebuild the existing version.
(11:21:16 AM) tibbs: I would use it extensively, but I have no idea how to implement it.
(11:21:19 AM) ***thl will end the meeting in 30
(11:21:32 AM) nirik: spot: thanks. Let me know if I can test build or assist you...
(11:21:43 AM) c4chris: thl, we should provide some better alternative I guess...
(11:21:57 AM) thl: let's discuss the cvs-import stuff in a later meeting
(11:22:01 AM) thl: one last thing
(11:22:02 AM) c4chris: right
(11:22:07 AM) thl: meeting next week?
(11:22:10 AM) thl: who will be there?
(11:22:17 AM) ***thl probably will
(11:22:18 AM) ***bpepple will be here.
(11:22:19 AM) tibbs: I will be around.
(11:22:22 AM) ***c4chris probably won't be around
(11:22:31 AM) nirik: FYI, I see extras has 980 bugs open. Of those 611 are in the NEW state. Thats 62% where no one has stepped up and assigned the bug to themselves. Kinda sad.
(11:22:32 AM) blarney: nirik: what about going to the latest 0.99 in devel and then porting back to FC-6 if that's stable?
(11:22:57 AM) thl: so let's meet next week
(11:22:58 AM) nirik: blarney: that would be a job for the maintainer. I wouldn't push a new version to fix this when the old one will work.
(11:22:59 AM) tibbs: nirik: I guess that's one for the mythical QA team.
(11:23:11 AM) thl: and it there are lett then 5 FESCo members around we'll cancel it
(11:23:13 AM) thl: that okay?
(11:23:19 AM) ***thl will end the meeting in 30
(11:23:20 AM) tibbs: Sure.
(11:23:24 AM) bpepple: thl: sounds fine.
(11:23:28 AM) spot: next week? maybe.
(11:23:32 AM) ***thl will end the meeting in 15
(11:23:39 AM) blarney: nirik: ok, unless it is orphaned, I guess we wait to see if jmatos is on vacation or wants to give it up
(11:23:51 AM) thl: -- MARK -- Meeting End