21:03:03 #startmeeting 21:03:10 #meetingtopic EPEL 21:03:12 * SmootherFrOgZ is 21:03:16 #meetingname epel 21:03:23 #topic Init process 21:03:42 * stahnma made it :) 21:03:47 I am here 21:03:50 hurray 21:03:52 im kinda here 21:04:00 doing the migration to koji 21:04:10 yeah koji 21:04:11 * abadger1999 here 21:04:12 very nice 21:04:42 ok, shall we go ahead and get started? 21:04:48 yes please 21:04:51 good with me 21:05:08 #topic Policy about packages moving from EPEL to RHEL 21:05:46 so, this came up with the recent openjdk thing. 21:06:11 well, openjdk is really only the latest one 21:06:16 I believe there were others 21:06:20 I thought the policy was 'when it appears in rhel, it is removed from epel', but I guess it's unclear. 21:06:29 well, I think that's the policy 21:06:44 unless RH keeps a lower EVR 21:06:56 or they only publish some of the binary packages rather than all of them 21:07:45 well, that does open a can of worms. 21:08:14 openjdk has been removed from epel 21:08:39 or the RHEL doesn't have a 'needed' patch the EPEL one had for some reason 21:08:44 but the EVR in EPEL is higher than what's currently available in RHEL 21:09:16 once it goes into rhel, we should report bugs there if any, etc... we shouldn't try and carry our own package. 21:09:25 nirik: right 21:09:39 stahnma: right, so those people who installed from epel still have the epel version. ;( Only rhel can fix this. 21:09:54 bug has been filed 21:10:00 it should be fixed in 5.4 21:10:05 they know it and will be making sure the next update is higher 21:10:12 this gets back to needing better coordination. 21:10:18 agreed 21:10:41 ok, so do we need to adjust our policy here? or just strive to enforce it moving forward better? 21:10:46 at the beta we should check new packages and EVR 21:10:54 but I also think RH should be doing the same 21:12:01 at the beta we would need to do a tree check and then mark/push stuff that is obsoleted 21:12:25 but it only helps so much. 21:12:58 sometimes things come in as updates too... 21:13:02 well, wehn 5.4 beta hits (unless it already has) we should probably check 21:13:07 we sometimes can't know what rhel is going to be doing. 21:13:12 true 21:13:22 my guess is that the beta should be this fall/winter 21:13:53 my frustration is that why are we constraining ourselves to a 1 way relationship. 21:14:06 then I take a happy pill and go back to work 21:14:14 agreed 21:14:21 we need a bi-directional feedback process 21:14:30 agreed stahnma 21:14:32 but we need somebody close to releng for RHEL 21:14:35 * nirik nods. 21:14:48 and I really don't know who those people are 21:15:04 stahnma, I am not sure anyone knows who those people are :P 21:15:47 f13: Do you know who might fill that role? 21:15:58 It was suggested to mail notting and/or spot and inquire. 21:16:01 I am asking here as well 21:16:07 Perhaps someone could take that task? 21:16:21 I will 21:16:28 I will try to find out 21:16:55 spot is on vacation/travel til I think late June 21:17:24 notting might be a good choice.. or a desperate and forlorn plea on the rhel mailing list 21:17:37 #action stahnma will try and find someone to interface with on the RHEL side of things. 21:17:53 cool. Shall we move on? or anything else on this topic? 21:18:25 not that I can think of. stahnma if I can help I will definately do so. 21:18:39 ok 21:18:40 next 21:19:05 #topic Review Bug Day ideas 21:19:22 ok, so this is scheduled now... what do we want to try and accomplish? 21:19:23 As I mentioned in #epel earlier, I'd like to classify bugs 21:19:31 so we can work with them easier 21:19:54 we basically have requests for branch, requests for update and actual bugs 21:20:17 it's a fairly even divide as far as numbers go(at a glance) 21:20:32 stahnma, how else would the grouping go? 21:20:35 I think bug day goal could be to touch/triage every bug 21:20:46 well, we should be able to just process the branches and close those. 21:21:03 request for updates could be trickier if they need a lot of other things. 21:21:04 nirik: well the branch requests are not from the maintainers 21:21:09 stahnma, do we have a listing of every bug? 21:21:12 they are from end-users 21:21:17 http://tr.im/epelbugs 21:21:20 ah, so requests to package? 21:21:39 requests for the maintainer to branch their fedora package to EPEL 21:22:19 well, we can try and ping maintainers, branch and maintain with existing people, or the like 21:22:31 slipp3d_: not sure on groupings. Just trying to make a managable listing 21:22:53 I think if we have enough folks it should be possible to touch on all of them... 135 right now. 21:23:25 I've been trying to read through and triage some of them, or ask for updates 21:23:32 some are misfiled, and moved some 21:23:56 cool. 21:24:03 the bugzapper guys were very interested in helping, but we probably need clear goals 21:24:25 for the bugs we should be able to try and at least make sure there is sufficent info provided, etc. 21:24:45 true 21:24:57 I think I had a couple of requests for branches that got closed for some reason 21:25:23 I think we should come up with some expectations and documentation for people who want to help 21:25:44 yes that is a good plan. 21:25:59 expectations: bug is looked at and updated with any info from tester 21:26:09 requests for branches ? 21:26:14 I am not sure how to handle those 21:26:25 i would think that would be a good idea stahnma ... otherwise someone like me who is new would be over whelmed .. 21:27:03 well, ping maintainer and try and see if they want to maintain it. If not, come up with a list of them and ask on the epel-list for maintainers? 21:27:19 i'd like a way to classify them in bugzilla 21:27:26 so at a glance we can tell what we are working on 21:27:39 I am not that familiar with BZ, so I might need help there 21:27:40 we could use the whiteboard field. 21:27:48 you can put anything you like in there... 21:27:53 oh great 21:27:59 that should be perfect 21:28:14 can I report/sort on that field? 21:28:50 nirik, a couple of the ones were ones I was wanting to maintain.. but its been a long while since I looked at what they were. 21:29:05 yeah, I think you can query it ok 21:29:25 nirik, cool. I didn't know about the whiteboard field 21:29:55 anything else on this topic? 21:30:01 I'll try to classify bugs 21:30:18 not off hand 21:30:29 thanks stahnma 21:30:48 anything else? 21:30:55 not me 21:31:02 next up... 21:31:08 #topic FAQ updating (posting even) 21:31:31 I looked at hte FAQ (very quickly) and wondered if we should updat eit 21:31:40 whats the link? 21:32:28 yes we should update/rewrite it. 21:32:37 I don't remember :) 21:32:40 its been pretty static since EPEL just founded 21:32:56 looking 21:32:58 http://fedoraproject.org/wiki/EPEL/FAQ 21:33:02 yeah 21:33:04 that one 21:33:39 yeah, we should go over it and update it... 21:33:54 how best to do that? just do it in the wiki and discuss changes? 21:34:01 or mock up a new one and move it when we are happy with it? 21:34:15 I would say mock up a new one. 21:34:26 what are the top 10 questions we need to answer regularly. 21:34:27 I would think that a mock would be the better option 21:34:34 and then the rest 21:35:05 ok. I know quaid was interested in updating the wiki pages, perhaps he could lead this? ;) 21:35:31 repotags 21:35:32 updating policy 21:35:32 how often we push 21:35:39 replacing core 21:36:04 compatibility with downstreams ELs 21:36:20 mixing repos 21:36:42 how we handle stuff thats in EL on one arch but not another 21:37:05 section for maintainers would be good... 21:38:08 so, who wants to lead this? or should we ask for help on the list? 21:39:34 nirik, when do we want a first stage mockup? next week/week after? I can do it for week-after... next-week would be pushing it. 21:39:49 I don't think it's urgent... just needs to get done sometime. 21:40:07 ok I will lead. put my deadline for 2 weeks 21:40:24 cool. thanks. 21:40:34 also I was wondering.. do we want a trac instance etc? 21:40:35 #action smooge will mock up a replacement/updated FAQ page for us. 21:40:51 well, for tag requests and such we can just use the existing rel-eng one. 21:41:07 not sure what else we need one for, but if there is a good reason we can request one. 21:42:12 ok, anything else on faq? 21:42:19 duh... I remember this being put in last meeting for using the rel-eng one.. sorry 21:42:34 no I will have a mockup on list soon 21:42:41 excellent. thanks. 21:42:45 #topic Stable Push & Koji/Bodhi progress report 21:42:51 dgilmore: you around? how do things look? 21:42:59 and thanks for working on it! 21:43:00 nirik: push done 21:43:06 im syncing it now 21:43:15 then ill import rpms into koji 21:43:50 cool. :) How does the bodhi stuff look? or we will see when we try and use it? 21:44:02 we will see when we try 21:44:10 lmacken is looking over the patches 21:44:26 most of it is config 21:44:27 * smooge makes sure to keep babies away from bodhi when you try. 21:44:34 excellent. I'm happy to try pushes or anything whenever needed. 21:45:00 ok, so thats all I had on the agenda. 21:45:05 #topic Open Floor 21:45:12 any other items? 21:45:19 I'd also like training on the pushes using the newer systems. 21:45:36 I was wanting to gather some metrics on EPEL 21:46:09 id like to keep the people who know the passphrase for the epel key small 21:46:09 no the main things I was wondering was how we might be able to use Fedora Community for ourselves 21:46:09 Policy on when pushes will be performed? 21:46:17 basically, are we losing contributors in EPEL? 21:46:22 yeah, we should do them more often... weekly? daily for testing? 21:46:27 * smooge realizes that made no sense. 21:46:28 also, why are certain fedora maintianers not interested in EPEL? 21:46:59 testing daily +1 21:47:01 I have an off-the wall idea I would like to propose 21:47:04 also, what are the primary reasons for people not using EPEL and using repo_x? 21:47:06 stahnma: the two reasons I think I hear most are: 1) involved in another rhel addon repo, or 2) have no time/interest in rhel, only use fedora. 21:47:19 nirik, agreed 21:47:55 stahnma, the reasons for choosing which repo are almost the same as choosing KDE vs GNOME vs LXDE 21:48:01 abadger1999: I'm fine just adding them to my daily schedule once we have all the push procedures down. I think weekly might be better for stable tho, so people know when to expect them to appear. Or even bi-weekly. 21:48:31 ... the only thing there is that testing (at least in Fedora) doesn't go to the buildroot. 21:48:36 my proposal is to change the name of the repos location from stable to 'current'. 21:49:15 abadger1999: yeah, we should do the same for epel I think. 21:49:32 I would like to see how 'current', 'next-week', 'next-month' would look 21:49:46 * nirik shrugs. Thats fine if you think 'stable' is too much of a promise I guess. 21:49:54 more repos==more pain. 21:50:20 nirik I think it is too much of a promise especially when we aren't really testing stability to the level we once hoped for. 21:50:54 well actually next-week/next-month are more like staging/testing. but I can understand having too many repos 21:51:13 actually staging/testing would be a better name 21:51:24 well, we only call it 'stable' in docs right, there is no 'stable' directory. 21:51:44 .... has been believing the docs too much 21:52:16 it's just 'testing' and then the 5 or 4 repo. 21:52:17 stahnma, what kind of statistics did you want to look for and how would we measure them? Mirror maanger 21:52:35 nirik, ok so it would be more of a change in documentation. 21:52:45 I'm out. 21:52:46 thanks 21:52:48 yeah, I think so. I agree we shouldn't promise 'stable' 21:52:58 thanks for coming stahnma 21:53:32 so, everyone ok with trying for daily pushes to testing and weekly (tuesday?) pushes to stable? 21:53:49 thanks stahnma 21:53:50 thanks 21:54:00 nirik +1 21:54:26 maybe we can shield ourselves from black tuesday 21:54:54 nirik: +1 21:55:24 well, I think it's good to have a known day when they show up. Friday is bad as people might head out for the weekend and they appear... monday's are kinda hectic... 21:55:32 I guess wed or thursday would be fine too, IMHO. 21:57:20 ok, anything else? or shall we close out the meeting? 21:57:38 I actually like Tuesday 21:57:51 Microsoft picked it for similar reasons. 21:58:12 I am ok with closing. 21:58:34 ok, will close in 60sec if nothing else appears. 21:59:34 #endmeeting