From Fedora Project Wiki
< Extras | SteeringCommittee
(also in the wiki at
Summary
Present from FESCo: thl, skvidal, jeremy, mschwendt, warren, spot, thomasvs, ensc, jpo
- 19:02 {x,}emacs-muse, emacs-comon-muse or emacsen-muse ?
- emacs-common-muse !
- 19:05 buildsys-build -- What packages shall be in the default buildroot?
- spot> | we should keep this to the smallest possible set of packages
- skvidal> | so whenever someone decides on what these things are, let me know of the list so I can edit the right files
- spot > | ok, i just sent an email to fesco with the packages used by mock that are above/beyond the exceptions; i'm not against adding some of these to the Exceptions list with rationalizations
- spot> | i'll work on the "new Exceptions"
- 19:14 Deduping of needsign packages
- mschwendt will lokk after this (it's on the schedule for a long time already)
- 19:19 How to solve legal issues
- thl put that on the schedule -- seems the communication between Extras and Legal isn't perfect and some things got stuck due to that
- warren> | thl, generally legal tells me, "If in doubt, the answer is no."
- spot> | legal issues wrt packaging should be decided by the packaging committee
- 19:20 packaging committee
- spot has a mandate for such a committee to exist and he has been appointed [by FAB] to make it go. :)
- some discussion if FESCo or another Committee should handle that; the idea was to have a committee that spanned both core and extras defining packaging standards for both; we need something today, and the current plan seems to be to create a packaging committee (lead by spot); we'll probably revisit this issue after fc6; if at any point, it becomes irrelevant, we'll absorb it back in
- Weekly sponsorship nomination
- _wart_ (Michael Thomas) nominates himself; FESCo will get back to him you next week
- 19:38 what do we do with MIA/AWOL maintainers?
- See also https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00319.html
- Just to make sure we all know what's meant:
- AWOL=absent without leave
- MIA=missing in action
- some discussions; jwb, mschwendt and Michael J Knox seem to be interested in it. See full log for details
- 19:48 co-maintainership is brought into the MIA/AWOL discussion
- warren> | Yeah, co-maintainership is something we need too... (thl puts it on the schedule)
- warren> | I suppose fedora account system is the proper place to track this in a database, and it can be
- mschwendt> | warren: plus a tracker for contributors who are believed to be MIA/AWOL
- warren> | Let's put together a design proposal for this packages database
- warren> | I'll write something up initially for fedora-extras-list
- 19:58 Incompatible package upgrade policy (directfb for example)
- some discussion around https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00433.html
- maybe there should be at most one compat-*package per case ?
- spot> | thl: let me write something up and we'll hash it out later; i think i know what i want here
- 20:07 Free discussion
- 20:07 spot> | ruby guidelines; http://www.fedoraproject.org/wiki/Packaging/Ruby
- some discussions if a "Ruby (abi) = foo" would make sense; rawhide might have something like that now. Spot will take a closer look if we can have something compatible for older distros
- 20:11 php: /var/www/ vs. /usr/share
- spot> | someone might just have to put their foot down and choose a side.
- spot> | i think i vote for php code to go into /usr/share i dont want to step on userdata living in /var/www
- ixs> | fine. I'll consider that settled then.
- spot> | ixs: can you write up a little policy blurb for me to add to the guidelines
Full Log
19:00 --- | thl has changed the topic to: FESCo Meeting in progess
19:00 < thl> | that's better :)
19:00 * | f13 goes away, sorry I have to drive ome
19:00 < thl> | k, who's around
19:00 < thl> | f13, have fun
19:00 --- | Users 68 nicks
19:00 * | skvidal is around
19:00 < jeremy> | I'm around, but need to brb
19:01 < thl> | is that all?
19:01 * | cweyl is around, but is part of the rabble anyways :)
19:01 < thl> | hmmm
19:01 * | Eitch is around but doesn't belong to FESCo :P
19:01 < tibbs> | rabble rabble
19:02 * | mschwendt is here, too
19:02 < thl> | well, let's start with a mini-meeting
19:02 * | nirik is also around, as is also rabble. ;)
19:02 * | jwb is semi-present
19:02 --> | xover (Terje Bless) has joined #fedora-extras
19:02 --- | thl has changed the topic to: FESCo Meeting in progess -- emacs-muse
19:02 * | bpepple lurking about.
19:02 < thl> | {x,}emacs-muse, emacs-comon-muse or emacsen-muse ?
19:02 < thl> | do we want to discuss this without spot?
19:02 * | spot is here
19:02 < XulChris> | +1 emacs-common-muse
19:02 * | nirik likes 'emacsen-muse', but it doesn't really matter that much I guess.
19:03 < thl> | +1 emacs-common-muse
19:03 < spot> | there is no precent for making up words like emacsen in the guidelines to date
19:03 < thl> | spot, what's you current solution?
19:03 < spot> | and i would prefer not to start anything. :)
19:03 < mschwendt> | +1 emacs-common-muse
19:03 < nirik> | spot: fair enough.
19:03 < spot> | emacs-common-foo is my vote
19:03 < XulChris> | +â emacs-common-muse
19:03 < bpepple> | +1 emacs-common-muse
19:03 < spot> | precedent
19:04 < thl> | k, seems this one one easy
19:04 < nirik> | ok, so muse, mew, and emacs-autex have to change...
19:04 < thl> | spot, can you mail that to the list and put it in the packaging guidelines please?
19:04 < spot> | gladly.
19:04 --> | thomasvs (Thomas Vander Stichele) has joined #fedora-extras
19:04 * | nirik can go review vm now too. ;)
19:04 < thl> | spot, thx
19:05 --- | thl has changed the topic to: FESCo Meeting in progess -- buildsys-build What packages shall be in the default buildroot?
19:05 < thl> | spot, I'd like to hear you opinion here, too
19:05 < spot> | ok, so my opinion on this is that we should keep this to the smallest possible set of packages
19:05 < thl> | agreed
19:06 < mschwendt> | this is not so easy, since rpm-build pulls in some big packages already
19:06 < mschwendt> | Perl vs. Python, C vs. C++
19:06 < warren> | rpm-build pulls in many of the things people are crying about
19:06 < skvidal> | so whenever someone decides on what these things are, let me know of the list so I can edit the right files
19:06 < spot> | mschwendt: understood, but lets determine what the smallest buildroot we can generate is.
19:06 < warren> | including python and perl
19:06 < spot> | i say we start with the list already in Exceptions
19:06 < warren> | The exclusion list on the Wiki is almost it, except I think we should add a few things there.
19:06 < thl> | just fyi, the current list is here: http://cvs.fedora.redhat.com/viewcvs/mock/buildsys-build.spec?root=fedora&view=markup
19:07 < spot> | and add as necessary
19:07 < warren> | er.. Exception list
19:07 < thomasvs> | spot: so would yours include any languages beyond bash ?
19:07 < mschwendt> | I really don't like all the automake* in there
19:07 < warren> | Yes, please remove all auto*
19:07 < thl> | mschwendt, +1
19:07 < skvidal> | each of you who have an opinion on this
19:08 < tibbs> | Why is openssh-server in there?
19:08 < skvidal> | edit the buildgroups.xml file on your own systems and email what you think is correct to the fesco list
19:08 < thomasvs> | doxygen and gdb. hm.
19:08 < thomasvs> | tibbs: because the post scripts kill any running ssh server when it gets removed
19:08 < thomasvs> | (tibbs: so it may be a hack that survived for the same reason that mach added it originally)
19:09 < warren> | thomasvs, scriptlets should rely on pid, not name...
19:09 < thomasvs> | warren: I don't disagree, just giving the history why it was put in mach originally
19:09 < thomasvs> | warren: it wasn't fun when it happened :)
19:09 < ensc> | afaik; mock does not *remove* packages
19:09 < mschwendt> | Would it be possible for somebody in the know to add comments to this list, which explain why all these packages are in the default build environment?
19:09 < ensc> | so this should not be a problem
19:09 < warren> | Yeah, comments in that file would be useful.
19:10 < thomasvs> | ensc: so it just keeps all previously used deps around for all future builds ?
19:10 < warren> | thomasvs, no, we want a new buildroot for each build.
19:10 < tibbs> | Current FC5 openssh-server doesn't have anything than service stop and chkconfig- -del
19:10 < thl> | I#d like to trim down the list as far as possible
19:10 < warren> | it doesn't uninstall, it should just blow it away.
19:10 < skvidal> | thomasvs: no, it doesn't
19:10 < thl> | and re-add things if it becomes necessary
19:10 < thomasvs> | tibbs: read service stop
19:10 < thomasvs> | but it sounds like openssh-server can go for mock
19:10 < skvidal> | and the new caching patches should zip things along
19:11 < spot> | ok, i just sent an email to fesco with the packages used by mock that are above/beyond the exceptions
19:11 < thl> | spot, k, thx
19:11 < spot> | i'm not against adding some of these to the Exceptions list with rationalizations
19:11 < warren> | I've been meaning to add pkgconfig to Exceptions for a while.
19:11 < thl> | spot, what about python?
19:11 < warren> | where should we discuss additions?
19:11 < warren> | thl, python is already pulled in by rpm-build
19:12 < spot> | thl: s/python/ruby/etc
19:12 < warren> | we could list it explicitly
19:12 < skvidal> | spot: pretty sure chkconfig will get auto-dep'd in
19:12 < thl> | warren, spot, should we put them in http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions in that case, too?
19:12 < tibbs> | thomasvs: sure looks like it kills what it finds in the pidfile.
19:12 < warren> | thl, yes
19:12 < spot> | it might not be a bad idea to generate a list of all the things in Exceptions today and what they're automatically depping in
19:12 < skvidal> | and initscripts
19:12 < warren> | spot, ++
19:12 < thl> | spot +1
19:12 < thomasvs> | tibbs: could very well be these days - it was probably added around rh8 or rh9
19:12 < skvidal> | and glibc
19:12 < spot> | then work from there
19:13 < thl> | k, do we want to discuss this further on the lists?
19:13 < thl> | or is there anything remaining that needs to be discussed now?
19:13 * | thl will move on soon
19:14 --- | thl has changed the topic to: FESCo Meeting in progess -- Deduping of needsign packages
19:14 < spot> | i'll work on the "new Exceptions"
19:14 < thl> | skvidal, that's still on the schedule
19:14 < thl> | skvidal, thx
19:14 < thl> | skvidal, I'd like to get this done
19:14 <-- | giallu has quit (Read error: 110 (Connection timed out))
19:14 < thl> | skvidal, or can somebody else look after that?
19:14 < skvidal> | ok, then feel free to work on it. :)
19:14 < thl> | (in case you don't find time for it)
19:15 * | thl still has no access to build64 afaik
19:15 * | thl is not sure that he want's to have access
19:15 < skvidal> | heh
19:15 < thl> | skvidal, can we set a date?
19:15 < thl> | get it done in the next four weeks?
19:15 < skvidal> | I can't, no.
19:15 < skvidal> | mschwendt: you've been working on the push scripts
19:15 < skvidal> | do you want it?
19:16 < skvidal> | ::crickets::
19:16 < mschwendt> | should be doable, I think
19:16 < skvidal> | mschwendt: okie doke - then it's all yours
19:16 < thl> | mschwendt, there is no need to hurry
19:16 < thl> | mschwendt, but I'd like to get it done sooner or later
19:16 < thl> | and it is on the schedule for a long time already ;-)
19:16 < thl> | k, moving on
19:17 < skvidal> | b/c it is utterly unimportant :)
19:17 * | warren signs & pushes
19:17 < mschwendt> | warren: don't!
19:17 < mschwendt> | push is in progress
19:17 < warren> | oh
19:17 < warren> | ok
19:17 --- | thl has changed the topic to: FESCo Meeting in progess -- Fedora Extras metrics
19:17 < cweyl> | maybe a lockfile in there too :)
19:17 < skvidal> | cweyl: already been worked on
19:17 < thl> | does anyone know if Sopwith still is working on it?
19:17 < cweyl> | skvidal: excellent
19:17 < warren> | Sopwith has been on vacataion for the past 2 weeks
19:17 < warren> | he should be back soo
19:17 < warren> | soon
19:17 < thl> | warren, k
19:17 < jwb> | oh good. was worried he died
19:18 < jwb> | :)
19:18 < thl> | then let's skip this today
19:18 < mschwendt> | cweyl: in the push script? there is one in my push script, fwiw
19:18 < mschwendt> | cweyl: but the others don't use it yet ;)
19:18 < skvidal> | mschwendt: why don't you check yours in?
19:18 --- | thl has changed the topic to: FESCo Meeting in progess -- Encourage Extras reviews
19:18 < thl> | warren, tibbs, any news?
19:18 < thl> | or do we simply skip it today?
19:18 < skvidal> | mschwendt: and make yours the default one, if you're comfortable with it, I mean.
19:18 < warren> | sorry, I forgot to follow up after the last meeting
19:18 < mschwendt> | skvidal: it is in CVS and running on extras64, just not linked in the bin dir
19:18 < warren> | skip for this week
19:19 --- | thl has changed the topic to: FESCo Meeting in progess -- How to solve legal issues
19:19 < skvidal> | mschwendt: any reason not to?
19:19 < thl> | I put that onto the schedule
19:19 < jwb> | thl, have a (simple) example?
19:19 < mschwendt> | skvidal: this weekend
19:19 < warren> | thl, generally legal tells me, "If in doubt, the answer is no."
19:19 < skvidal> | mschwendt: cool, thanks.
19:19 < spot> | legal issues wrt packaging should be decided by the packaging committee
19:19 < thl> | warren, are you out official gateway to legal?
19:19 < warren> | In the case of the MP4 container thing, someone needs to look at the code itself
19:19 < thl> | warren, I got the impression we don't have a gateway
19:20 < warren> | spot, packaging commitee as in... us?
19:20 * | jwb thinks spot refers to f-a-b
19:20 < spot> | right now, all we have is a mandate for such a committee to exist
19:20 <-- | bress has quit (Read error: 110 (Connection timed out))
19:20 < spot> | and i've been appointed to make it go. :)
19:21 < warren> | spot, I'm confused, where did this come from?
19:21 < spot> | fab
19:21 * | jwb gets a cookie
19:21 < warren> | spot, this is different from my suggestion to FPB that seems to have support from FPB.
19:21 < thl> | I'd like to nominate mschwendt and scop for that committee
19:21 < jwb> | thl, as the FESCO reps?
19:21 < warren> | The "Technical Standards Committee" which is what FESCO would eventually become, when Core + Extras merges.
19:21 < warren> | Essentially doing the same job as today.
19:21 < warren> | big in Core too.
19:21 < warren> | but*
19:22 < spot> | warren: i'm not opposed to that being the end goal, and having this packaging standards/practices committee become that several miles down the road
19:22 < spot> | but we need something today
19:22 < warren> | For what?
19:22 < thl> | jwb, no, they seem to be the right persons for it in general
19:22 < warren> | We already have that in Extras, no?
19:22 < spot> | warren: if by that you mean "me"
19:22 < warren> | I mean, FESCO already sets packaging policy.
19:22 < jwb> | thl, i don't disagree. was just asking to clarify
19:23 < spot> | yes, but i would prefer a more formal team to handle and take in such issues
19:23 < thl> | jwb, I know ;-)
19:23 < warren> | spot, I'm just questioning the need for an interim team here, when the existing group already does it.
19:23 * | thl tends to agree with spot
19:23 < jwb> | warren, FESCO is "Extras centric"
19:23 < warren> | I'm saying that it shouldn't.
19:23 < spot> | the idea was to have a committee that spanned both core and extras
19:23 < spot> | defining packaging standards for both
19:23 < warren> | that's exactly what I'm saying
19:23 < spot> | max agreed, and told me to run it
19:24 < warren> | I suggested to FPB that FESCO should become that.
19:24 < jeremy> | warren: this actually lets fesco concentrate on things *other* than just packaging policy
19:24 < warren> | jeremy, like what?
19:24 < jwb> | any of the other items that sit on the schedule repeatedly?
19:24 < spot> | so far, the only issue that has been mentioned today that would be packaging policy would be emacs-common-*
19:24 < jeremy> | warren: how to encourage and improve contributions, etc
19:24 < spot> | exceptions is a tangential issue
19:25 < warren> | This seems like an overlapping role
19:25 < jwb> | but not orthogonal
19:25 < spot> | warren: yes, which is why it is a committee, not a separate responsibility.
19:25 < spot> | i plan to stay on FESCO (assuming my ninjas ensure continued membership)
19:25 < warren> | jeremy, "how to encourage and improve contributions, etc" will not continue to be an Extras-only thing.
19:26 < spot> | packaging isn't a FE only issue, thus the overlapping group
19:26 --> | dgregor (Unknown) has joined #fedora-extras
19:26 < spot> | the special forces of packaging. ;)
19:26 < warren> | I guess...
19:26 < jeremy> | warren: yes, but packaging isn't an extras only thing *NOW*
19:26 < warren> | I don't see much difference here, but I suppose it wouldn't hurt.
19:26 < thl> | spot, packaging also need's an in deep knowledge of packaging
19:27 < thl> | spot, and probably some people of the new FESCo don't have that deep knowledge in it
19:27 < spot> | thl: don't i know it. i'd love to have mschwendt and scop to help there.
19:27 < spot> | thl: agreed
19:27 < thl> | so having a comitte with the job that really know what they are doing is better then a elected group
19:27 * | cweyl resists saying anything about Congress
19:28 < warren> | cweyl, rhymes with Progress =)
19:28 < cweyl> | :)
19:28 < thl> | k, anything else regading this?
19:28 < thl> | otherwise I'll move on soon
19:28 < jwb> | also rhymes with digress
19:28 < spot> | i was going to say, rhymes with ducking vidiots.
19:28 < tibbs> | BTW, where was this new packaging committee anounced?
19:28 < spot> | tibbs: hasn't been created yet
19:29 < spot> | this is just the intent to form, right now, its a one man committee
19:29 < warren> | thl, just one more comment
19:29 < spot> | (this literally happened this morning)
19:29 < warren> | thl, if this happens, I'd like to see clearly stated and differing goals of both FESCO and this new committee.
19:29 < spot> | warren: i agree entirely.
19:30 < tibbs> | I worry about too many boards and committees. Especially if they all have the same people.
19:30 < thl> | warren: I agree, too
19:30 < mschwendt> | tibbs: yes
19:30 < thl> | k, let's move on
19:30 < warren> | tibbs, I agree with that. And given that this is really an overlapping role, I don't see the need to create yet another committee.
19:30 < warren> | I instead think FESCO could evolve into that.
19:31 < mschwendt> | we ought to use existing structures more efficiently
19:31 < tibbs> | We should has this out later, though.
19:31 * | thl will not move on
19:31 * | warren writes counter-proposal to fab
19:31 * | spot sees the role of FESCO to handle extras-specific issues
19:31 < spot> | i don't see that role going away until fe goes away
19:31 < warren> | spot, that will become obsolete when Core + Extras merges.
19:32 < spot> | and since i've YET to see a timetable for this mystical merger of packages
19:32 < warren> | spot, sometime after FC6
19:32 < spot> | jeremy: this is your cue to laugh wildly
19:32 < warren> | spot, we're very serious about this, and jeremy is well aware. He did much of the planning.
19:32 < warren> | well... theorizing.
19:32 < spot> | "sometime after fc6"
19:32 < jwb> | i want to know what is involved in this mystical merger of packages
19:32 < spot> | so lets revisit this issue after fc6
19:32 < skvidal> | jwb: so would everyone
19:33 < skvidal> | jwb: don't worry about it
19:33 < tibbs> | But until the merge, FC uses FE's packaging policy and so FESCO makes decisions for FC, which is odd.
19:33 < skvidal> | jwb: we'll cross that bridge IF we get to it
19:33 < spot> | right now, we're separate
19:33 < spot> | and i need a packaging committee to handle both core and extras
19:33 < jwb> | i agree with spot
19:33 < warren> | spot, jwb: Details aren't hashed out yet, but we have people researching this simultaneously as FC6 is being developed, so we'll have more of a concrete plan in the coming months.
19:33 < tibbs> | So I see the point behind a separate committee.
19:33 < spot> | after fc6, if its irrelevant, we'll suck it all back in
19:34 <-- | roozbeh has quit ("Leaving")
19:34 < thl> | spot, yeah, that might work
19:34 < spot> | or even, if at any point, it becomes irrelevant, we'll absorb it back in
19:34 < spot> | this is a corner case, not the norm
19:34 < spot> | believe me, i dont want 400 overlapping groups fighting on who gets to say what
19:35 < spot> | but i'd rather not make decisions on the issues facing us today based on what "might happen" in the somewhat distant future. ;)
19:35 * | spot gets off his soapbox
19:35 < thl> | k, I think we all made our standpoints clear for today
19:35 < thl> | let's move on
19:35 < warren> | Let's bring this discussion back to fab.
19:36 --- | thl has changed the topic to: FESCo Meeting in progess -- Weekly sponsorship nomination
19:36 < thl> | anyone any nominations?
19:36 * | _wart_ nominates himself
19:36 < tibbs> | I was thinking of nominating _wart_;
19:36 * | thl runs /wii _wart_ and gets no real name
19:37 < _wart_> | MichaelThomas
19:37 < thl> | k, I'll forward that to the list
19:37 < thl> | _wart_, we'll get back to you next week
19:37 < _wart_> | np.
19:37 < thl> | any other nominations?
19:38 < thl> | seems not
19:38 < mschwendt> | what do we do with MIA/AWOL maintainers?
19:38 < jwb> | yeah, i have that same question
19:38 * | thl did not follow that thread closely
19:38 < jwb> | in my specific case, i just plan on giving the maintainer 2 weeks to reply to the email i sent him. no reply, and i'll take the package myself (i was his sponsor)
19:38 < spot> | i say we try to communicate with them, give them 30 days to respond
19:39 < spot> | at least two emails sent
19:39 < spot> | and if no response, package is orphaned
19:39 < jwb> | i can do that
19:39 < mschwendt> | and what about the sponsorship? unsponsor them?
19:39 < nirik> | should be a bug filed at the beginning... would be good for tracking times/
19:39 < spot> | nirik: thats a good idea
19:39 < jwb> | nirik, yes. and a bug has been filed (in my case)
19:39 < thl> | we should put interim guidelines somewhere, discuss them and make them official soon
19:39 < thl> | anyone interested in working that out?
19:39 < jwb> | mschwendt, i vote for unsponsoring, yes
19:40 < spot> | mschwendt: yeah, i think so
19:40 < mschwendt> | should we create a tracking-list in CVS, e.g. "owners/mia.list"? A free-form text file for now?
19:40 --> | Foolish (Sindre Pedersen Bjordal) has joined #fedora-extras
19:40 < tibbs> | Note that the security folks won't wait 30 days to hear back before pushing patches.
19:40 < ixs> | nevening
19:40 < nirik> | mschwendt: or how about a FE_MIA blocker bug?
19:41 < mschwendt> | would work, too
19:41 --> | RTLM (RTLM) has joined #fedora-extras
19:41 --> | jpo (Jose Pedro Oliveira) has joined #fedora-extras
19:41 < ixs> | tibbs: there's a difference between waiting 30days for a secfix or between waiting 30 days to revoke a developers priviliges.
19:41 < ixs> | I'd even suggest, to give the packager more time until the unsponsoring.
19:42 < jwb> | tibbs, what ixs said :)
19:42 < jwb> | except the more time part
19:42 < tibbs> | I understand completely.
19:42 < warren> | IMHO, we shouldn't be waiting 30 days before stepping in with a security fix.
19:42 < spot> | yeah
19:42 < thl> | warren, agreed
19:42 < ixs> | something like x days for secfix, 1month for orphan in case it's important und 2month till being dropped.
19:42 < spot> | i was excluding the security fix case from that
19:42 < warren> | If somebody wont even answer mail in a week or two, somebody else should just do it that one time. Revoking privs should be another step beyond that.
19:42 < thl> | the old Security SIG proposal had other deadlines
19:43 < ixs> | warren: think about it, 2 weeks vacation without email are sometimes the norm.
19:43 < warren> | Somebody should step in to do the job.
19:43 < mschwendt> | I was more interested in the general procedure with regard to withdrawing the sponsorship
19:43 < tibbs> | Back to co-maintainers?
19:43 < warren> | In most cases the "right" thing to do is obvious.
19:43 < ixs> | warren: as long as it's temporal and the package isn't being reassigned, +1
19:43 < warren> | ixs, yes
19:44 < jwb> | tibbs, that's an option. _if_ you can even get the current maintainer to respond
19:44 < warren> | mschwendt, that is a separate issue from stepping in to do the job.
19:44 < thl> | guys, we can discuss this endlessly this way
19:44 < thl> | we need someone to work out a proposal how to do it
19:44 < ixs> | warren: but that stepping in would be a good job for the "roving maintainer hordes" which were mentioned last week, even though the name was different.
19:44 < thl> | IMHO
19:45 < thl> | jwb, mschwendt can you work out something
19:45 < thl> | we can look at it in a later meeting
19:45 < warren> | ixs, we've been doing this for years inside of Red Hat, in practice people do the right thing.
19:45 < jwb> | thl, i can give it a shot
19:45 < mschwendt> | thl: on extras-list somebody else was working on a proposal
19:46 < thl> | ohh
19:46 < nirik> | jwb: Michael J Knox was proposing some things with the debian guidelines...
19:46 < ixs> | warren: fine, but not to step on anyones toes, we should put that down somewhere.
19:46 < thl> | taking some hints and ideas from debian seems to be a good idea
19:46 < jwb> | nirik, i vaguely remember seeing that. i'll read the thread more closely and go from tehre
19:46 < ixs> | nirik: please leave debian out with regard to this. The debian way takes _ages_ and is a major hassle to jsut do a bit of work on a programm where the maintainer is MIA.
19:46 < ixs> | nirik: or unresponsive.
19:46 < nirik> | http://www.redhat.com/archives/fedora-extras-list/2006-May/msg00319.html
19:47 < warren> | another thing we do inside of Red Hat is agreements made between developers to fix things with implicit permission.
19:47 < jwb> | warren, hm?
19:47 < nirik> | ixs: I didn't bring it up. :) Just pointing out someone else did. ;)
19:47 < mschwendt> | co-maintainership is a good thing, but doesn't answer my initial question ;)
19:47 < nirik> | I think just a outline with 'X days of no response you can do this' would be helpfull...
19:48 < warren> | jwb, example... I trust the judgement of a dozen other maintainers, so I give them permission to make changes on my packages whenever they wish.
19:48 < jwb> | oh sure
19:48 < tibbs> | Sounds like co-maintainership.
19:48 < ixs> | nirik: well. I'll have to point ot to MJK then, that the debian way is not the way to go. They do have a lot of packages with unresponsive maintainers and as a new maintainer upload is generally frowned upon, nothing get's done.
19:48 < warren> | Yeah, co-maintainership is something we need too...
19:48 < thl> | we really need a proper scheme for co-maintainership, too
19:48 < jwb> | warren, but Extras is a bit different. how do i know you gave developer J.Bob implicit permission?
19:49 < nirik> | ixs: yeah, agreed.
19:49 < warren> | jwb, if they fix it and I don't complain, currently. If we want to do this explicitly, then we need some kind of tracking system.
19:49 < cweyl> | implicitly, you can't. it'd probably have to be something explicit -- or at least something explicit in the guidelines
19:49 < jwb> | i dunno... i kinda like the "if i don't complain" approach
19:49 < jwb> | but i see value both ways
19:50 < ixs> | warren: could we abuse the accoutns system? create a group like "barcode-maintainers", add people and they all are considered co-maintainers?
19:50 < nirik> | could cvs be setup so developers have only perms to their package, and have a module they can edit to add other people if they want?
19:50 < ixs> | warren: maybe even whip up automatic email alias creation et al?
19:50 < thl> | nirik, " cvs be setup so developers have only perms to their package" seems like a good idea to me
19:50 < tibbs> | Probably over-engineered for the majority of packages.
19:50 < warren> | nirik, significantly raises bar and hassle, while it would only stop 0.01% of bad changes.
19:50 < thl> | only some important people should have access everywhere
19:51 < tibbs> | I've pushed packages for someone because they had no CVS access and asked me to.
19:51 < jwb> | that requires 1) acl groups for each package, 2) automatic creation of said acls, 3) an accounts system that supports adding people to said acls
19:51 < thl> | there is still the idea "give co-maintainers access to cvs, but let only the maintainer request the build"
19:51 < warren> | We need a database to track this
19:51 < ixs> | thl: in general yes, that is a nice idea. However, there are cases where that would be a hassle. Few weeks ago, thomas was in brazil, and I needed one of his packages in rawhide (libshout 2 was in fc5, but rawhide still had libshout 1.x), which was checked in, but not tagged an not built. That would be a bit difficult with enforced ACLs.
19:52 < warren> | I suppose fedora account system is the proper place to track this in a database, and it can be exported to Bugzilla.
19:52 < jwb> | yes
19:52 < jwb> | which falls back to those with accounts access
19:52 < warren> | I don't support the idea of only owner can checkin.
19:52 < tibbs> | The security team needs lots of access.
19:53 < ixs> | warren: where is the problem of just requiring co-maintainers to become fedora contributers? everything solved.
19:53 < nirik> | sponsors should have access to their sponsorees packages too... so it gets complicated fast.
19:53 < warren> | In practice we have very few problems with people doing things they shouldn't. And when it does happen we educate.
19:53 < jwb> | and when education doesn't work, we revoke
19:53 < warren> | jwb, exactly
19:53 < thl> | warren, but there is still the case hans described
19:53 < ixs> | I think until now, just tracking commits worked great.
19:53 < warren> | which?
19:53 < ixs> | so why change it without a real need.
19:54 < warren> | I think a database of packages and multiple owners would be a good first step here.
19:54 < nirik> | yeah, tracking commits is fine, as long as you can't bypass that... which you can if you can hit control-c fast enough. ;(
19:54 < ixs> | nirik: yeah. I followed that.
19:54 < thl> | warren, https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00510.html
19:54 < mschwendt> | warren: plus a tracker for contributors who are believed to be MIA/AWOL
19:54 < ixs> | nirik: but face it: it's way easier just uploading a modified souce package. less the hassle.
19:55 < thl> | nirik, but who really tracks commits?
19:55 < ixs> | thl: ville does.
19:55 < warren> | A database of packages and multiple owners could allow you to auto-CC multiple owners, add other people to explicit permission to modify your packages, track MIA durations for possible priv revocation.
19:55 < thl> | nirik, nobody checks md5sums
19:55 < warren> | many things we can do with it.
19:55 < ixs> | thl: he reminded me of one or two lapses. ;)
19:55 < jwb> | thl, i do for every package i maintain
19:55 < thl> | ixs, ralf probably looks closely, too ;-)
19:55 < nirik> | I try to track anything I approved/interests me, I skim the rest. ;)
19:55 * | jwb has an obsessive-compulsive need to cvs up -dPA every day
19:55 < ixs> | thl: corsepius? he probably looks way too close. :D
19:56 < warren> | another thing the database could do is enable owners to receive ONLY commits that they own
19:56 < warren> | optionally
19:56 < thl> | warren, that would be a good idea
19:56 < thl> | warren, I'd like that
19:56 < jwb> | s/own/are interested in
19:56 < warren> | Sponsors could receive commits of packages owned by sponsorees
19:56 < warren> | jwb, that too, subscribe to whatever you want
19:56 < ixs> | thl: isn't taht a bit overengineered? .procmail on the client should do a fine job.
19:56 * | nirik likes getting the full feed... can see things like the qt4 import today. ;)
19:56 < warren> | packages could be grouped in say "Games" and people can subscribe to the Games group.
19:57 < warren> | nirik, full feed will always remain an option.
19:57 < thl> | ixs, if you have more then 10 packages you for sure will miss one of yours sooner or later
19:57 --- | jwb has changed the topic to: FESCo Meeting in progress -- Maintainership issues
19:57 < warren> | Let's put together a design proposal for this packages database
19:57 < ixs> | thl: yeah, but I'm always thinking about the fact that someone will need to code all this.
19:57 < warren> | I'll write something up initially for fedora-extras-list
19:57 < thl> | warren, thx
19:58 < thl> | k, so let's move on
19:58 --- | thl has changed the topic to: FESCo Meeting in progess -- Incompatible package upgrade policy
19:58 --- | mspevack is now known as mspevack_mtg
19:58 < ixs> | --verbose please
19:59 < tibbs> | "Just don't do it"?
19:59 * | thl is searching
19:59 < ixs> | ahh? the release issue of having .3 in FC5 and .5 in FC4?
19:59 < thl> | https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00433.html
19:59 < ixs> | yeah, that's a "don't do that issue."
19:59 < thl> | do we want to make this mail official?
19:59 < jwb> | yes
20:00 < spot> | i obviously support this. ;)
20:00 < thl> | there was one add-on scop mailed me:
20:00 < thl> | I would also like to add that maybe there should be at most one compat-*
20:00 < thl> | package per case: foo + compat-foo, NOT foo + compat-foo1 + compat-foo2
20:00 < thl> | + compat-fooN. IMO this would be understandable, easy to document,
20:00 < thl> | control, and clean up when needed.
20:00 < thl> | sound like a good idea to me
20:00 < spot> | compat-foo can have multiple revs of old libs in them if needed
20:00 < warren> | compat-openssl with all 12 versions? =)
20:00 < spot> | warren: yeah.
20:00 < tibbs> | Maintainers would need to know that they're requiring a compat package.
20:01 < spot> | we're trying to discourage this. :)
20:01 * | nirik sees that this would make getting the Xfce4.4 into fc5 hard, but it all makes sense.
20:01 < mschwendt> | tibbs: ?
20:01 < ixs> | warren: compat openssl with 12 versions? #debian is over ---> there.
20:01 < mschwendt> | compat-foo packages are without compat-foo-devel
20:01 < tibbs> | If someone revs something I depend on and I'm now requiring a -compat package, I want to know about it.
20:01 < spot> | mschwendt: ehh, why?
20:01 < warren> | tibbs, not necessarily. auto-deps would just pull in the so-name
20:02 < spot> | assuming they can live in the same space?
20:02 < tibbs> | warren: precisely.
20:02 < mschwendt> | spot: that is the tricky part
20:02 < ixs> | tibbs: hmmm. that should be figured out by the daily broken deps mail.
20:02 < tibbs> | The dep wouldn't be broken if it's satisfied by a -compat package.
20:02 < spot> | mschwendt: yeah, if they can be kept apart, then i don't see any problem with a compat-foo-devel
20:02 < thl> | spot, we should make sure that we don#t get to much compat packages
20:02 < thl> | spot, how about this
20:02 < thl> | spot, normaly only one compat package for a software
20:03 < thl> | more then one only if FESCo agress with it
20:03 < spot> | i dont really ever see the case for more than one
20:03 < thl> | e.g. in case we need two or three openssl
20:03 < thl> | spot, that's also okay for me
20:03 < spot> | thl: why not just have multiple subpackages inside one compat-foo ?
20:03 < spot> | if we really needed two or three openssl
20:04 < thl> | yeah, that could work, too
20:04 * | spot doesn't really care either way. i'm not trying to go out of my way to make this easy
20:04 < thl> | but I still fear that some people will make a lot of compat packages
20:04 < nirik> | the pathalogical case here is directfb... new so every release. ;)
20:04 < thomasvs> | spot: it could be important for people that run binary only stuff from ISV's
20:04 < spot> | thomasvs: ok, i see that
20:04 < thomasvs> | I think I saw one of the dell packages require a specific openssl version
20:04 < spot> | how about not in subpackages
20:05 < thl> | spot, that area normally is handled by core these days
20:05 < spot> | compat-foo can provide old libs for as many old revs as you'd like
20:05 < thl> | s/spot/thomasvs/
20:05 < warren> | nirik, let's limit it to 99 sonames within the directfb package =)
20:05 < spot> | assuming they are numbered
20:05 < ixs> | hmmm. what about tracking deps and informing maintainers of tools whenever their BuildReqd libs do a major version jump?
20:05 < thomasvs> | yeah, I'd like to have some policy about the case like directfb
20:05 < thomasvs> | I just replied to scop's mail about it
20:05 < ixs> | that should automagically cut down on the number of compat-packages.
20:05 < jwb> | time is running long
20:05 < thl> | jwb, agreed
20:05 < nirik> | "99 .so's of directfb on the wall, 99 so names of directfb..."
20:05 < spot> | that way, we have BuildRequires: compat-foo or BuildRequires:libfoo.so.5
20:05 * | warren writes package database strawman...
20:06 < thomasvs> | I'm fine either way, but if we do not want to allow for what directfb, I'd like to know so I can drop the package
20:06 < thomasvs> | I have no interest in maintaining it if it's not allowed to be upgraded :)
20:06 < thomasvs> | and I can't clue the dfb people in either, so ...
20:06 < thl> | spot, so what to you suggest as solution?
20:06 < spot> | thl: let me write something up and we'll hash it out later
20:06 < spot> | i think i know what i want here
20:06 < thl> | spot, can you write a updated proposal and we agree on it inthe next meeting?
20:06 < thl> | spot, k, thx
20:07 --- | thl has changed the topic to: FESCo Meeting in progess -- Free discussion
20:07 < spot> | i've got one item
20:07 < thl> | anything else we need to discuss?
20:07 < spot> | ruby guidelines
20:07 < tibbs> | Yes, please.
20:07 < spot> | http://www.fedoraproject.org/wiki/Packaging/Ruby
20:07 < tibbs> | We had one submission die due to lack of guidelines.
20:07 < spot> | these guidelines seem sane to me, + a ruby namespace ruby-gemname
20:08 < spot> | i propose to add them to the packagingGuidelines
20:08 < spot> | and lift the hold on ruby packaging
20:08 < ixs> | I could need a bit of help about the php guidelines. I put down some initial thoughts and discussed them on irc a bit, but I could need some thoughts about where to suggest putting apps. right now I'm going with /usr/share/appname and then aliasing it into the webroot, but other people suggest /var/www as it would be easier on selinux.
20:08 < thl> | spot, wouldn't a package that provides "Ruby (abi) = foo" make sense?
20:08 < ixs> | url is http://www.fedoraproject.org/wiki/Packaging/PHP
20:09 < thl> | spot, we had such a one in fedora.us for python
20:09 < thl> | before python(abi) became part of core
20:09 < tibbs> | I have a bunch of private mail on the Ruby issue. I'll try to find it.
20:09 < spot> | thl: wouldn't ruby be the place to do that?
20:09 < thl> | spot, don#t know
20:09 < thl> | spot, was just a idea
20:09 < tibbs> | I think Akira agreed to provide Ruby(api) or something like Perl(MODULE_COMPAT).
20:10 < spot> | tibbs: ok, that sounds optimal, but until it hits as an update for FC4+, we'll need to Requires on the version
20:10 < tibbs> | I think it hit FC5 yesterday, but I'll have to check what actually gets provided.
20:11 < thl> | tibbs, spot can you look at it closer?
20:11 < tibbs> | Or maybe that was just rawhide.
20:11 < dgilmore> | ixs: /var/www/ may be easier on selinux but i think /usr/share is where it should go squirellmaill has been that way forever
20:11 < thl> | and we discuss this in the next meeting?
20:11 < spot> | thl: ok
20:11 < tibbs> | thl: ok
20:11 < thl> | we might want to make something that is compatible with rawhide
20:11 < ixs> | dgilmore: my point. exactly.
20:11 < thl> | (if possible)
20:11 --> | fedorared (John Mahowald) has joined #fedora-extras
20:11 < thl> | that would probably the best
20:11 < spot> | thl: yeah, agreed
20:11 < ixs> | dgilmore: however, there was abit of ruckus raised during some reviews about that.
20:11 < thl> | k, anything else?
20:11 < spot> | ixs: someone might just have to put their foot down and choose a side.
20:11 < thl> | we're quite late
20:12 < dgilmore> | ixs: i remeber but it shouldnt be to hard to put in a %post script that make sure the selinux context is ok
20:12 < f13> | I'm back.
20:12 < f13> | is meeting still going?
20:12 < jwb> | trying to clsoe
20:12 < ixs> | spot: well, I'm all for /usr/share/ and as nobody is there to say anyth9ing different, /usr/share it is. *g*
20:12 < dgilmore> | f13: ruby and php packaging
20:13 < dgilmore> | ixs: ill say /usr/share
20:13 < ixs> | dgilmore: yeah. there's a bit of content about selinux for packagers on the wiki, however, there could be more.
20:13 < f13> | was there any need for me during the meeting?
20:13 < thl> | f13, nope
20:13 < tibbs> | Some of the selinux stuff is still buggy and being worked out.
20:13 < spot> | i think i vote for php code to go into /usr/share
20:13 < spot> | i dont want to step on userdata living in /var/www
20:14 < ixs> | fine. I'll consider that settled then.
20:14 < jwb> | f13, unless you have access to the accounts system...
20:14 < spot> | ixs: can you write up a little policy blurb for me to add to the guidelines
20:14 < dgilmore> | ixs: i guess what would be best is if there we some way to mark a package / dir as web app and make selinux policy aware so that context is maintained during selinux-policy updates
20:14 < ixs> | I'll try to finish the php guidelines tonight. where to best announce it?
20:14 * | thl will close the meeting in 60 if nothing new shows up
20:14 < spot> | ixs: email it to me first, i want to eyeball it
20:14 < ixs> | spot: fine with me.
20:15 * | thl will close the meeting in 30 if nothing new shows up
20:15 < f13> | jwb: thats needed w/ the account system?
20:15 * | thl will close the meeting in 15 if nothing new shows up
20:15 < thl> | MARK Meeting end
20:15 < jwb> | f13, at some point we'd like to actually hold this election. would be nice to use the accounts system. requires access for interested parties (me and spot)
20:16 < f13> | ah
20:16 < ixs> | .oO( wouldn't that be -- MARK -- ? )
20:16 < Seg> | ...
20:16 < thl> | ixs, do you want to holf the next meeting?
20:16 * | spot points out that he has some of the voting code done...
20:16 < ixs> | thl: no way. you'Re doing a damn good job with it. ;)
20:17 < spot> | but havent had ANY time to do more
20:17 < jima> | thl: great, you made yourself irreplaceable. now you're screwed.
20:17 < jwb> | spot, oh, didn't know
20:17 < ixs> | jima: time to lifetime-nominate thl for fesco?
20:17 < Seg> | Heh I just woke up. There's a point I'd like clarified in the packaging guidelines.
20:18 < jima> | ixs: :D
20:18 < thl> | ixs, no way
20:18 < spot> | jwb: sent it to fesco
20:18 < spot> | bout a week ago
20:18 < jwb> | spot, closed list
20:18 < spot> | hrm.
20:18 < spot> | jwb: i'll send you a copy
20:18 < jima> | thl = done for ;)
20:18 < jwb> | spot, ok
20:18 < tibbs> | warren: I recall sending you an email about redoing the docs for package reviews last Thursday. Am I hallucinating?
20:19 < warren> | tibbs, yes, sorry
20:19 < warren> | tibbs, our mail server melted after that.
20:19 < ixs> | thl: ohh btw, are there enough nominations for fesco?
20:19 < Seg> | Should we be using macros like %{__make} and %{__rm} ? Should we not? Should we just do whatever as long as we're consistent?
20:19 < tibbs> | No problem; I often forget to send messages I type.
20:19 < thl> | ixs, 17 people
20:19 < ixs> | Seg: good point. Some people like them in the .specs, some complain about em.
20:19 < tibbs> | If you need me to resend, I can dig it out. I wrote it during the meeting so it's probably incoherent anyway.
20:19 < thl> | ixs, sound okay to me
20:19 < thl> | anyway, I need to leave
20:20 < ixs> | cya
20:20 < tibbs> | Seg: I personally don't use them, but if you do, use them everywhere.
20:20 < thl> | have fun!
20:20 < warren> | tibbs, it is somewhere in my thousand messages of unsorted mail
20:20 * | thl afk
20:20 < tibbs> | warren: don't worry about it; I'll put more thought into it and send you a message later.
20:20 < warren> | tibbs, cool thanks
20:20 < Seg> | The spec templates don't use them, which is the only thing that implies anything either way.
20:20 < nirik> | oh, thats the other thing I was going to bring up... packages that change name upstream... re-review? or just import new name?
20:20 * | jima receives a dead 1.8" hard drive. whee.
20:20 --- | thl has changed the topic to: This is the Fedora Extras channel, home of the FESCo meetings and general Extras discussion. | http://fedoraproject.org/wiki/Extras | Next FESCo Meeting: 2006-05-25 1700 UTC
20:21 < spot> | Seg: as long as you're consistent, its ok
20:22 < tibbs> | nirik: it never hurts to do a re-review, but the committee should decide. I don't think any new modules should be created in CVS without a review.
20:22 < tibbs> | (personal opinion, of course).
20:22 < Seg> | So like the %{buildroot} vs $RPM_BUILD_ROOT policy?
20:23 < nirik> | yeah, I would tend to agree... we just don't have a known rule on it.
20:23 < tibbs> | Yes, consistency is key.
20:23 < Seg> | Might want to note this in the wiki in the macro section.
20:23 < ixs> | tibbs: bah. no review necessary for a simple namechange.
20:23 <-- | green_ has quit ("Ex-Chat")
20:23 < ixs> | tibbs: we shouldn't waste reviewers time.
20:23 * | jima vaguely wishes one were officially preferred.
20:24 < warren> | nirik, there is a rule for %{buildroot} and $RPM_BUILD_ROOT
20:24 < Seg> | Yeah, personally I like to see fewer macros in specs.
20:24 < tibbs> | I officially prefer %{buildroot} because my pinkies get tired otherwise.
20:24 < jima> | heh
20:24 < nirik> | http://www.redhat.com/archives/fedora-extras-list/2006-May/msg00469.html
20:24 < warren> | The rule is don't use them inconsistently.
20:24 < Seg> | But then some people are paranoid and like the fully specified paths.
20:24 < nirik> | warren: yes, I was talking about when upstream changes package names... should you just import the new name package or send it thru review again.
20:25 < warren> | hmm, I guess we don't have that in the guidelines
20:25 < warren> | a re-review never hurts
20:25 < nirik> | was answering tibbs, sorry. ;)
20:25 < nirik> | yeah...
20:25 < warren> | but then again just getting things done is important
20:25 < ixs> | warren: correct, a review never hurts. But what hurts is having to wait till a package gets reviewed just for a simple namechange.
20:26 * | nirik is going to run into that with xfcalendar->orage soon...
20:26 < ixs> | warren: and I do consider it rude, to waste reviewer's time.
20:26 --> | Sopwith (Elliot Lee) has joined #fedora-extras
20:26 < warren> | Sopwith, welcome back!
20:26 < Seg> | Near as I can tell, reviews of packages by people already sponsored go pretty quickly.
20:27 < Seg> | Its the needssponsor thats a bottleneck...
20:27 < warren> | ixs, I'd propose that we add that as an explicit guideline. "Just do it."
20:27 < Sopwith> | hi warren
20:27 < warren> | Seg, not exactly. Review of packages that have an interest of more than one person goes quickly.
20:27 < Seg> | Heh, that too.
20:27 < |Jef|> | Seg: do you have hard stats on that or is that based soley on feeling?
20:27 < fedorared> | And the simple packages go easy.
20:27 < warren> | Sopwith, someone mentioned you went to a wedding and vacation or something?
20:28 < tibbs> | Anyone know what's up with qt4?
20:28 < ixs> | warren: I'd agree on that. Maybe a appropriate comment in the import message, and that's it. If anyone want's to do a review, they are welcome to. But it shouldn#t IMHO be a necessity.
20:28 < Sopwith> | Some vacation, some wedding, some working remotely, little bit of everything.
20:28 < f13> | tibbs: than was supposed to email extras-list to find out how he should proceed, such as removing th emodule to make way for rex.
20:28 < ixs> | tibbs: misscomunication or misunderstanding of the guidelines. f13 is talking to than.
20:28 < Seg> | And if its a re-review its likely going to be mostly acceptable already. In theory. ;P
20:29 < ixs> | Seg: yeah, but the problem is, reviews take time. If the package is somewhat unknown or not deemed important or reviewers are busy, it will be stuck for some time. That's a unnecessary bottleneck.
20:29 < warren> | Seg, depends on how seriously people follow rules.
20:29 < warren> | Seg, some people don't.
20:29 < tibbs> | f13, ixs: Thanks. Rex and folks are working hard on that review.
20:30 < ixs> | especially, as the package hasn't changed basically.
20:30 < f13> | tibbs: indeed.
20:30 < warren> | removes qt4 from CVS....
20:30 < Seg> | Anyway I've been trying to get all the audio apps reviewed. Even though I'm not a sponsor.
20:30 < Seg> | No one else seems to want to. Heh.
20:31 < fedorared> | Seg: I notice most of them depend on jack-audio-connection-kit
20:31 < Seg> | Yeah, jack is key to the whole thing.
20:32 * | tibbs is happy he sponsored Laurent.
20:32 < Seg> | And we need to get Fernando sponsored.
20:32 < tibbs> | Fernando?
20:32 < warren> | Fernando is the audio rep guy?
20:32 < Seg> | CCRMA guy, yeah.
20:32 < Seg> | He submitted qjackctl.
20:32 < warren> | the audio stuff doesn't have patent problems?
20:33 < Seg> | Which stuff?
20:33 < Seg> | I don't see how.
20:33 < warren> | the stuff from CCRMA
20:33 < warren> | like MP3
20:33 < Seg> | The FM synth patent expired in 1995...
20:33 < ixs> | warren: by my reading, the jack stuff is just a framework...
20:33 < ixs> | something a bit like gstreamer, only lowlevel.
20:33 < Seg> | Jack is awesomely unix.
20:33 < tibbs> | Yes, Jack is pretty neat.
20:34 < Seg> | Its a framwork for plugging audio between apps.
20:34 < Seg> | Like piping text, only with audio.
20:34 < warren> | this is like MIDI stuff?
20:34 < nirik> | now that muse is going to be emacs-common-muse, the jack muse needs to fight it out with that other muse. ;)
20:34 < ixs> | nirik: jack-muse
20:34 < tibbs> | jack muse will slay all.
20:34 < warren> | We could just put all three into muse.src.rpm =)
20:35 < Seg> | Music production is pretty virtual these days. We have the CPU power.
20:35 < nirik> | "battle of the muses"!
20:35 <-- | JSchmitt has quit (Remote closed the connection)
20:35 < Seg> | Jack is a virtual audio patch bay, ALSA provides a virtual MIDI patch bay.
20:35 <-- | jpo has quit ("Leaving")
20:36 < tibbs> | Anyone notice the six people who have applied for sponsorship? I get the mail every morning, wondering if I'm supposed to do anything about it.
20:36 < jima> | crap, my degree in extreme audio/video patchery is becoming obsolete. :(
20:36 < warren> | tibbs, theoretically we're supposed to check if those people actually submitted anything
20:36 < mschwendt> | tibbs: the problems is I have no idea who they are
20:36 < fedorared> | tibbs: if you are satisfied their stuff is up to par sponsor them.
20:36 < warren> | if they didn't submit anything, then Decline them
20:36 < fedorared> | Politely.
20:37 < tibbs> | Precisely; there's no easy way to link back to package submissions or even bugzilla comments.
20:37 < warren> | I usually Decline, then follow up with a mail explaining the process.
20:37 < warren> | with links to the wiki
20:37 < warren> | tibbs, oh, that's a good idea.
20:37 * | warren adds to that to the package database
20:37 <-- | drpixel has quit (Read error: 104 (Connection reset by peer))
20:37 < warren> | Developer view must point at Bugzilla and CVS activity
20:37 < tibbs> | I know nbecker has submitted stuff. But aren't they supposed to find someone to sponsor them first, and then apply?
20:38 < mschwendt> | the user description in teh accounts system can be used for that
20:38 < warren> | yes they are supposed to
20:38 --> | MikeC (Mike Chambers) has joined #Fedora-Extras
20:39 < |Jef|> | Seg: FYI, out of the 20 oldest open bugs blocked by FE-NEW, only 3 are marked as needsponsor.. i dont think you can make any sort of claim that needsponsor is a bottleneck without doing some clever aggregate datamining
20:39 < Seg> | Fine, I'm full of shit as usual.
20:40 < skvidal> | someone add that to the quote file, please
20:40 < tibbs> | Well, the oldest bug is "Helixplayer should be removed". (??)
20:40 --> | mdomsch (Matt_Domsch) has joined #fedora-extras
20:40 * | Seg bows
20:40 < tibbs> | Some of us have been trying to ping on those old bugs.
20:40 < nirik> | yeah, and it should... but thats shouldn't be a review bug. ;)
20:40 < |Jef|> | tibbs: some how a doubt helixplayer removal is marked FE-NEW
20:42 < fedorared> | It is. 154392
20:42 < jima> | probably everyone was just ignoring it.
20:42 < |Jef|> | fedorared: oldest open bug i have in my query is 165666
20:43 < tibbs> | It shows up for me: https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=163776
20:43 < |Jef|> | fedorared: and initng is among the 20 oldest.. and will continue to be
20:44 < fedorared> | |Jef|: it's against fc4 package review.
20:44 < tibbs> | https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154392 clearly blocks FE-NEW and nothing else. What should it be blocking?
20:44 < |Jef|> | fedorared: im looking at just devel
20:44 < |Jef|> | fedorared: i think
20:44 < fedorared> | I figured
20:45 < |Jef|> | fedorared: which all seem to be valid review requests according to the summaries
20:45 --> | drpixel (Dr Pixel) has joined #fedora-extras
20:45 < tibbs> | Interesting. Warren set it to block FE-NEW on 2006-04-19.
20:45 < warren> | which?
20:46 < |Jef|> | fedorared: like i said... you have to make a stab at datamining to really know wtf is going on with timeoflife with review requests
20:46 < |Jef|> | tibbs: probably some automatic mass retagging booboo
20:47 < warren> | tibbs, oh that. We're working on removing it, but it is a bit of a mess
20:47 < warren> | tibbs, internal problem...
20:47 < fedorared> | "datamining". I just start at the older bugs, see if there's anything happening.
20:47 < |Jef|> | fedorared: my saved query does Product: FE Component: Package Review Status: New
20:58 < |Jef|> | okay so changing my pre-set query a little.. out of the oldest 100 bugs in Component Package Review just 30 are marked as need sponsor
20:59 < |Jef|> | err i should say the 100 oldest that are marked as blockedby FE-NEW still