================================== #fedora-meeting: EPEL (2011-01-03) ==================================
Meeting started by nirik at 20:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-01-03/epel.2011-01-03-20.30.log.html Meeting summary --------------- * init process/agenda (nirik, 20:30:02) * EPEL provenpackagers (nirik, 20:35:41) * will discuss ideas on the list and revisit. (nirik, 20:56:39) * What can be in EPEL6? (nirik, 20:56:50) * AGREED: "EPEL6 will not ship any packages that have src.rpms on public mirrors under 6* directories with the following exception: If the binary rpm is only shipped in some arches in RHEL, EPEL may ship a package as close as possible to the RHEL version with a leading package Release of 0. (ie, libfoo-1.2-0.x) (note that EPEL maintainer must keep up exactly with the RHEL src.rpm where possible). (nirik, 21:08:14) * Broken EPEL6 deps (nirik, 21:08:26) * AGREED: please fix your broken deps or untag until you can. (nirik, 21:14:54) * EPEL6 moving out of beta 2011-01-11 (nirik, 21:15:05) * folks would still like more time, so 2011-01-11 doesn't seem likely at this point. (nirik, 21:28:05) * nirik will try and mail out a list of packages and versions in epel6 now with maintainer (nirik, 21:29:28) * Open floor (nirik, 21:31:24) Meeting ended at 21:35:23 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (113) * dgilmore (59) * stahnma (39) * sgallagh (25) * abadger1999 (21) * rsc (21) * Jeff_S (4) * zodbot (3) * smooge (2) * hicham (1) -- 20:30:01 <nirik> #startmeeting EPEL (2011-01-03) 20:30:01 <zodbot> Meeting started Mon Jan 3 20:30:01 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:30:02 <nirik> #meetingname epel 20:30:02 <zodbot> The meeting name has been set to 'epel' 20:30:02 <nirik> #topic init process/agenda 20:30:40 <nirik> smooge / abadger1999 / dgilmore / stahnma / tremble / rsc (any others interested in epel meeting) 20:31:12 * dgilmore is here 20:31:17 * rsc is also around 20:31:34 <nirik> anayone have agenda items? 20:31:37 * stahnma is here 20:31:43 * sgallagh lurks, as usual 20:31:49 <nirik> * EPEL6 moving out of beta 2011-01-11 20:32:02 <nirik> * What can be in EPEL6 20:32:12 <nirik> any other agenda items? 20:32:21 <stahnma> Dealing with broken deps in epel6 20:32:44 <sgallagh> I've suggested it before, but can we get a separate provenpackager status for EPEL? 20:33:02 <sgallagh> (Separate from Fedora, I mean) 20:33:07 <dgilmore> sgallagh: why? 20:33:17 <smooge> sorry late for everything today 20:33:18 <rsc> sgallagh: sounds interesting, but why? 20:33:20 <dgilmore> Id think anyone trusted for one woul d be trusted for the other 20:33:46 <sgallagh> dgilmore: Not necessarily. EPEL is supposed to be much stricter about updates, for example 20:34:08 <dgilmore> sgallagh: prvovenpackager has nothing to do with that 20:34:09 <smooge> supposed to be 20:34:19 <rsc> nirik: will CentOS 6 be ready till 2011-01-11? 20:34:24 <nirik> rsc: no idea. 20:34:28 <stahnma> I would be in favor of that 20:34:29 <sgallagh> Also, I for one would not want that responsibility in Fedora, but I'd be okay with it in EPEL (since it's a slower-pace) 20:34:40 <nirik> ok, so I have: 20:34:41 * abadger1999 here 20:34:42 <dgilmore> sgallagh: implementing a second provenpackager status greatly complicates the git acls also 20:34:59 <nirik> EPEL provenpackager 20:34:59 <nirik> What can be in EPEL6 20:34:59 <nirik> Broken EPEL6 deps 20:34:59 <nirik> EPEL6 moving out of beta 2011-01-11 20:35:12 <nirik> any other topics/agenda items before we start/ 20:35:13 <nirik> ? 20:35:23 <dgilmore> nirik: not that i can think of 20:35:29 <stahnma> sounds reasonable for today 20:35:41 <nirik> #topic EPEL provenpackagers 20:35:59 <nirik> so yeah, this could make things complex with the acls... 20:36:15 <dgilmore> the acl file is already massive 20:36:26 <dgilmore> this would add greatly to it 20:36:56 <rsc> I think a provenpackager is a knowledged packager, so �ckager as previously called. A provenpackager should be aware how to handle EPEL. Otherwise he shouldn't be a provenpackager 20:37:00 <dgilmore> since im assuming fedora provenpackager means your not an epel provenpackager 20:37:01 <nirik> I think also when asking to be a provenpackager, noting that you want to use your powers for epel might sway votes. 20:37:03 <dgilmore> and vice versa 20:37:07 <stahnma> maybe we should discuss the process behind the idea rather than the implementation specifics first 20:37:27 <nirik> I know that tremble was granted provenpackager after working on stuff in epel. 20:37:32 <stahnma> I also was 20:37:35 <dgilmore> rsc: i agree with you 20:38:05 <rsc> and if somebody heavily violates, he should be removed from provenpackager simply. 20:38:06 * dgilmore wants to know what we gain by having it seperate? 20:38:28 <sgallagh> dgilmore: Well, my main concern is this: those working on EPEL are a very small subset of the general Fedora community 20:39:00 <dgilmore> sgallagh: being small doesnt mean much 20:39:02 <sgallagh> Especially during beta periods, there are a lot of broken dependency issues that can be solved with more provenpackager access 20:39:21 <sgallagh> Rather than the time-consuming process of acquiring comaintainership on every package 20:39:29 <dgilmore> sgallagh: sure 20:39:30 <hicham> because not all community members have access to it 20:39:31 <nirik> perhaps we should look at having a policy that allows us to add people as comaintainers more easily. 20:39:38 <stahnma> I spend 90% of my time in EPEL. Me having rights to mess with Fedora might not be the best idea, but I chose not to mess with Fedora packages for the most part 20:39:53 <sgallagh> So I think it should be easier to get provenpackager status on EPEL but not necessarily grant that same power over Fedora as a whole 20:39:57 <dgilmore> but i dont see anyof this precluding having general provenpackager access 20:40:54 <dgilmore> sgallagh: easier access and 20:33 < sgallagh> dgilmore: Not necessarily. EPEL is supposed to be much stricter about updates, for example 20:40:59 <dgilmore> contradict 20:41:12 <stahnma> I can sgallagh's point. Many people don't fix issues with things in EPEL. 20:41:15 <sgallagh> Yes, I know it's a contradiction 20:41:17 <dgilmore> there is no reason that because you have provenpackager access you have to do anything in fedora 20:41:20 <stahnma> If a few more people had access to fix them, it would help overall 20:41:32 <stahnma> regardless of if they have it in Fedora proper or not 20:41:45 <sgallagh> I'm trying to put my thoughts into words, and my thoughts are still on holiday :) 20:42:03 <dgilmore> sgallagh: :) i get what your saying 20:42:13 <dgilmore> i just dont know that it gets us anything 20:42:15 <sgallagh> dgilmore: If we have two separate sets of standards for how a provenpackager is supposed to behave, shouldn't they be two separate groups? 20:42:38 <nirik> one problem is that if provenpackages wander around and just fix deps, we don't realize that we have packages that are not being maintained. 20:42:44 <dgilmore> sgallagh: why dont we have seperate epel-packager then 20:42:52 <nirik> so, getting co-maintainers is much better than provenpackagers usually. 20:42:57 <nirik> IMHO 20:42:57 <dgilmore> we expect packagers to behave differently in epel to fedora 20:43:24 <dgilmore> nirik: right thats the other side of the coin 20:43:30 <sgallagh> nirik: That's a good point. But as I mentioned, our comaintainership process is pretty tricky to navigate 20:43:44 <sgallagh> If the primary maintainer is non-responsive, that process is very slow 20:43:49 <rsc> if we start with epel-packager vs. fedora-packager, we need epel-packager-sponsor vs. fedora-packager-sponsor... ;-) 20:43:54 <nirik> yeah. So, perhaps we could make it easier in epel. 20:44:12 <rsc> nirik: you're thinking about shortening AWOL in EPEL? 20:44:24 <nirik> I'd love to see most/all/more packages with co-maintainers in epel. 20:44:51 <nirik> well, shortening what it takes to add someone as a co-maintainer. 20:45:37 <nirik> I'm not sure I have a concrete thing to vote on now, just a thought. 20:46:30 <dgilmore> nirik: perhaps we could have something autoapprove co-maintainer requests after 3-5 days if the maintainer hasnt acted on it 20:46:44 <sgallagh> nirik: Might I propose that we change co-maintainership from an approval process to an auto-grant process (where the primary owner can revoke it if necessary)? 20:46:53 <sgallagh> dgilmore: You read my mind :) 20:47:07 <nirik> or have a process for requesting them/discussing at meetings? 20:47:23 <rsc> no auto-grant, but some delay before auto-grant if primary is not opting out 20:47:44 <rsc> I dislike auto-grant because we also have people that simply add themself as comaintainers without having a clue about the package :( 20:47:54 <dgilmore> nirik: id rather not have discussions on each and everyone 20:47:57 <nirik> I'd be a bit afraid of going to fast... you might get someone who is overeager, gets commit, and pushes a incompatible update before the maintainer can see them and ask them not to. 20:48:03 <dgilmore> only have discussions in the case of conflict 20:48:19 <rsc> nirik: I agree with you 20:48:33 <sgallagh> nirik: Well, we still have a minimum time in epel-testing in effect 20:48:33 <nirik> so, it's all a balancing act. 20:48:39 <nirik> true. 20:48:39 <sgallagh> That should catch most issues like that 20:48:40 <rsc> maintainer and co-maintainer should work hand in hand... 20:49:26 <nirik> agreed. 20:49:37 <dgilmore> cd 20:49:54 <nirik> So, not sure what we can do here. Does anyone feel strongly on any of the proposed ideas? Or perhaps we discuss on list and revisit? 20:50:34 <sgallagh> I'd back dgilmore's auto-approval proposal if it came to a vote 20:51:05 * dgilmore is not sure what it would take to implement 20:51:08 <nirik> that would likely require changes to pkgdb... not sure how feasable that would be 20:51:10 <nirik> abadger1999: ? 20:51:29 * abadger1999 figures out the parameters of dgilmore's proposal 20:52:00 <dgilmore> abadger1999: have somthing go though and auto approve comaintainer requests after 3-5 days 20:52:00 <abadger1999> Okay so it wouldn't be a major overhaul of the system but it would take work 20:52:17 <dgilmore> i guess it could be scripted as a cron job 20:52:26 <abadger1999> I think the parts are: store in the pkgdb when an acl is changed to request comaint. 20:52:31 <dgilmore> it would depend on pkgdb exposing when the request was made 20:53:10 <abadger1999> Write a cron job/scheduled task that scans forr acls with status "Awaiting" that are more than X days old 20:53:20 <abadger1999> And changes them to Approved. 20:53:45 <abadger1999> Oh -- and make that differ between Fedora EPEL and Fedora... but I think you could do that as part of the cron task 20:53:58 <abadger1999> So... Who likes this enough to write code? 20:54:16 * nirik doesn't feel too strongly on it. 20:54:22 * dgilmore doesnt either 20:54:29 <dgilmore> was just offering it as an option 20:54:34 <abadger1999> I don't see anything that would make me reject the feature... just don't have the time to implement 20:54:40 <dgilmore> anyway its something to ponder 20:54:41 <sgallagh> abadger1999: In what language is pkgdb written? 20:54:45 <stahnma> I think you summed up all of epel 20:54:51 <dgilmore> sgallagh: python 20:54:51 <nirik> Another idea is that we could auto allow co-maintainer on any packages that have not yet been bult for epel6. 20:54:55 <abadger1999> sgallagh: python -- TurboGears1 at the moment 20:55:08 <nirik> ie, if the maintainer didn't build so far, they likely don't care or are missing anyhow. 20:55:30 <stahnma> or are waiting for deps 20:55:36 <stahnma> or versions to be worked out 20:56:14 <nirik> yeah, I suppose so. 20:56:27 <sgallagh> I suggest we take this to the list and stop burning up our meeting time on it. We have other agenda items to look at too. 20:56:29 <nirik> so, lets discuss more on list and revisit next week then? 20:56:39 <nirik> #info will discuss ideas on the list and revisit. 20:56:50 <nirik> #topic What can be in EPEL6? 20:56:58 <nirik> I posted a proposal to the list a while back. 20:57:22 <nirik> Subject: Proposal on what packages can be in EPEL6 20:57:50 <stahnma> nirik: it was quite confusing to me, even with the explanations, but I don't think that's your fault 20:58:02 <nirik> yeah, rhel6 is confusing. ;) 20:58:41 <nirik> so I guess I came down with: 20:59:09 <nirik> "EPEL6 will not ship any packages that have src.rpms on public mirrors under 6* directories with the following exception: If the binary rpm is only shipped in some arches in RHEL, EPEL may ship that exact same version (note that EPEL maintainer must keep up exactly with the RHEL src.rpm). 20:59:25 <nirik> of course there are problems with that too. 20:59:39 <nirik> java being the biggest corner 20:59:40 <dgilmore> nirik: that im ok with 20:59:55 <sgallagh> What about packages with a dep in Workstation vs. Server? 21:00:25 <dgilmore> sgallagh: AFAIK workstation + optional and server+optional should be the same content 21:00:30 <dgilmore> but i could be wrong 21:00:35 <nirik> other problem: what if rhel shipps libfoobar for one arch. So, we add it to epel and build it for all arches, but it needs patches/fixes/different version to work on the other arches? 21:00:37 <sgallagh> I'm pretty sure you're wrong :( 21:01:26 <nirik> sgallagh: well, we had in beta time some packages that were only in workstation-optional or the like that were needed, but as far as I know all of them are in serveral optional now. 21:01:37 <dgilmore> nirik: as long as we keep it older we should be ok 21:01:37 <sgallagh> ah ok 21:01:53 <dgilmore> we can say anything in rhel have to have a release that starts with 0. 21:02:04 <nirik> dgilmore: so, should we always keep such things older? 21:02:14 <dgilmore> nirik: right 21:02:15 <nirik> that seems reasonable to me. 21:02:50 <dgilmore> abadger1999: would the fpc be ok with that ? 21:02:55 <nirik> "EPEL6 will not ship any packages that have src.rpms on public mirrors under 6* directories with the following exception: If the binary rpm is only shipped in some arches in RHEL, EPEL may ship a package as close as possible to the RHEL version with a package version of 0. (note that EPEL maintainer must keep up exactly with the RHEL src.rpm where possible). 21:03:08 <dgilmore> though i guess an epel only packging guideline doesnt need to go though fpc 21:04:10 <abadger1999> dgilmore: fpc let's epel define things beyond the standard guidelines and I think the 0. release would be fine. 21:04:17 <sgallagh> Seems sensible to me 21:04:28 <nirik> anyone have wording changes or other changes to the above? 21:04:45 <rsc> nirik: the working above means -0.*, right? 21:04:46 <abadger1999> Just be sure you word it so that people know that Release: 0.1.snap in RHEL means in EPEL it needs: Release: 0.0.1.snap 21:04:58 <nirik> rsc: yeah. 21:05:17 <rsc> nirik, abadger1999: Please add some examples - especially one like from abadger1999 around the wording 21:05:46 <nirik> "EPEL6 will not ship any packages that have src.rpms on public mirrors under 6* directories with the following exception: If the binary rpm is only shipped in some arches in RHEL, EPEL may ship a package as close as possible to the RHEL version with a leading package Release of 0. (ie, libfoo-1.2-0.x) (note that EPEL maintainer must keep up exactly with the RHEL src.rpm where possible). 21:05:59 <nirik> rsc: yeah. 21:06:29 <nirik> we may already have packages in that would need to do this. 21:06:45 <nirik> I think tremble had a script to find them. 21:07:13 <nirik> ok, so the above sounds ok? 21:07:18 <stahnma> +1 21:07:24 <rsc> +1 21:08:14 <nirik> #agreed "EPEL6 will not ship any packages that have src.rpms on public mirrors under 6* directories with the following exception: If the binary rpm is only shipped in some arches in RHEL, EPEL may ship a package as close as possible to the RHEL version with a leading package Release of 0. (ie, libfoo-1.2-0.x) (note that EPEL maintainer must keep up exactly with the RHEL src.rpm where possible). 21:08:26 <nirik> #topic Broken EPEL6 deps 21:08:34 <nirik> so, we still have a fair number of broken deps. 21:08:42 * dgilmore just fixed up the koji one 21:08:47 <rsc> yeah, heartbeat is missing! ;-) 21:08:52 <nirik> should we look at untagging things that are broken? or let maintainers have more time? 21:08:59 * stahnma has some ruby cleaning/work to do 21:09:03 <nirik> rsc: given the above, I think I can build hb now. ;) 21:09:16 <rsc> nirik: then please give some more time before untagging 21:09:23 <dgilmore> rsc: we dont have the cluster stuff available to the buildroot. dep checker 21:09:38 <nirik> dgilmore: given the above, we could ship it in epel... 21:10:03 <dgilmore> nirik: yeah or we add the channel to the buildroot 21:10:16 <dgilmore> nirik: if the srpms are public we should add the channel 21:10:19 <nirik> but there are no mirrored srpms for it. 21:10:19 <rsc> dgilmore: how about CentOS users? 21:10:21 <nirik> they are not. 21:10:38 <dgilmore> nirik: oh ok well then i guess we can ship it 21:10:40 <nirik> rhel5 had srpms from the various other AP channels. 21:10:46 <nirik> rhel6 doesn't as far as I can see. 21:11:36 <dgilmore> nirik:they might all be dumped in one place 21:11:55 * Jeff_S checks in late for the meeting 21:12:01 <nirik> dgilmore: is there any way we could find out? 21:12:36 <nirik> pacemaker src.rpm is in server-optional, but that might be due to it's -docs and -cts subpackages being shipped there. 21:13:14 <dgilmore> nirik: yeah 21:13:41 <nirik> if they are putting the HA and Cluster and other src.rpms in optional, that will be even more confusing to us. ;) 21:13:58 <nirik> so, give another week, revisit then, urge maintainers to fix things? 21:14:26 <stahnma> maintainers should probably start fixing now 21:14:27 <stahnma> :) 21:14:54 <nirik> #agreed please fix your broken deps or untag until you can. 21:15:05 <nirik> #topic EPEL6 moving out of beta 2011-01-11 21:15:14 <nirik> So, we thought this might be a good date a while back. 21:15:23 <nirik> do we stil? what do we need to do before then? 21:15:31 <nirik> * no broken deps 21:15:39 <nirik> * press release/announcements 21:15:44 <nirik> * add to bodhi 21:15:45 <stahnma> more packages 21:16:21 <stahnma> we're short on lots of stuff from what I can tell. Perl/ruby at least. I don't use a ton of python or php so I'm not sure on that 21:16:52 <stahnma> and many of us still lack a test area to ensure packages are working properly 21:17:02 <nirik> yeah. 21:17:23 <stahnma> the number one complaint I get about epel5 is lack of packages 21:17:25 <rsc> all my packages except three or so are in EPEL 6... :) 21:17:28 <stahnma> and 6 has less than 5 currently 21:18:09 <nirik> well, we need maintainers willing to step up to maintain. ;) 21:18:25 <stahnma> yes we do 21:18:39 <stahnma> it's a never ending battle for me 21:18:56 <Jeff_S> centos release of 6 should help a lot for getting more 6 packagers 21:19:03 <nirik> yeah, it could... 21:19:20 <stahnma> it doesn't help with new packages coming into Fedora and the maintainer not branching for epel 21:19:27 <nirik> does everyone still want to target 2011-01-11? 21:19:28 <Jeff_S> :( 21:19:32 <stahnma> or asking if anybody would be willing to do an epel branch 21:19:45 <stahnma> I run into that a bunch 21:19:52 <rsc> nirik: I'm also happy if we delay a bit, because CentOS 6 is also not there so far... 21:20:11 <stahnma> I too would rather wait for CentOS 21:20:45 <rsc> nirik: to be honest...all my package builds for EPEL 6 are assumed to work...not more. I don't have RHEL 6... 21:20:55 <Jeff_S> same here 21:20:59 <nirik> well, I have been using rhel6b2 to test... 21:21:19 * abadger1999 is okay with epel6 being small... We can build it up as we go along 21:21:31 <abadger1999> I'd rather be short packages than to have obsolete packages 21:21:38 <abadger1999> when we first release 21:21:51 <nirik> yeah. 21:22:41 <stahnma> either way it hurts the epel brand. If we don't have many packages or if we're late 21:22:44 <nirik> so do people have big changes they are still waiting to land until centos? 21:22:56 <stahnma> nirik: I have much ruby sorting to do. 21:23:04 <stahnma> about 100 packages 21:23:23 <nirik> and those are things that would change if you had a centos? 21:23:32 <stahnma> I could test some of it a little more 21:23:57 <stahnma> we're also waiting for rails3 to hit rawhide, in some respects. I just don't think I have the man-power/time to maintain two whole stacks of ruby stuff 21:23:58 <nirik> as a reminder, going out of beta doesn't mean everything stops... it just means we go to our normal 2 weeks of testing, buildroot overrides, etc. 21:24:16 <nirik> sure, but you can land that when it happens right? 21:24:28 <stahnma> yeah but until then most of the ruby stack will be absent 21:24:46 <stahnma> or will have incompatible upgrades 21:25:02 <nirik> right, but if we wait for everything we would never go out of beta. 21:25:04 * abadger1999 has TG-1.1.1 so not too bad. 21:25:21 <abadger1999> What I'd really love is a listing of all the packages that I nominally own that are in EPEL-6 right now. 21:25:48 <nirik> and their versions? 21:25:48 <abadger1999> Then I could check those and see if there's any I think need to get an incompatible update before the deadline. 21:25:52 <abadger1999> yeah. 21:26:07 <nirik> yeah, such a report would be great. ;) 21:26:49 <nirik> so, sounds like people are weak on 2011-01-11 now... 21:27:02 <nirik> would anyone be willing to do such a report and mail it to the list? 21:27:44 * nirik listens to the chirping. ;) 21:28:05 <nirik> #info folks would still like more time, so 2011-01-11 doesn't seem likely at this point. 21:28:09 <stahnma> I'd volunteer, but then not get it done and be a disappointment to myself and everybody around me 21:28:28 <stahnma> can we get epel interns? 21:28:33 <nirik> I guess I could try and whip up something. 21:29:12 <dgilmore> nirik: ill be flying to australia on jan 11 21:29:28 <nirik> #info nirik will try and mail out a list of packages and versions in epel6 now with maintainer 21:29:47 <nirik> dgilmore: cool. How long will you be out there? 21:29:55 <dgilmore> nirik: jan 28 21:30:01 <dgilmore> coming back for fudcon 21:30:11 <dgilmore> its all work 21:30:22 <dgilmore> ill be working from the brisbane office while there 21:30:32 <dgilmore> except for when lca is on 21:30:59 <abadger1999> nirik: I'll try and whip up something but If I can't finish it I'll hand what I have done off to you tomorrow. 21:31:12 <nirik> dgilmore: ok. 21:31:12 <rsc> stahnma: isn't Ruby on Rails dead? :) 21:31:13 <abadger1999> So i'm not a bottleneck 21:31:16 <nirik> abadger1999: ok. 21:31:24 <nirik> #topic Open floor 21:31:30 <nirik> anyone have open floor items? 21:32:04 <nirik> ah bummer. I was thinking I might be able to just use koji tag history, but a bunch of epel6 stuff was tagged in by nobody when it was setup in koji. Oh well. 21:32:57 <dgilmore> nirik: everything in epel-6 was built in koji 21:33:04 <dgilmore> and tagged at build 21:33:20 <nirik> dgilmore: why are some things showing as tagged in by nobody? 21:33:28 <stahnma> rsc: ? 21:33:35 <nirik> anyhow, we can continue this over on #epel... 21:33:40 <nirik> anything else before we close out the meeting? 21:35:12 <nirik> thanks for coming everyone. 21:35:13 * dgilmore has nothing 21:35:23 <nirik> #endmeeting
signature.asc
Description: PGP signature
_______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
