Extras/SteeringCommittee/Meeting-20060223

Summary
Present from FESCo: thl, jpo, warren, jeremy, scop, Sopwith

Important topics:


 * Kernel module standardization


 * thl will try to convert GFS-packages from Core to the new kernel-module scheme
 * adding kmodtool to redhat-rpm-macros? scop: '...and I think it wouldn't hurt to actually ship some module packages and watch it a bit before including in something "official" like that'
 * status of yum wrt kmod-* packages? plugin in the works; no one knows the exact status


 * Mass rebuild of Extras for FC5


 * noarch packages don't need to be rebuild
 * jpo mentions that if would be good for perl packages as it reduces the module loading time; warren replied later "I personally don't consider that a reason for mandatory rebuild, but the owners have the option of doing anything they want."
 * there were also some other perl problems (maybe ABI related, maybe not); see https://www.redhat.com/archives/fedora-perl-devel-list/2006-February/msg00037.html for details


 * EOL Policy for FE


 * Some discussions; we probably soon have a security SIG and will try to get them involved. No details yet.


 * Weekly sponsorship nomination


 * John Mahowald / jpmahowald is a sponsor now


 * separate extras-ml-list for bugzilla spam


 * We'll probably open fedora-extras-bugzilla-list and fedora-extras-review-list. All contributors should subscribe to -reviews.


 * Free discussion; Topics: Review days, better education and documentation to increase reviews, close old reviews-bugs where nothing is happening, scratch builds. Highlights below:

19:03 <        thl> | nirik, any plans for another "review day" 19:04 <      nirik> | I could try another one... was out of town last weekend and have been trying to catch up since then... ;) 19:04 <      nirik> | perhaps not this coming weekend, but the one after, and I could start advertising soon. --- 19:51 <      warren> | Regarding the review problem, I don't see any viable options here other than what I suggested last week.  Focus on education and documentation, because nothing else is effective in the long term. --- 19:38 <       nirik> | I have something to throw out for free discussion... should there be a time limit after which a new review request is closed for lack of interest? or should they just stay? 19:52 <      warren> | I don't think we should close review requests or bugs just because they are old. 19:54 <   BobJensen> | People I have talked to abotu submitting packages are frustrated by the reviw process 19:54 <         thl> | nirik, if you don't get answers in old review bugs it's probably okay to close them 19:54 <      warren> | He was being hand-holded through package reviews, he himself didn't know how to do anything, and he didn't learn any skills in the process. That is unsustainable, and it cannot be our responsibilty to get such people through the process. 19:54 <  BobJensen> | Most say they never hear anything 19:55 <  BobJensen> | I know nothing about packaging or the Extras Process at this time, but this is a community concern in general 19:55 <     warren> | BobJensen, ultimately volunteers cannot be forced to do anything. volunteers will only review things that interest them. 19:58 <    ignacio> | Better to have someone incapable get frustrated and leave then to let them in. 19:58 <     warren> | ignacio, I agree with that. 19:59 <    Sopwith> | ignacio: I could agree a lot more with that if Fedora Extras had a great setup for teaching people about packaging 19:59 <    Sopwith> | ignacio: I could agree a lot more with that if Fedora Extras had a great setup for teaching people about packaging 19:59 <    ignacio> | I'm working on it... --- 20:13 <        jwb> | anything from RH on the "scratch builds"? 20:14 <       jwb> | thl, i think dcbw outlined what is needed for plague pretty well. i'm talking about just "should we do it" 20:15 <        thl> | "buildroot = core + extras + needsign + scratch" sound like the best solution afaics 20:15 <        jwb> | +1 20:16 <        jwb> | packages hang out for two days and are gone? 20:16 <        thl> | jwb, +1

Full Log
18:57           --> | jpo (Unknown)  has joined #fedora-extras 19:00             * | thl looks at the watch 19:00           --- | thl has changed the topic to: FESCo Meeting in progress 19:00 <        thl> | okay, who's around? 19:01 <     nman64> | I am, but that's irrelevant. 19:01             * | Anvil is, unusualy. 19:02 <        thl> | hmmm, that not much 19:02             * | nirik is much of the time too. 19:02 <        thl> | well, let's start slowly 19:02           --- | thl has changed the topic to: FESCo Meeting in progress -- Free discussion 19:02 <        thl> | is there anything you guys want to talk about before we start looking at the schedule? 19:03 <        thl> | nirik, any plans for another "review day" 19:04 <      nirik> | I could try another one... was out of town last weekend and have been trying to catch up since then... ;) 19:04           --- | Users 60 nicks 19:04 <       nirik> | perhaps not this coming weekend, but the one after, and I could start advertising soon. 19:04            --> | scop (Ville Skytta)  has joined #fedora-extras 19:04 <         thl> | ping warren, jeremy, skvidal , ensc|w, Sopwith:  "FESCo meeting!" 19:05 <      warren> | I'm here, just waiting 19:05 <      warren> | (and doing 3 other things) 19:05 <         thl> | ahh, okay :) 19:05 <        thl> | nirik, okay, sounds like a plan 19:06 <        thl> | okay, then let's go trough the schedule 19:06           --- | thl has changed the topic to: FESCo Meeting in progress -- Kernel module standardization 19:06 <    Sopwith> | oh 19:06 <         thl> | Well, we poked dcbw and he answered 19:06 <        thl> | but now we're stuck again afaics 19:07 <        thl> | warren, or is dcbw working on it already? 19:08 <     warren> | sorry... I don't know any new information about his 19:08 <     warren> | this 19:08 <     warren> | I suggested to jeremy that we should redo the GFS kernel modules in FC5 in order to lead by example, but no response. People are very busy. 19:08 <        thl> | warren, I wanted to talk about GFS in core, too 19:08 <        thl> | warren, shall I convert it? 19:09 <     jeremy> | warren: cfeist had said he'd look at converting gfs, but hasn't 19:09 <      jeremy> | if someone wants to take a pass at it, that wouldn't be a bad thing 19:09 <    warren> | thl, that would be interesting and helpful, kick them 19:09 <     warren> | jeremy, do you agree with "single package" for GFS modules? 19:09 <        thl> | k, I'll try to find time for it 19:09 <      jeremy> | warren: I'm not against the idea 19:10 <        thl> | warren, just out of curiosity: "single package" ? 19:10 <        thl> | all the modules in one packages? 19:10 <    warren> | thl, currently GFS modules are multiple packages, which is rather stupid 19:10 <        thl> | warren, okay 19:10 <        thl> | yeah, sounds like a good idea 19:10 <     warren> | anyhow, I think this would be useful to lead by example in this way. 19:10 <        thl> | yeah 19:11 <        thl> | and we need to get kmodtool into redhat-rpm-macros 19:11 <        thl> | that was the plan iirc? 19:12 <        thl> | Think it was 19:12 <        thl> | moving on 19:12 <      warren> | Hmm.. I need to get my ass involved 19:12           --- | thl has changed the topic to: FESCo Meeting in progress --  Mass rebuild of Extras for FC5 19:12 <    warren> | thl, let us talk afterward about stuff 19:12 <        thl> | warren, okay 19:12 <        thl> | well, rebuilding SRPMS is still undecided 19:13 <     warren> | What specifically about it? 19:13 <     warren> | or do you mean noarch? 19:13 <        thl> | stupid me 19:13 <         thl> | I meant rebuilding noarch rpms 19:13 <     warren> | I personally think it isn't necessary 19:13 <     warren> | and we have bigger problems to worry about 19:14 <        thl> | jpo, what's the status regarding perl? 19:14 <        thl> | jpo, you rebuild a lot of perl packages 19:14 <        jpo> | For perl it would be good as it reduces the module loading time 19:14 <        thl> | jpo, should they all be rebuild? 19:14 <     warren> | jpo, last week there was concern about perl-5.8.8 breaking ABI or something, any more details found? 19:14           <-- | puzzled has quit ("Leaving") 19:15 <        jpo> | Warren: sent a email for the fedora-perl-list a few hours ago 19:15 <        jpo> | regarding the problem with perl-Sub-Uplevel 19:16 <       scop> | that doesn't look like anything ABI related though 19:16 <     warren> | any responses from upstream? 19:17 <        jpo> | Not yet. There at least two tickets in CPAN RT. 19:17 <        thl> | so, what do we do? 19:18 <       scop> | jpo, regarding module loading time, you mean perl not having to search that much @INC? 19:18 <        thl> | ignoring the problem for another week? 19:18 <        jpo> | scop: yes. 19:18 <     warren> | were compat dirs removed in 5.8.8? 19:18 <       scop> | no 19:19 <        jpo> | thl: No. I already have a patch but I would like a second opinion 19:19 <       scop> | why should they be removed? 19:19 <        jpo> | before commiting it 19:20 <      warren> | Just wondering how the @INC list became smaller 19:20 <       scop> | did it? 19:20 <        jpo> | I am also planning in sending an email to  the perl5-porters mailing list if I don't hear from the module author 19:20 <     warren> | How is the attitude on the lits? Probably best to ask for clarification sooner than later? 19:20 <        jpo> | warren: not smaller. The perl 5.8.8 dir is searched before the 5.8.7 ones and so on 19:21 <     warren> | ahh 19:21 <       scop> | It's actually larger in FC5 than FC4, as expected 19:22 <        jpo> | Yes: 5.8.8 and 5.8.7 19:22           --> | ensc (Enrico Scholz)  has joined #fedora-extras 19:23 <     warren> | I personally don't consider that a reason for mandatory rebuild, but the owners have the option of doing anything they want. 19:23 <     warren> | We have bigger problems elsewhere... (kmod) 19:24 <        thl> | okay, then let's ignore the noarch packages in the rebuild 19:24 <        thl> | anything else on this topic? 19:24           --- | thl has changed the topic to: FESCo Meeting in progress --  EOL Policy for FE 19:24 <         thl> | still on the list 19:25 <        thl> | we'll probably soon have a security SIG 19:25 <        thl> | maybe that can be involved in this discussion 19:25 <        thl> | so let's wait for that first 19:25 <        thl> | oaky? 19:25 <     warren> | what does SIG mean? 19:25 <        thl> | Special Interest Group iirc 19:25 <     warren> | good that it isn't called Legacy 19:26 <     warren> | How do people here feel about my idea... that this 'team' by any name should focus on tracking the problem rather than doing? (they can optionally do) 19:26 <        thl> | well, the plan is that is also watches FE-current and FE-devel 19:27 <     warren> | 1) security SIG tracks security issues and makes sure there are open bugs for each, tracked in some sort. 19:27 <      warren> | 2) existing maintainers can fix stuff, and probably will in many cases 19:27 <     warren> | 3) we can then easily see where we have gaps, and people can query easily for stuff to work on 19:27 <         thl> | warren, the current private discussion lead in a different direction 19:27 <         thl> | more a 19:27 <      warren> | My thought is, we can work on merging this methodology with Core and Legacy eventually. 19:28 <     Sopwith> | It's a nice suggestion, but I think at this point the problem really requires a motivated leader, rather than more planning. 19:28 <         thl> | team a from Securiy SiG tracks issues 19:28 <         thl> | team b from Security SIG fixes things if maintainers vanished or don#t do anything 19:29 <      warren> | Sopwith, right, it is a problem of leadership really 19:29 <     warren> | thl, I don't think team b needs to be defined officially.  the important thing is 'team a' providing the plainly easy to see data of what work needs to be done. 19:29 <    Sopwith> | If there's someone here who wants to (and has the time & commitment to) focus on security issues, that's cool. Otherwise, it's probably something that should go on the HelpWanted page. 19:30 <    warren> | thl, Red Hat operates in this way, our security team identifies issues and puts them in the database, and maintainers deal with it. 19:30 <        thl> | Sopwith, there are people who are working on  it 19:30 <     warren> | thl, sometimes security people help 19:30 <        thl> | warren, yeah, you have a point 19:30 <        thl> | warren, I'll forward you opinion to the private discussions 19:30           <-- | Foolish has quit (Read error: 110 (Connection timed out)) 19:31 <        thl> | let's wait what the guys think about it 19:31 <         thl> | warren, that okay for now? 19:31 <     warren> | can I join the private discussion? 19:31 <     warren> | I happen to know a lot about how similar models work 19:31 <     warren> | plus the volunteer motivation 19:31 <     warren> | which is unique in our situation 19:31 <        thl> | well, I'm only watching the discussions 19:31 <        thl> | mostly 19:31 <        thl> | But I'll forward your request 19:31 <     warren> | ok, I'll see where this goes. 19:31 <        thl> | k 19:32 <         thl> | moving on 19:32 <        scop> | my experience in the past is that most maintainers deal with security issues pretty quickly, and others completely ignore 19:32 <     warren> | I just want to warn against the idea of forming defined groups and expectations 19:32 <        thl> | scop, exactly... 19:32 <     warren> | groups of volunteers too often become about the people and their egos rather than results. 19:32 <     warren> | scop, right, that is why tracking is the most important part. 19:33 <        thl> | okay, let's move on 19:34            --- | thl has changed the topic to: FESCo Meeting in progress --  Broken deps report 19:34 <        thl> | mschwendt not there, skipping 19:34           --- | thl has changed the topic to: FESCo Meeting in progress -- Weekly sponsorship nomination 19:35 <        thl> | John Mahowald / jpmahowald ? 19:35 <        thl> | we didn't get to a real and last week 19:35 <        thl> | scop, warren ? 19:35 <       scop> | oh, my +1 is still in effect 19:35 <     warren> | I'm not against it, no strong feeling here. 19:36 <        thl> | that lets do it; 19:36 <     warren> | ok 19:36 <         thl> | Can anybody ask him if he wants to be a sponsor? 19:36 <       scop> | I'll take care of it 19:36 <      warren> | scop, thanks 19:36 <        thl> | scop, k, thx 19:37 <        thl> | scop, if it's okay for him drop be a mail and I'll upgrade him 19:37 <      scop> | thl, ack 19:37           --- | thl has changed the topic to: FESCo Meeting in progress -- Free discussion 19:37 <        thl> | scop, something else: 19:37 <        thl> | scop, can you also take care of adding kmodtool to redhat-rpm-macros? 19:38 <      nirik> | I have something to throw out for free discussion... should there be a time limit after which a new review request is closed for lack of interest? or should they just stay? 19:38 <       scop> | well, I obviously don't have that kind of access... 19:38 <        thl> | scop, sure; but a patch would probably be helpfull for warren and jeremy 19:38 <       scop> | ...and I think it wouldn't hurt to actually ship some module packages and watch it a bit before including in something "official" like that 19:39 <    Sopwith> | nirik: The real problem is that not enough package reviews are getting done. 19:39 <    Sopwith> | nirik: That's what I wanted to bring up :) 19:39 <        scop> | kmodtool is the smallest of our kmod problems :) 19:39 <        thl> | scop, okay 19:39 <       scop> | ...but sure, I can put together a patch 19:39 <      nirik> | yeah, many of the pending ones are pretty old... how do we interest people in reviewing them? they are often things that are not of general interest too... 19:40 <        thl> | jeremy, what about the xen problematic regarding package/kenrel names? 19:40 <        thl> | jeremy, should we file a bug? 19:40 <     warren> | Red Hat engineering needs to make a good faith effort of ratifying the standard. This involves 1) leading by example in GFS 2) helping the implemetation of buildsys hooks 3) ??? 19:40 <    Sopwith> | buildsys hooks meaning what? 19:41 <         thl> | Sopwith, passing options like "--define kvariants foo bar" to rpmbuild 19:41 <     warren> | thl, is the buildsys stuff as simple as looping through archs, or we have variants too? 19:41 <         thl> | warren, archs and variants 19:41 <         thl> | warren, and maybe kernel-versions if they differ between archs 19:41 <     warren> | thl, hmm I don't think GFS has direct support for this in core (beehive) currently. 19:42 <    Sopwith> | thl: My guess is that's unlikely. The .spec file needs to have this coded in so that builds are reproducible. 19:42 <         thl> | warren, the kversions and variants can be hardcoded in the spec 19:42 <         thl> | warren, but it should be done in the buildsys 19:42 <     Sopwith> | We can possibly come up with some preinstalled macros to make this easier (e.g. in redhat-rpm-config) 19:42 <        thl> | Sopwith, well, we discussed this in the past with jeremy 19:42 <        thl> | Sopwith, the result was a "okay, I can live with it" 19:43 <     warren> | Sopwith, I understand your feelings about this, but it was really our responsibilty to take seriously the kmod discussions earlier 19:43 <       scop> | what's the status of yum wrt kmod-* packages? 19:43 <     warren> | fortunately hard coding is possible 19:43 <        thl> | scop, don't know 19:43 <     warren> | scop,  probably best handled as a plugin, we make sure it works, and include it in yum by default when it is ready. there is another plugin that handles groupinstall conditionals that is going in soon. 19:44 <       scop> | warren, ok 19:44 <    Sopwith> | thl: I guess for the context of this discussion, my main point would be "Don't assume any specific features in the build system, such as passing macros on the cmdline" 19:44 <        thl> | warren, a plugin is in the works, but I don't know the status 19:44 <        thl> | Sopwith, okay, noted; hardcoding is possible, so it should work in beehive, too 19:45 <        thl> | warren, search yum-devel for details 19:45 <     warren> | k 19:45 <         thl> | I suppose we'll have to deal with the yum problems during FE5 19:45 <        thl> | there will be some rough edges in the beginning 19:45 <        thl> | but in genereal it should work afaics 19:46 <       scop> | so who's got the ball now? do we want this in gfs and friends first? 19:46 <        thl> | scop, I can try to convert GFS over 19:46 <       scop> | okay 19:46 <        thl> | scop, but if you want to do it feel free 19:47 <       scop> | no thanks :) 19:47 <         thl> | ;-) 19:47 <       scop> | but I _could_ hardcode everything into lirc and thinkpad kmod and just request builds... 19:47 <     warren> | GFS needs to lead by example, and I don't think cfeist has the rpm skills to do it. 19:47 <     warren> | also lacks motivation 19:47 <        thl> | jeremy, we really need to solve the xen naming issues regarding the kernel-packages/the kernel names! 19:48             * | thl hopes jeremy shows up again 19:48 <    warren> | thl, is that a different issue than other variants? 19:48 <       scop> | yes, there's a mismatch in uname and kernel-$foo 19:48 <       scop> | (naming) 19:48 <    warren> | thl, I think we need a separate small meeting between me, you, jeremy and anybody else to focus on this stuff. 19:48 <     warren> | ah 19:49 <         thl> | warren, not sure if a meeting helps 19:49 <        thl> | warren, but yeah, why not 19:49 <     warren> | at least to get some focused time from jeremy so he can make decisions 19:49 <     warren> | I'll figure it out 19:49 <        thl> | warren, k, thx 19:50 <        thl> | getting back to what nirik suggested 19:50 <     warren> | scop, any existing thread describing the xen mismatch? 19:50 <        thl> | warren, was in a private mail 19:50 <       scop> | I don't think there's a public one; thl did send some private mails last week(ish) 19:50 <        thl> | jeremy wanted to talk to the xen guys about it 19:50 <         thl> | warren, I can forward that mail to you 19:50 <    warren> | thl, that would be useful 19:51 <     warren> | I need context 19:51 <        thl> | yeah, that's often usefull :) 19:51 <         thl> | okay, now nirik again :) 19:51 <        thl> |  <       nirik> | I have something to throw out for free discussion... should there be a time limit after which a new review request is closed for lack of 19:51 <        thl> | interest? or should they just stay? 19:51 <        thl> | interest? or should they just stay? 19:51 <        thl> | interest? or should they just stay? 19:51 <     warren> | Regarding the review problem, I don't see any viable options here other than what I suggested last week. Focus on education and documentation, because nothing else is effective in the long term. 19:51 <        thl> | interest? or should they just stay? 19:52 <        thl> | uhhps, sorry 19:52 <     warren> | I don't think we should close review requests or bugs just because they are old. 19:52 <      nirik> | warren: yeah... 19:52 <        thl> | warren, agreed 19:52 <     warren> | Rahul went through closing a bunch of bugs across the board this week and got many people angry. 19:53 <      nirik> | I added comments to some of the older reviews and got some response, and some no answers... 19:53 <  BobJensen> | Can I give some Feedback? 19:53 <    Sopwith> | nirik: Thanks for taking the time to do that. 19:53 <     warren> | In the review problem, there are cases like Finalzone where I don't know what to do... 19:53 <        thl> | BobJensen, sure 19:54 <  BobJensen> | People I have talked to abotu submitting packages are frustrated by the reviw process 19:54 <        thl> | nirik, if you don#t get answers in old review bugs it's probably okay to close them 19:54 <     warren> | He was being hand-holded through package reviews, he himself didn't know how to do anything, and he didn't learn any skills in the process. That is unsustainable, and it cannot be our responsibilty to get such people through the process. 19:54 <  BobJensen> | Most say they never hear anything 19:54 <        thl> | BobJensen, yeah, that's a problem 19:55 <  BobJensen> | I know nothing about packaging or the Extras Process at this time, but this is a community concern in general 19:55 <        thl> | BobJensen, but we need solutions 19:55 <     warren> | BobJensen, ultimately volunteers cannot be forced to do anything. volunteers will only review things that interest them. 19:55 <        jwb> | and at a pace that suits them 19:55 <  BobJensen> | How can the community in general get involved? 19:55 <        jwb> | anyone can do reviews 19:55 <        jwb> | _anyone_) 19:55 <     Sopwith> | That needs to be communicated 19:56 <         jwb> | right 19:56 <      warren> | If you cannot get even a single volunteer other than yourself to look at your package, then there is a big question about the level of interest in your software. 19:56 <      warren> | it only takes 2 people to get a package into Fedora 19:56 <         jwb> | warren, that's not true 19:56 <   BobJensen> | Who can I contact to help with promoting that part of the process? 19:56 <      warren> | 2 people, and a sponsor 19:56 <         jwb> | yes 19:56 <     Sopwith> | bobjensen: You can do it yourself if you like. Just write up a post to fedora-announce-list asking for volunteers to help with package reviews, and pointing out that /anyone/ can do a review. 19:57 <      warren> | while I wanted to trust more, I got burned sponsoring Finalzone. 19:57 <      warren> | I don't know how to think about this anymore. 19:57 <    Sopwith> | What's with Finalzone? 19:57 <    ignacio> | You really do have to take a hard line when sponsoring someone. 19:57 <        jwb> | warren, but until submitters get cvsextras access there is burden on the sponsor to actually work with the package 19:57 <    ignacio> | Mollycoddling just degrades the project as a whole. 19:57 <        jwb> | ignacio, right 19:58 <     warren> | Sopwith, a case where somebody lacked even basic skills in using Linux, submitted a RPM made by someone else that he downloaded from the internet, everyone else gave him dozens of sugestions to fix the package, he himself dind't learn anything. 19:58 <    ignacio> | Better to have someone incapable get frustrated and leave then to let them in. 19:58 <     warren> | We can't be hand holding 19:58 <  BobJensen> | Sopwith: I will start with some added content ont he subjet on our Fedora Unity/Solved sites and see how we can work that in to an article for RHMag and mailing lists 19:58 <     warren> | ignacio, I agree with that. 19:58 <    Sopwith> | bobjensen: Cool stuff! 19:58 <    Sopwith> | bobjensen: BTW, you get paid for RHMag articles, which is a nice bonus :) 19:59 <     Sopwith> | ignacio: I could agree a lot more with that if Fedora Extras had a great setup for teaching people about packaging 19:59 <     ignacio> | I'm working on it... 19:59 <     Sopwith> | cool :) 20:00 <        thl> | okay, something else: warren, what's the status of the separate extras-ml-list for bugzilla spam? 20:00 <     warren> | I can create the lists, I only need decisions 20:00 <     warren> | what do we actually want? 20:00 <        jwb> | a -bug and a -review list 20:00 <        thl> | fedora-extras-bugzilla-list and fedora-extras-review-list ? 20:00 <    ignacio> | +1 20:01 <        jwb> | are sponsors required to subscribe to both? 20:01 <     warren> | no, anybody can subscribe 20:01 <     warren> | nobody can post to those lists though 20:01 <        jwb> | that wasn't my question 20:01 <     warren> | absolutely nobody 20:01 <        thl> | warren, okay for me 20:01 <     ignacio> | All contributors should subscribe to -reviews. 20:01 <        jwb> | people with cvsextras access are required to subscribe to -commits 20:01 <        thl> | ignacio, +1 20:01 <        jwb> | right 20:02 <        jwb> | +1 20:02 <     warren> | jwb, they are? 20:02 <        jwb> | they were at one time, yes 20:02 <        thl> | not anymore iirc 20:02             * | jwb goes to look 20:02 <     warren> | that isn't bein enforced 20:02 <     warren> | really no problem in allowing subscriptions 20:02 <     warren> | open project 20:02           --> | JL0gik (JerzeyLogic)  has joined #fedora-extras 20:03 <    Sopwith> | warren: I think you're missing jwb's point. Requiring some people to subscribe doesn't exclude other people from subscribing. 20:03 <        jwb> | right :) 20:03 <      warren> | ah 20:03 <      warren> | OK yes, some people are required to subscribe, everyone else has the option. 20:03 <         jwb> | basically i'm just looking to make sure that these shiny new lists aren't just bit buckets because nobody is subscribed 20:04 <         thl> | warren, maybe we should subscribe everyone from fedora-extras-list to fedora-extras-reviews-list? 20:04 <     warren> | thl, initially yes 20:04 <         thl> | warren, sure 20:04 <      warren> | and anybody that is sponsored 20:04 <         thl> | warren, sounds fine 20:05 <      warren> | I'll take this ball 20:05 <      warren> | creation of lists, announcements, etc. 20:05 <         thl> | okay, does anyone don't like this whole concept? 20:05 <      warren> | subscriptoins 20:05 <         thl> | then speak now 20:05 <         thl> | warren, thx 20:05 <     Sopwith> | I think enforcement needs to be figured out. 20:05 <     warren> | this makes it easier to find conversation on fedora-extras-list 20:05           <-- | nman64 has quit ("BRB") 20:05 <    Sopwith> | Not a reason not to do it, just a detail to take care of. 20:05             * | jwb agrees with Sopwith 20:05 <     warren> | reviews can be more easily filtered into their own folder 20:05 <     warren> | We need to promote the canned queries page more, what is the URL? 20:06 <    Sopwith> | Otherwise this is just as bad as a law saying you can't have a pet whale in your house on Tuesdays. 20:06 <     warren> | Sopwith, but only in California 20:06 <    Sopwith> | True dat. 20:06 <     warren> | how about enforcement ideas, next meeting? 20:06           <-- | JL0gik  has left #fedora-extras 20:07 <        thl> | warren, +1 20:07 <     warren> | I'll go ahead with these first steps 20:08 <     warren> | Sopwith, can our bugzilla component auto-create script add to the hidden auto-CC field automatically? 20:08 <     warren> | Sopwith, that will be necessary to add stuff like 1) perl team list to perl* 2) fedora-extras-bugs-list to auto-CC of all fedora extras components. 20:09 <    Sopwith> | warren: Hmm, I think it's doable. 20:09           --> | nman64 (Patrick Barnes)  has joined #fedora-extras 20:09 <    Sopwith> | Need a way to store & retrieve that information in a generic way. 20:09 <    Sopwith> | If you come up with the syntax you want used in owners.list, I can implement it. 20:10 <     warren> | Sopwith, it need not be in owners.list at all, these are global things 20:10 <    Sopwith> | They are not global to the multiple Fedora projects that use owners.list 20:10 <     warren> | hmm 20:11 <     warren> | Sopwith, should we have an Extras specific owners.list? 20:11 <    Sopwith> | We already do. 20:11 <     warren> | then it is global for that owners.list 20:11 <    Sopwith> | Yup 20:11 <     warren> | if perl*, then perl team list 20:11 <     warren> | if *, then fedora-extras-bugs-list 20:11 <     warren> | being careful not to blow away other auto-CC things we already have there 20:11 <     warren> | (probably entered manually by me) 20:11 <    Sopwith> | Sure. What I'd like you to do is come up with the desired syntax for lines in owners.list that will communicate this special info. 20:12 <    Sopwith> | And make sure it will work for all the use cases you can imagine. 20:12 <     warren> | no no, I'm saying it shouldn't be in owners.list at all 20:12 <     warren> | this should be hidden from owners.list 20:12 <     warren> | it is needless complication 20:12 <    Sopwith> | Why hide it? 20:12 <        thl> | warren, Sopwith can you work out the details later? 20:12 <     warren> | because it is a blanket policy 20:12 <     warren> | yes 20:12 <     warren> | I'll talk with sopwith privately 20:12 <        thl> | thx 20:12 <        thl> | anything else left? 20:13 <     warren> | I think we have enough to work on 20:13 <         thl> | yeah 20:13 <        jwb> | anything from RH on the "scratch builds"? 20:13 <        jwb> | as in, can we do it? 20:13 <        thl> | jwb, that depends on the new plague iirc 20:13 <     warren> | good question.. 20:13 <       jwb> | thl, yeah i know. i meant outside of the technical things 20:13 <     warren> | oh, somewhat related buildsys question, anybody remember the URL to the needsign yum repo? 20:14 <        thl> | warren, http://buildsys.fedoraproject.org/plague-results/ 20:14 <       jwb> | thl, i think dcbw outlined what is needed for plague pretty well. i'm talking about just "should we do it" 20:14 <     warren> | question 20:14 <        thl> | jwb, good question 20:14 <     warren> | should scratch populate the scratch buildroot with itself 20:15 <     warren> | or only Extras + needsign is the buildroot? 20:15 <     warren> | scratch buildroot = core + extras + needsign? 20:15 <     warren> |  scratch buildroot = core + extras + needsign + scratch? 20:15 <        jwb> | warren, that was some of the dep solving things that dcbw was talking about 20:15           --> | Foolish (Sindre Pedersen Bjordal)  has joined #fedora-extras 20:15 <     warren> | It is a simple matter of creating another mock definition and plague target 20:15 <        thl> | "buildroot = core + extras + needsign + scratch" sound like the best solution afaics 20:15 <        jwb> | +1 20:16 <     warren> | What policy governs scratch? 20:16 <        jwb> | packages hang out for two days and are gone? 20:16 <        thl> | jwb, +1 20:16 <     warren> | If we use existing infrastructure, stuff needs to go in CVS before built in scratch 20:16 <     warren> | but CVS conflicts with the contents of extras 20:16 <        jwb> | yes 20:16 <        thl> | warren, yes 20:16 <        jwb> | conflicts? 20:17 <     warren> | you aren't sure if packagename/FC-5 means Extras or scratch 20:17 <        thl> | warren, people want to use it to test there builds before they are build for real 20:17 <     warren> | hmm 20:17 <        jwb> | which brings up a better question:  should scratch only exist for devel? 20:17             * | jwb sorta see's warrens point 20:18 <     warren> | Red Hat has a scratch target 20:18 <     warren> | it doesn't build from CVS 20:18 <     warren> | and requires manual pruning 20:18 <     warren> | it also doesn't populate a buildroot, which is both good and bad in some ways. 20:18 <        jwb> | plague can build from uploaded SRPMs, but i dont think we want to do that 20:19 <     warren> | "2 days" automatic pruning sounds like a good idea, but is that problematic? 20:19 <        thl> | no, we don't want that afaics 20:19 <        jwb> | warren, only if you allow scratch builds to be ongoing during the prune 20:19 <     warren> | we need pruning of some sort 20:20 <     warren> | scratch in RH regularly takes up LOTS of storage 20:20 <     warren> | Too many implementation details here, and I don't think this is as importnat as other tasks 20:20 <     warren> | lets get these tasks done, and revisit the details of this in nex tmeeting 20:20 <        thl> | agreed 20:20             * | thl will close this meeting in 30 20:21             * | thl will close this meeting in 15 20:21           --> | dcbw (dcbw)  has joined #fedora-extras 20:21 <    roozbeh> | while all the big fish are here, 20:21             * | thl will close this meeting in 10 20:21 <       dcbw> | skvidal: ping 20:21 <    roozbeh> | would someone fix the FC4 build thing? 20:21 <        thl> | MARK: Meeting end