From Fedora Project Wiki
< Extras | SteeringCommittee
Summary
Present from FESCo: thl, warren, Sopwith, mschwendt, scop, thomasvs
- FESCo future/election
- abadger1999 working on it
- buildsys-build
- new mock in the works
- Encourage Extras reviews
- tibbs is working on better documentation; Initial work at http://www.fedoraproject.org/wiki/Extras/HowToGetSponsored
- some discussions how to improve the situation in general -- see 0:10 and later for details
- MIA/AWOL maintainers
- we might track this with the package database ( http://fedoraproject.org/wiki/Infrastructure/PackageDatabase ) in the long term; no other progress
- kmod's enhanced ( see kerneldrivers.org )
- Seems there is no real benefit nor detriment for Fedora -- we'll wait and look what falls out of the work from jcmasters work for RHEL5
- Free discussion
- CTRL-C-Problem -- cvs-commits-mails can be prevented by hitting CTRL+C during commit. Warren and the infrastructure group will look into fixing this (if possible)
Full Log
23:57 < warren> | mspevack, should we discuss your new idea about dealing with unpopular reviews during this fesco meeting?
23:57 < mspevack> | warren: i'd rather write a note to the list and let it see discussion there. it's easier to lay out thoughts in an email than on irc
23:58 < warren> | mspevack, alright
23:58 < tibbs> | mspevack: Could you give me a heads up on that?
23:58 < Sopwith> | warren: Please explain what this all means - what's the problem with having the account system know the sponsor -> sponsoree connection, which is how it's currently implemented?
23:59 < warren> | Sopwith, that's the only relationship it knows about, but it needs to know about the packages and other data related to that.
23:59 --> | mschwendt (Michael Schwendt) has joined #fedora-extras
23:59 < warren> | Sopwith, http://fedoraproject.org/wiki/Infrastructure/PackageDatabase
23:59 < Sopwith> | warren: Yes, but you said above that we needed a formal database for sponsor->sponsoree info. I'm saying that we already have that info.
0:00 < warren> | Sopwith, I guess that's the easy part then. The hard part is all the other missing pieces.
0:00 < warren> | Sopwith, and I have a strong interest in implementing this stuff.
0:00 < thl> | sorry to interrupt you guys, but it's time...
0:00 < Sopwith> | OK, so never mind that bit, cool.
0:00 --- | thl has changed the topic to: FESCo meeting in progress
0:00 --> | thomasvs (Thomas Vander Stichele) has joined #fedora-extras
0:00 < thl> | okay, who's around?
0:01 * | bpepple lurking about.
0:01 * | mschwendt is here
0:01 * | abadger1999 lurking as well
0:01 --> | mdomsch (Matt_Domsch) has joined #fedora-extras
0:01 < cweyl> | rabble here!
0:01 < tibbs> | rabble as usual.
0:01 < thl> | okay, then let's start slowly
0:02 * | nirik is also rabble. ;)
0:02 < thl> | something not on the schedule (don#t know why...)
0:02 --- | thl has changed the topic to: FESCo meeting in progress -- FESCo future/election
0:02 * | skvidal is here
0:02 * | thomasvs is in
0:02 < thl> | abadger1999, spot, what's the stuatus of the voting system?
0:02 * | scop partially here, not much time today
0:02 < abadger1999> | I think we're at the point of needing to start testing things
0:03 < thl> | abadger1999, what is needed to test things?
0:03 < abadger1999> | There's a few error conditions where I have to write something to send an email and display an error for the voter to see but the logic is all there
0:04 < thl> | abadger1999, do we need help from Sopwith (he might still be around)
0:04 < Sopwith> | I'm still here
0:04 < thl> | abadger1999, any expected timeframe when it might be ready?
0:04 < abadger1999> | spot, Sopwith: What can we get? Can we put the code somewhere and create a test electiondb in postgres?
0:04 < thl> | I'd really like to start the election...
0:05 < abadger1999> | And then try it out agains tthe live accounts system?
0:05 < abadger1999> | (Read-only access to the accountsdb rw to electiondb)
0:05 < Sopwith> | abadger1999: Would you be able to stop by #fedora-admin at 20:00 GMT for our meeting?
0:06 < abadger1999> | About three hours? I think I can do that.
0:07 < thl> | Sopwith, would be really nice if you could help the guys getting the elction system in place
0:07 < thl> | anyway, I'll move on for now
0:07 < abadger1999> | thl: I'd like to see it done this week. I need to find and squash bugs and finish off the error notification.
0:07 < thl> | abadger1999, great, many thx!
0:07 --- | thl has changed the topic to: FESCo meeting in progress -- buildsys-build
0:08 < thl> | skvidal, any plans / timeframe for a new mock release?
0:08 < Sopwith> | thl: Yup, that's the plan.
0:08 < skvidal> | thl: well now that we have everyone okay w/this release and fix the issues with mockhelper meb found for the next
0:08 < skvidal> | it should be by this weekend at the latest
0:09 < thl> | skvidal, k, thx
0:09 < thl> | I think this topic is mostly ready; I'll remove it from the schedule
0:09 <-- | BobJensen-Away has quit (Read error: 101 (Network is unreachable))
0:09 --- | thl has changed the topic to: FESCo meeting in progress -- Encourage Extras reviews
0:10 < thl> | warren, tibbs (or anyone else)
0:10 < tibbs> | Started in on some basic documentation work:
0:10 < tibbs> | CommonRpmlintIssues and thl started FrequentlyMadeMistakes
0:10 < tibbs> | but then I lost access to those pages.
0:10 < tibbs> | I need to get with spot to straighten that out.
0:11 < tibbs> | In the meantime I'd like to delve a bit into the review requirement for sponsorship.
0:11 < warren> | mspevack came up with some new ideas on this topic yesterday, he'll be posting to the list soon.
0:11 < tibbs> | It's not very well documented that people who want sponsorship need to do reviews; we need to change that.
0:11 < warren> | tibbs, +1
0:11 < tibbs> | Where would a "HowToGetSponsored" page go? Under Extras?
0:11 < warren> | yes
0:12 < warren> | Sponsorship today is entirely an Extras thing.
0:12 < tibbs> | OK, can we agree on how much review someone should do? I'd like to see five or so good review comments.
0:13 < tibbs> | Or does that even need to be written down?
0:13 < warren> | we were hesitant in the past to give a number
0:13 < warren> | how do you define "good review comments"? who judges?
0:13 < bpepple> | Yeah, I don't think setting a number of reviews is a good thing.
0:14 < tibbs> | The sponsor should judge, but I don't want to leave folks hanging wondering if they've done "enough".
0:14 < tibbs> | Then again, I don't want to see anyone saying "I've done my N reviews, so I should get in".
0:15 < tibbs> | OK, another thought:
0:15 < warren> | more generally people that do things like reviews gain "leadership"
0:15 < tibbs> | Should we encourage new package submitters to include "references" in with their request for sponsorship?
0:15 < tibbs> | Right now I just see "this is my first package and I need a sponsor" and I have to go off searching.
0:16 < warren> | Wait, are we talking about sponsorship to gain cvsextras, or to gain sponsorship access?
0:16 < tibbs> | Just to get their first package in. cvsextras.
0:16 < bpepple> | tibbs: 'references' to what? reviews?
0:16 < tibbs> | Reviews or community activity.
0:17 < tibbs> | Think about it this way: I'm wondering if I should sponsor someone. How on earth do I know whether that's a good idea?
0:17 < warren> | Who they are is less important than "Do they understand the packaging guidelines and process?"
0:17 < tibbs> | I think there's more at issue that that, though.
0:18 < bpepple> | warren: +1
0:18 < nirik> | ...and if they are going to stay around and keep maintaining their packages and not dissapear... ?
0:18 < tibbs> | nirik: precisely.
0:19 < warren> | tibbs, for example, Fernando and his audio based packages. Sure his references and community standing are excellent, but at least at first he clearly didn't even read the packaging guidelines.
0:19 < tibbs> | Yes, and that you can guage from looking at the package. But that's all you can get from looking at the package.
0:20 < tibbs> | And in that review request right now all anyone puts in is the package. I'm wondering if we shouldn't encourage people to give us more info.
0:20 < warren> | nirik, tibbs: to deal with the "are they going to stay around" question, we cannot possibly *know* for sure beforehand. In a volunteer organization the best we can do is track it, automated hopefully... thus another package database problem.
0:20 < warren> | tibbs, like a CV?
0:21 < tibbs> | Pretty much.
0:21 < nirik> | if someone has a good history of community involvement, it's a indication that they are more likely to stick around... but yeah, we can never know.
0:21 < RTLM> | well and you can't rule someone out with no history
0:21 < tibbs> | Of course not. But you can consider history.
0:21 < RTLM> | you may get someone new that will stick around for years.
0:21 < RTLM> | nod
0:21 < warren> | That's why demonstrating clear understanding of the process and guidelines are the key requirement to gaining cvsextras access.
0:22 < RTLM> | yeah, a bad history is probably a good indication
0:22 < tibbs> | The point is that FE-NEEDSPONSOR has a bunch of bugs blocking it and I'm not having too much luck...
0:22 < RTLM> | If only to keep everyone else from constantly cleaning up behind them.
0:22 < tibbs> | finding people who I immediately _want_ to sponsor.
0:23 < tibbs> | Anyway, I'll work on HowToGetSponsored.
0:23 < warren> | The clear mistakes that I've seen and made myself in sponsoring people were cases where 1) blanket approval because their requests sat too long 2) people that needed too much hand holding because they didn't have enough skills to understand the package guidelines.
0:23 < warren> | #1 was eliminated with revocation and education
0:23 < bpepple> | tibbs: A lot of those people haven't done much beyond just submitting a package. Ask them to do some reviews, so you can gauge their knowledge of the guidelines.
0:23 < warren> | #2 has one remaining case...
0:24 * | RTLM wonders if an "unsponsored" repo may be warented.
0:24 < warren> | bpepple, tibbs: Maybe HowToGetSponsored should focus on "how to demonstrate your understanding of ..."
0:24 < thl> | RTLM, nope
0:24 < bpepple> | warren: That's a good idea.
0:24 < thl> | RTLM, I don't think so
0:25 < bpepple> | RTLM: -1
0:25 < warren> | RTLM, that might promote a fire-and-forget dumping ground
0:25 < RTLM> | :-o
0:25 < RTLM> | I can see that
0:25 < nirik> | perhaps the bugzilla submit for a new request could spill out on a page explaining that if it's your first package you should go to HowToGetSponsored to learn how to get sponsored?
0:25 < RTLM> | and its that much more overhead
0:26 < warren> | nirik, one possible idea is to make a better review process as part of the package database system, and we'd have that kind of flexibility there.
0:26 < warren> | The process does need to be more informative
0:26 < thl> | warren, tibbs, I'd like to stop here
0:26 < thl> | we can contiune another time
0:26 < warren> | Yes, too many tangents.
0:27 < thl> | otherwise we'll run late
0:27 < warren> | This is a *hard* problem that we've been discussing for a year+. We wont solve this overnight.
0:27 < warren> | Although mspevack's idea may help. =)
0:27 * | warren nudges mspevack.
0:27 --- | thl has changed the topic to: FESCo meeting in progress -- MIA/AWOL maintainers
0:27 < thl> | mschwendt, any progress?
0:28 < thl> | or revisit this item next week?
0:28 < warren> | thl, short-term mia.list, long-term package database tracking? Isn't that the plan?
0:28 < thl> | warren, MiaList in the Wiki was the short-term solution iirc
0:28 < thl> | long-term package databas -> yes
0:28 < warren> | ok
0:28 < mschwendt> | thl: no progress - but you can mark the other two actions items as done (repoclosure, dupe builds)
0:29 < warren> | http://fedoraproject.org/wiki/Infrastructure/PackageDatabase I encourage people to add more details to this page.
0:29 < warren> | If we have disagreements about details, we can discuss them.
0:29 < warren> | otherwise just add stuff
0:29 < thl> | warren, thx, I'll mention it in the summary
0:30 < thl> | mschwendt, with "repoclosure" you mean "Broken deps report" (running on build64)?
0:30 < thl> | (just to be sure)
0:30 < mschwendt> | yes
0:30 < thl> | mschwendt, thx, will do
0:30 < thl> | mschwendt, and thx for your work
0:30 < warren> | mschwendt, do you and scop have sudo access on that box? you really should.
0:31 < mschwendt> | not sure I need that
0:31 < scop> | ditto
0:31 < warren> | ok
0:31 --- | thl has changed the topic to: FESCo meeting in progress -- kmod's enhanced
0:31 < thl> | scop, and I looked into this
0:32 < thl> | anyone else interested in that topic?
0:32 < warren> | thl, are details at a URL or posted to a list?
0:32 < warren> | public
0:32 < thl> | warren, in the archieves of fedora-packaging iirc
0:32 < warren> | ah
0:32 < thl> | jcm wanted to create a page in the wiki but never actually did it afaics
0:33 < warren> | thl, do you need someone to poke him?
0:33 < thl> | s/jcm/jcmasters/
0:33 < thl> | warren, no, I don#t think so
0:33 < warren> | thl, perhaps this is a very specialized topic, just invite folks here and on the devel groups to join the discussion if they care. Otherwise whoever cares and contributes gets to decide?
0:34 < thl> | warren, the problem simply is: the stuff is interesting
0:34 < thl> | but has no real benefits for Fedora afaics
0:34 < scop> | it's more like everyone who's interested needs to be nudged towards looking at the stuff at kerneldrivers.org
0:34 < warren> | You mean... interesting, but would actually be of detriment to Fedora?
0:34 < scop> | no
0:34 < thl> | no, I don't think so
0:35 < scop> | one obvious benefit would be that we'd no longer need to list "known" kernel variants in kmodtool
0:35 < warren> | Point people at it, but Fedora will just follow what is ratified?
0:36 < thl> | warren, I'm not sure we should follow blindly
0:36 < scop> | and it _could_ make it so that some module packages won't need to be rebuilt for every kernel release
0:36 < thl> | warren, but we'll watch the new stuff and should probably discuss some things here now and then if that might be needed
0:36 < warren> | hm
0:37 < thl> | but in genereal I mostly agree with " perhaps this is a very specialized topic, just invite folks here and on the devel groups to join the discussion if they care. Otherwise whoever cares and contributes gets to decide?"
0:37 < warren> | OK
0:37 < thl> | warren, spot as our future official "packaging master" might have a word on this, too
0:38 < thl> | anyway, let's stop here
0:38 < thl> | we'll get back to it when it might be needed
0:38 < scop> | (btw, on a 2nd thought, "known" kernel variants list would probably still be needed)
0:38 --- | thl has changed the topic to: FESCo meeting in progress -- Weekly sponsorship nomination
0:39 < thl> | any nominations?
0:39 * | thl will wait 30 seconds
0:39 < warren> | sorry none here, I've been completely swamped by security issues in the past week
0:40 < thl> | okay, let's move on
0:40 --- | thl has changed the topic to: FESCo meeting in progress -- Free Discussion
0:40 < warren> | I have to get lunch before my next meeting.
0:40 < warren> | bbl
0:41 < thl> | just FYI: I'll prepare a more detailed proposal for the ideas that I outlined in https://www.redhat.com/archives/fedora-advisory-board/2006-June/msg00013.html
0:41 < thl> | and post in to f-extras-list
0:41 < thl> | that more a long term plan
0:41 < thl> | warren, still around?
0:41 < thl> | CTRL-C problem in CVS?
0:42 < scop> | I'm planning to integrate the broken upgrade path report somewhere so it's run automatically, https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00960.html
0:42 * | thl will add that to the schedule and clean the schedule page up while at it
0:42 < warren> | thl, ?
0:42 * | thomasvs still recommends the power of the ampersand for CVS
0:43 * | scop needs to go in 2 minutes
0:43 < thl> | warren, you wanted to look in the cvs problem "commits-mails are prevented when CTRL+C is hit in the right moment"
0:43 < warren> | thl, I can do so during my next two meetings, infrastructure related.
0:43 < thl> | warren, you wanted to try what thomasvs suggested
0:43 < warren> | both
0:43 < thl> | warren, k, thx
0:43 < warren> | thomasvs, isn't that only a 99% solution?
0:43 < thl> | scop, we should try to get that also on build64
0:43 < thl> | so it is run after the push scripts?
0:43 < thomasvs> | warren: where does the last 1% go ?
0:44 < warren> | thomasvs, if they get their timing just right?
0:44 < scop> | thl, yes
0:44 < thomasvs> | warren: only one way to find out
0:44 < thomasvs> | warren: but I would be surprised if it was
0:44 < thl> | scop, how often shall in run? every push?
0:44 * | warren checks in trojans in order to test it...
0:44 * | warren get sfood
0:44 < tibbs> | I'm curious what the general opinion within Red Hat is regarding the Extras/sponsorship process. (Or if there even is one.)
0:45 < scop> | dunno, thoughts welcome
0:45 < thl> | scop, how long does in take to create that list?
0:45 < thomasvs> | btw, I think you can also have pre-commit hooks, that receive the diff, so you can send the diff *before* committing
0:45 * | spot is back at keyboard, anything for me? :)
0:45 < thomasvs> | so that ctrl-c would also make it not commit
0:45 < tibbs> | I ask because I was this in a package review:
0:45 < tibbs> | "There doesn't seem to be any way to avoid the requirement for sponsorship."
0:45 < scop> | a few seconds with cached metadata, otherwise slightly more, but always < 1 minute
0:46 < thl> | scop, then I'd vote for "with each push"
0:46 < thl> | spot, no, I don't think so
0:46 < thl> | spot, maybe one thing:
0:47 < thl> | spot, what are your feeling on the kmod stuff from jcmasters ?
0:47 < spot> | the abi stuff?
0:47 < thl> | spot, yes
0:47 < scop> | thl, hm, actually we wouldn't ever want to run that against cached metadata
0:47 < spot> | well, both me and davej agree that fedora kernels have no abi
0:47 < scop> | but it just took 27 seconds on my local box w/o caching
0:47 --> | jima_ (jima) has joined #fedora-extras
0:47 < skvidal> | scop: metadata parsing is vroomier now in rawhide
0:48 < thl> | scop, let's add it for now; we can change that later again
0:48 < skvidal> | scop: way vroomier
0:48 < spot> | so it really doesn't make any difference if we use an ABI that changes every version-release
0:48 <-- | jima has quit ("Reconnecting")
0:48 < spot> | or just version-release
0:48 < scop> | skvidal, great
0:48 --- | jima_ is now known as jima
0:48 < scop> | anyway, I need to go now, seeya
0:48 < spot> | i'll defer to what the kmod tool provides
0:48 < thl> | scop, yes, I also agree with "no abi in fedora kernels"
0:48 < thl> | s/scop/spot/
0:49 < thl> | but having a similar solution in RHEL and in Fedora would be nice
0:49 < spot> | thl: i see the value in that specific change being consistent with RHEL
0:49 < thl> | and it would be even nicer when this or similar/compatible stuff works on Suse, too
0:49 < spot> | but you'd have to get davej onboard to add things to his kernel package, right?
0:50 < thl> | spot, probably
0:50 < spot> | jcmasters: awake?
0:50 < thl> | spot, but didn't he add some of that stuff already
0:50 * | thl is not sure
0:50 < spot> | thl: ok, i'll email him and we'll try to figure out what changes would be necessary for FC kernel
0:50 < thl> | spot, k
0:50 < spot> | if they're too intrusive, this might die
0:50 < spot> | but if not, i'll try to push for it
0:51 < thl> | spot, just FYI: I'm more in a "just waiting what happens position" with that suff atm
0:51 < thl> | I don#t want to invest to much time in it
0:51 < spot> | thl: i told jcmasters that i would defer to whatever the kmodtool owner implemented
0:52 < spot> | since there's no direct Fedora benefit.
0:52 < thl> | spot, yeah, saw that; kmodtool is a quite short sript atm
0:52 < spot> | thl: are you the author of that?
0:52 < thl> | I can live with a situation where we carry some things for RHEL in it around, even if fedora doesn't use it
0:53 < thl> | spot, yes, scop and me wrote it
0:53 < spot> | well, if we implement ABI in the kmodtool, i'll want to use it.
0:54 < spot> | that way, the spec will be consistent for RHEL and Fedora
0:54 < thl> | let's stop this discussion for now and wait how it all works out
0:54 < spot> | ok
0:54 < thl> | anything else we need to discuss for Extras today?
0:55 < tibbs> | spot: Any chance we could work out access to some of the pages under Packaging?
0:55 < tibbs> | CommonRpmlintIssues and FrequentlyMadeMistakes?
0:55 < spot> | tibbs: sure.
0:56 --- | mspevack is now known as mspevack_mtg
0:56 < spot> | tibbs: i'll try to open the ACLs for those (assuming that moinmoin plays nice)
0:56 * | thl will close the meeting in 60 seconds
0:56 < tibbs> | Thanks.
0:57 * | thl will close the meeting in 30 seconds
0:58 * | thl was afk for a moment...
0:58 * | thl will close the meeting in 10 seconds
0:58 < thl> | -- MARK -- Meeting end
0:58 < thl> | thx everyone!