Extras/SteeringCommittee/Meeting-20060518

From FedoraProject

< Extras | SteeringCommittee
Revision as of 16:32, 24 May 2008 by Admin (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

(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