Extras/SteeringCommittee/Meeting-20060518

(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