From Fedora Project Wiki
< Extras | SteeringCommittee
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