EPEL/Meetings/20070318
From FedoraProject
Contents |
Meeting 20070318
Attending
- entr0py
- nirik
- quaid
- thimm
- thl
Summary
- Some discussions about the meeting time; seems to be quite important for some people to make sure the current main EPEL drivers can make the meeting; But Sundays on the other hand are bad for some people (especially people that might get payed for packaging stuff in EPEL) and we try to check for alternative times by using the wiki page: http://fedoraproject.org/wiki/EPEL/NewMeetingTime ; if you would be interested to join the SIG meetings times please fill that table out! tia!
- RHEL5 on the builders -- there are some issues getting RHEL5 in place, but they hopefully sort out soon; the current plan is to use a merged tree for building (as agreed on in the past)
- we probably need to split the repo up for different users like CentOS, RHEL5 Desktop (4 flavours afaics: Client, VT, Workstation, WOrkstation + VT) and Server (2 flavours) to make sure yum doesn't run into missing-dep situations; maybe this can be done with a yum plugin, needs to be investigated. Anyone interested to help? thl will look into this, but that might take some days as he has others things on this plate
- Some discussions on http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates
- thimm wants to allow kernel modules, but thl and nirik would like to avoid them for now
- some discussions how to push packages to the different repos and tested pacakge to the stable repo ; it was suggested to use three repos:
- stable -- main repo
- stable-testing -- test packages there for a short time period before they get *moved* to stable
- devel/testing/updates-nextrel -- packages get queued up here; this becomes stable with the next quarterly update
The current proposal works with just two repos and suggested to build packages for devel/testing (against the latest updates that might become the next quarterly update) and then build the pacakge anew for stable if everything looks fine
Please discuss on the list!
- thimm urges to have a "Voting body & fesco mandate" (btw, we have a fesco mandate, but it's not actually clearly written down). thl will write something up and present it to the world and FESCo
Note: there are some takes on the schedule at http://fedoraproject.org/wiki/EPEL/Schedule that could need some help.
Full log
00:00 --- | thl has changed the topic to: EPEL SIG meeting 00:00 < thl> | ping EPEL SIG members 00:00 < thl> | who's around? 00:00 * | quaid is here 00:00 * | thimm is 00:00 < entr0py> | bjohnson here 00:00 * | nirik is here. 00:00 --- | thl has changed the topic to: EPEL SIG meeting -- http://fedoraproject.org/wiki/EPEL/Schedule 00:01 < thl> | hi everyone 00:01 * | kanarip is here 00:01 < thl> | dgilmore mentioned it would be likely that he could not join us today 00:01 < thimm> | :/ 00:01 < thimm> | Isn't he the only one that insists on Sunday meetings? 00:02 < nirik> | yeah, sunday or off business hours during the week... 00:02 < thl> | nirik, yes, something like that was what dgilmore wants 00:03 < thl> | and even if someone asks for this is doesn't mean that he has free time each week ;-) 00:03 < nirik> | true... 00:03 < thimm> | So, how about we move the meeting time into the work week? 00:03 < thl> | I pinged mmcgrath in #fedora-devel 00:03 --- | thl has changed the topic to: EPEL SIG meeting -- http://fedoraproject.org/wiki/EPEL/Schedule -- meeting time 00:04 < thl> | thimm, well, "off business hours" in the US means probably middle of the night for us europeans 00:04 < nirik> | thimm: where was the link to that wiki timeschedule page you made? I was meaning to look at it and add, perhaps we could see what time works best based on that? 00:04 < thimm> | Isn't he down-under? 00:04 < thimm> | http://fedoraproject.org/wiki/EPEL/NewMeetingTime 00:04 < thl> | thimm, dgilmore? no 00:04 < thimm> | But noone entered anything in there 00:04 < thl> | he comes from down under iirc, but is in the US for some years now 00:05 < nirik> | do we have any west coast people at all? perhaps we could use that time as well? 00:05 < nirik> | (for now) 00:05 < nirik> | yeah, I think he's in MN.us. 00:05 < thl> | quaid, are you on the west coast? 00:05 < quaid> | I am 00:06 < nirik> | ah, sorry, thought there weren't any west coast folks. :) My mistake 00:07 < quaid> | we used this to figure out likely slots for our far-flung FDSCo members: 00:07 < quaid> | http://fedoraproject.org/wiki/BobJensen/MeetingTimes 00:07 < thl> | well, I stated my preferred times on the list in https://www.redhat.com/archives/epel-devel-list/2007-March/msg00203.html 00:07 < quaid> | each person put in their unavailability by their initial, and we looked for the ligthest coverage 00:07 < thimm> | similar to what we did with FPC 00:07 < quaid> | thl: right, we tried that for a while, but it failed to make it obvious when the best times were 00:08 < quaid> | so, if passing ideas back and forth doesn't help, me may need a matrix like this 00:08 < thimm> | See http://fedoraproject.org/wiki/Packaging/NewMeetingTime 00:08 < thimm> | This is what I used as a template for http://fedoraproject.org/wiki/EPEL/NewMeetingTime 00:08 < nirik> | I would prefer to have dgilmore around, since he is dealing with so much of the infrastructure, but most times are ok with me otherwise. 00:09 < nirik> | thimm: sundays are usually bad for you? 00:09 < thl> | nirik, +1, we need to make sure the certain key driers so far can join the meeting normally 00:09 < thimm> | Yes 00:09 < thimm> | Sundays seems to be bad for many people including @RH.com 00:09 < nirik> | yeah, true... 00:10 < nirik> | from dgilmore's email to the list: " It would need to be between 23:00-3:00 UTC or 11:30-12:30 UTC or on the weekends." 00:10 < thimm> | We'd like more participation from the enterprise world and people with jobs like to work on Mo-Fr 00:10 --> | che (Rudolf Kastl) has joined #fedora-meeting 00:10 < thl> | thimm, we fist need to lift of... 00:10 < nirik> | thimm: agreed. 00:11 < thimm> | thl: If we close doors, how will we lift off? 00:11 < thl> | anyway, can somebody fill out http://fedoraproject.org/wiki/EPEL/NewMeetingTime with what we know so far 00:11 < thl> | then we can ask the others to put up their time 00:11 < thl> | and then we can look further 00:11 < thl> | thimm, it's not that bad currently 00:12 < thl> | and those that showed most interested seems to agree on sunday 00:12 < thl> | for now 00:12 * | thimm looks around 00:12 < nirik> | I think we are left with sunday or not having dgilmore available at the meetings. 00:12 < thl> | nirik, +1 00:12 < thimm> | nirik: Or both like today ... 00:13 < thimm> | I won't be able to make it on other Sundays 00:13 < thimm> | This is my first Sunday I could make it anyway 00:13 < nirik> | what about saturday? 00:13 < thimm> | Well, weekends in general are bad, but Saturday early (in UTC speech) are the lesser evil 00:14 < nirik> | perhaps we can propose that to dgilmore. Or just pick a weekday meeting time and move on. 00:15 --> | engwnbie (Leo Canale) has joined #fedora-meeting 00:15 * | thl still votes that somebody that pre-fills http://fedoraproject.org/wiki/EPEL/NewMeetingTime with what is publically known; then we ask others to add their info, and then we'll look at it next week 00:15 < thimm> | It would make sense for everyone interested to fill out his own slots 00:15 < thimm> | That's how it worked at the FPC 00:16 < thimm> | Cross out what you can't attend and ++ the lsots you prefer 00:16 < thl> | thimm, go ahead and to it 00:16 < thimm> | s/lsots/slots/ 00:16 < thl> | thimm, somebody needs to start 00:16 < thl> | so others know how it shall look like 00:16 < thl> | add mine and dglimores times, too 00:16 < thl> | and others will join 00:16 < nirik> | in my case as long as it's not fesco and at times I am awake it's ok with me. ;) 00:17 < thl> | let's fill out the form until next week and then look at it? 00:17 < thl> | and move on now? 00:18 < nirik> | ok 00:18 < thl> | somebody just needs to start afaics 00:18 * | thl will move on 00:18 --> | glezos (Dimitris Glezos) has joined #fedora-meeting 00:18 --- | thl has changed the topic to: EPEL SIG meeting -- http://fedoraproject.org/wiki/EPEL/Schedule -- RHEL5 on the builders 00:19 < thl> | we have some issues getting RHEL5 in place 00:19 < thl> | but they hopefully sort out soon 00:19 < nirik> | I think dgilmore was working on that. ;) 00:19 < thl> | dgilmore, yes, he and mmcgrath are working on it 00:19 < nirik> | FYI, centos has a 4.92 beta out to test with... 00:19 < thl> | the big problem is: 00:19 < thl> | do we need one merged tree 00:20 < thl> | or different ones for Client and server 00:20 < thl> | I'd say: 00:20 < thimm> | thl: OK, my part is done 00:20 < nirik> | I think we agreed on one merged tree in the past. I think Client and Server would make things too complicated. 00:20 < thl> | nirik, +1 00:20 < thl> | nirik, neertheless we need to split stuff somehow 00:20 < thl> | otherwise Client users will run into missing dep issues 00:20 < nirik> | split how? 00:21 < thl> | if a pacakge requires something from the server 00:21 < thl> | split the repo into Client (Desktop, VT, Workstation, VT+Workstation) and Server 00:21 < thl> | or use a yum plugin 00:22 < thl> | that prevents that people run into missing dep issues 00:22 < thimm> | yum plugin sounds nicer 00:22 < thl> | thimm, +1 00:22 < thl> | that's my plan, too 00:22 < nirik> | yuck. Yeah, yum plugin would be better... 00:22 < thl> | as we would hae just one repo 00:22 < thimm> | It will deal with any furture layering of RHEL products, too 00:22 < thl> | and centos users simply could use all 00:22 < nirik> | but who is going to write it? :) 00:22 < thl> | nirik, that's the problem... 00:22 < thimm> | Well, is it really a plugin? 00:23 < che> | thl, well but the plugin cant just ignore missing deps 00:23 < thimm> | Maybe it is yum core functionality 00:23 < thl> | che, we'd need to ship list of packages 00:23 < thimm> | Like a switch to deal with missing/broekn deps 00:23 < thl> | where we know that deps will be missing 00:23 < thl> | well, or something like that... 00:23 < thimm> | This switch would be usefull for rawhide as well 00:23 < thl> | I'll try to look into this during the week 00:23 < thl> | and post to the list 00:24 < thl> | but well, if somebody else is interested in solving this I won't mind :) 00:24 < thl> | is anyone? 00:24 < nirik> | didn't someone post a list of packages that were just in server/client? I can't find the list now... 00:24 < thimm> | I did on epel and rhelv5 lists 00:24 < thl> | nirik, is more complicated then just server vs client 00:25 < thimm> | Just grep for evolution in the body 00:25 < thl> | nirik, there are different client versions 00:25 < nirik> | thl: in 4, but not 5, right? 00:25 < thimm> | thl: sure? 00:25 < nirik> | 5 just has a since client/workstation I thought. 00:25 < thimm> | thl: difference in premium etc is support, not content 00:25 < thl> | only RHEL5-Client-Workstation for example ships PHP and eclipse 00:26 < thl> | thimm, not 100% sure, but quite sure, yes 00:26 < thl> | you have a isntall-number 00:26 < nirik> | ah, found the list... it's pretty small... 00:26 < thl> | you have to fill in during install 00:26 < thl> | and that decides about the package set you can install 00:26 < thimm> | I see 00:27 < quaid> | are the "not available" packages not oon RHN for those install types? 00:27 < thimm> | so one media, several outputs 00:27 < thl> | well, as I said, I'll try to look at this closer during the week 00:27 < thl> | thimm, yes 00:27 < thl> | quaid, are they? 00:27 < quaid> | I don't know 00:27 < thimm> | Makes organisation quite messy 00:27 * | thl has no RHEL5 at hand ATM 00:27 < quaid> | this is a bit unexpected thinking to me ... 00:27 < thimm> | quaid: It wouldn't make much sense, or not? 00:27 < quaid> | well 00:28 < quaid> | from a support perspective, sure, if you have Server and call about Eclipse on it ... 00:28 < quaid> | but does that mean there is no way to get the package? 00:28 < quaid> | I'm thinking about dep resoling in particular 00:28 < thl> | let's stop here 00:28 < thl> | and further investigate during the week 00:28 < quaid> | and not being to replace packages i nthe distro, etc. 00:28 < quaid> | ok 00:28 < thimm> | If the install number prohibit installtion of eclipse from the media they should also do so from the channels 00:28 < thl> | does that sound sane? 00:28 < nirik> | yeah, I think further investigation would be good. 00:29 < nirik> | I would really prefer to just have one repo per release of epel... otherwise it's getting very complex for maintainers. 00:29 < thl> | nirik, +1 00:29 < thl> | and for us, too 00:29 * | thl will move on soon if nobody yells 00:29 --- | thl has changed the topic to: EPEL SIG meeting -- http://fedoraproject.org/wiki/EPEL/Schedule -- http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates 00:30 < thl> | do we all agree on that this is the way forward? 00:30 * | nirik re-reads it again quickly 00:30 < thl> | not much changed in the past week 00:31 < thl> | actually, the changes since the initial posting were quite small in general 00:31 < thimm> | I disagree on kernel module policy 00:32 < thl> | thimm, suggestions please :) 00:32 < thl> | this was discussed on the list, wasn#t it? 00:32 < thl> | did you speak up there? (/me wonders if he missed that) 00:32 < thimm> | I did 00:32 < thimm> | And you replied 00:32 < thimm> | But I still disagree :) 00:32 < nirik> | kernel modules are a nice can of worms. I think we want to at least avoid them until everything else is up... 00:32 < thl> | nirik, +100 :) 00:33 < thimm> | Also: why rebuild packages? 00:33 < che> | from a usability point of view i like the dkms approach 00:33 < thl> | thimm, ? 00:33 < thimm> | From testing to stable transition 00:33 < thimm> | Doesn't that defeat any testing/QA done? 00:33 < thl> | thimm, that's not written there afaics 00:34 < thl> | the testing branch simply becomes the stable branch when the quarterly update happens 00:34 < thimm> | "go to a testing branch for a short time period and then build a second time for the stable branch" 00:34 < nirik> | yeah, shouldn't need to do that... since ABI/API should keep stable in minor releases of RHEL, right? 00:34 < thl> | thimm, that's something different 00:34 < thl> | that's more a: "updates-testing" meachnism 00:34 < thl> | and only for those rare cases where updates to stable are needed 00:34 < thimm> | Yes, and this should be rebuilt as well 00:35 < thimm> | Otherwise the "testing" part gets reset 00:35 < nirik> | isn't that more "there were problems in testing, so a new release was needed to fix them before pushing to stable" ? 00:35 < thimm> | That's different 00:35 < thimm> | If the package has a bug it needs to get fixed in testng 00:35 < nirik> | agreed. 00:35 < thl> | thimm, can you please outline your thoughts on the list 00:35 < thimm> | And when the bugs are off move the final testing package to stable 00:35 < thl> | I think that would be the better place 00:36 < thimm> | Well, these are no "thoughts", just general pratice 00:36 < thl> | thimm, don#t forget that packages in testing might get build agianst something else then the ones in stable 00:36 < nirik> | thimm: I agree, perhaps we need to clarify the document in that? 00:36 < thl> | stable=rh-latest 00:36 < thimm> | thl: that should not happen 00:37 < thl> | testing=rh-what-becomes-next-quarterly-update 00:37 < thl> | thimm, let's move this to the list 00:37 < thl> | it becomes to complicated here on IRC in my opinion 00:37 < thimm> | thl: There are two concepts mixes up then 00:37 < nirik> | The only time I would think that would happen is if there were several packages in epel that depended on each other and needed to be pushed at once. 00:37 < thimm> | You want "rawhide" and "updates-testing" in one repo 00:37 < thimm> | That won't wokr 00:38 < thimm> | For development we need to separate them, just like FC does 00:38 < thl> | development is fedora 00:38 < thimm> | security and major bugfxies go to the "updates-testing" 00:38 < thl> | security and major bugfxies go to the "updates-testing" +1 00:38 < thimm> | Any the prepeation for quarterly go to epel's "rawhide" 00:39 < thl> | no 00:39 * | thl stopps here, this doens't lead to anything 00:39 < thl> | lets move it to the list 00:39 < thimm> | Why? 00:39 < nirik> | security and major bugfixes go to "updates-testing" for a short time only and then get pushed to fix the security/major bug, right? 00:39 < thimm> | Yes 00:39 < thimm> | W/o rebuilding 00:39 < thimm> | Otherwise the QA gets lost 00:39 < nirik> | the minor updates/versions just keep sitting in updates-testing until the next minor 00:40 < thl> | I'd say with rebuilding 00:40 < thimm> | Yes, but that needs to be a separate repo 00:40 < nirik> | thimm: +1 to no rebuild. 00:40 < thl> | at leat if we build against rhel-what-becomes-update soon 00:40 < thimm> | E.g. one for quarterly long-term updates and one for near-term updates to the current minor 00:40 < nirik> | updates-testing and updates-nextrel ? 00:41 <-- | engwnbie has left #fedora-meeting ( "I'm Done") 00:41 < thl> | thimm, then we'd need to have 3 repos 00:41 * | thl thinks that's to much 00:41 < thimm> | Whch three? 00:41 < thl> | that will fail just as updates-testing fail 00:41 * | thl repeats: let's discuss it on the list 00:41 < thl> | we don#t understnad each other here 00:41 < thimm> | Let's talk in FC naming: 00:41 * | thl votes for moving on 00:42 < thl> | and reisiting this next week and on the list 00:42 < thl> | revisit 00:42 < thl> | stupid keyboard 00:42 < nirik> | so for each release, say RHEL5... there is a "5" repo with main packages, stable, pushed out. A 'updates-testing' thats usually empty, but sometimes has major security/bugfix packages, and a 'updates-nextrel' that has the packge updates for 5.1 waiting in it. 00:42 < nirik> | thl: ok. 00:43 < thimm> | nirik: something like that, yes 00:43 < thimm> | Where the two latter repo are consdiered our development repos 00:43 < thimm> | Not development as in == rawhide, but development as in where we do QA and shape packages for the next quarterly 00:43 < thimm> | Anyway, let's move on 00:44 --- | thl has changed the topic to: EPEL SIG meeting -- http://fedoraproject.org/wiki/EPEL/Schedule -- what else? 00:44 < nirik> | right. I think thats all doable, and mostly autopmagically so maintainers don't need to mess with it too much. 00:44 < thl> | anything else for today? 00:44 < thl> | repotag? 00:44 < thimm> | Voting body & fesco mandate? 00:44 < thl> | thimm, was discussed last week 00:44 --> | ChitleshGoorah (Chitlesh GOORAH) has joined #fedora-meeting 00:44 < thl> | but we can bring it up again 00:44 < thimm> | I'm sure it wasn't voted on ;) 00:45 < thimm> | repotag, fedr-ausrmgmt etc need a final voting somewhere 00:45 < thl> | sure, because we'd need to ask FESCo first how to set up a voting body 00:45 < nirik> | thimm: so what are you looking for? voting on tech issues where there is no consensus? 00:45 < thimm> | It's either the sig or fesco 00:45 < thl> | and the fest members around just said "try to continue without a oting body" 00:45 --> | lancelan (Lance Davis) has joined #fedora-meeting 00:45 < thimm> | thl: we need to suggest something and get iot ratified 00:45 < thl> | thimm, seems a lot of people disagreed last week 00:46 < thimm> | Last week? 00:46 < thl> | last meeting 00:46 < thimm> | On this irc? 00:46 < nirik> | I think repotag should fall under packaging... 00:46 < thl> | nirik, +1 00:46 < thimm> | Where less than half of the sig can participate? 00:46 < thl> | the summaries get send to the list 00:46 < thl> | so people can look at it 00:46 < thl> | and yell if they don#t like something 00:46 < thl> | nobody yelled 00:47 < thimm> | That's not to be deducted into everybody agrees 00:47 < quaid> | fwiw, we aren't near ready to be a formal project 00:47 < thl> | thimm, see https://www.redhat.com/archives/epel-devel-list/2007-March/msg00210.html 00:47 < quaid> | so it is SIG or nothing , afaict 00:47 < nirik> | I would much rather get to some tech consensus than brute force voting on issues where everyone gets unhappy in the end. 00:47 < thimm> | Well, every sig does have to make decisions, right? 00:47 < thl> | thimm, "some discussion about steering issues that got discussed on the list" 00:48 < thl> | nirik, +1 00:48 < quaid> | right, a SIG can vote, can't it? I mean, anyone can hjold a vote, unless they are somewhere they will get shot for doing it :/ 00:49 < thl> | quaid, well, yes, but who is allowed to vote 00:49 < thimm> | So the N people mentioned on the SIg list already form a voting body, is that what you're saying? 00:49 < thl> | that can quickly become confusing if people just join the sig just to be able to vote 00:49 < thl> | and how many votes does something need to get accepted 00:49 < thimm> | 50% 00:49 < thimm> | >50% 00:50 < thl> | to much 00:50 < thl> | that will deadlock soon 00:50 < thimm> | That's how voting works 00:50 < nirik> | so this is all for fedora-usermgmt banning? or ? 00:50 < thimm> | No, its for everything 00:50 < thl> | I'd say a group that decides about how epel moves forward should be 5 or 7 people 00:50 < thl> | not more 00:50 < thimm> | Then make a suggestion and have fesco ratify the list 00:50 < nirik> | well, what I mean is what "everything" do we need voting for now? aside from usermgmt? 00:51 < thimm> | repotag? 00:51 < thimm> | repo layout? 00:51 < thimm> | guidelines? 00:51 < thimm> | policies? 00:51 < thl> | thimm, we just do it the "if nobody yells it's okay" way currently 00:51 < thl> | and that was what FESCo members in the last meeting prefered 00:51 < thimm> | Which means 100% consensus or people are not paing attention 00:51 < thl> | and non-FESCo members, too afaics 00:51 < thl> | thimm, yes 00:51 < thimm> | That's not a healthy way of a project 00:52 < thl> | it worked so far 00:52 < thl> | sure, if we grow 00:52 < thimm> | It depends on the view I guess 00:52 < thl> | then we need a committee 00:52 < thimm> | so how do you deal with disagreement? 00:52 < thl> | we try to avoid it for now 00:53 < thimm> | Discuss until RHEL6? 00:53 < thl> | or move it to FESCo 00:53 < thimm> | Burry it under the carpet? 00:53 < thimm> | Oh fesco will be grateful for esalating any decision to them 00:53 < thimm> | For example repotag 00:53 < thimm> | I would agree that pushing it to FPc is the right thing to do 00:54 < nirik> | well, I would prefer to avoid the overhead, but if you want voting on issues, how about: anyone with a EPEL package can vote... voting to take place on a wiki page somewhere on each issue? 00:54 < thimm> | At least not w/o a preference form EPEL 00:54 < thl> | thimm, just out of interest, what's your opinion on repotag? 00:54 < thl> | nirik, that has other disadantages 00:54 < thl> | okay, I'll write something up for FESCo 00:54 < thimm> | I don't really care, I would like to see one, but I wopuld rather see it decided upon either way before it gets an infininte thread 00:54 < thl> | I'll of course send it to the list beforehand 00:55 < thimm> | thl: thanks! :) 00:55 < thl> | anything else? 00:55 < thimm> | Off the meeting: How do I import all my packages to EPEL? 00:55 * | thl will be afk soon anyway 00:56 < thimm> | (All but a few non-EPELizable) 00:56 < thimm> | Can someone here do a mass branching for me? 00:56 < thl> | thimm, I asked last week for people to write a script to simplyfy mass-branching in cvs 00:56 < thimm> | Who's doing the branches for EPEL, dgilmore? 00:56 < thl> | thimm, I'll do this script properly myself later as no one showed interest 00:57 < nirik> | might be best to generate a list and mail cvsadmins@fedoraproject.org? 00:57 < thl> | thimm, cvsadmins, that includes dgilmore 00:57 < thimm> | OK, I will try cvsadmins, thanks 00:57 < thl> | anything else? 00:57 * | thl will close the meeting in 30 00:58 < thimm> | bye all! 00:58 * | thl will close the meeting in 10 00:58 < thl> | -- MARK -- Meeting end
