Reminder: next meeting on Wednesday (20070919) at 23:00 UTC in #fedora-meeting
00:00:56 <knurd> Hi everybody; who's around? 00:01:07 --- knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:01:11 <knurd> Meeting ping dgilmore, Jeff_S, knurd, mmcgrath, nirik, stahnma, quaid and everyone interested in EPEL -- EPEL meeting in #fedora-meeting now! 00:01:17 * knurd likes to remind people that the schedule and the topic list for todays meeting can be found on http://fedoraproject.org/wiki/EPEL/Schedule 00:01:30 * f13 peeks in 00:01:45 * knurd has a cold and should be in bed... 00:02:11 <dgilmore> knurd: pushing should be easier now 00:02:27 <knurd> dgilmore, yeah, I've read about it in my inbox 00:02:38 <knurd> dgilmore, does it work like Michael expected it now? 00:02:52 <dgilmore> knurd: it seems to yes 00:03:03 <knurd> dgilmore, great 00:03:30 <knurd> dgilmore, btw, the current repo is "5" 00:03:47 <knurd> the plan was to have "5.0" and "5.1" repos and let 5 point to the current one 00:03:54 <knurd> dgilmore, should that still be possible to do? 00:04:16 <knurd> having "5.0" and "5.1" repos would make it possible for users to stick to 5.0 00:04:25 <knurd> if they don#t want to upgreade yet to 5.1 00:04:27 --> sharkcz () has joined #fedora-meeting 00:04:41 <f13> given that Red Hat has an update model that is like that, this is probably a good idea. 00:04:55 <dgilmore> knurd: they should be symlinks to 5 00:04:58 <knurd> btw, I supose there is no public official date when RHEl 5.1 is going to be released? 00:04:58 <f13> Red Hat has an update model that will allow you to stay on say 5.0 and get only critical updates built for 5.0. 00:05:06 <f13> knurd: I don't think so 00:05:26 --> trashy (n=trashy@fedora/trashy) has joined #fedora-meeting 00:05:33 <knurd> dgilmore, no, that does not work if there is something in the normal repo then that requires stuff from 5.1 00:05:39 <knurd> so we need 5.0 and 5.1 repos 00:05:47 <dgilmore> knurd: we can not do that 00:05:49 <knurd> and just link from 5 -> latest (e.g. 5.1 soon) 00:05:58 <knurd> dgilmore, why not? 00:06:01 <dgilmore> we do not have the resources to offer something like that 00:06:20 <knurd> resources as in "hard-disk space"? 00:06:27 <knurd> it's just for some months 00:06:31 <knurd> we could hardlink the files 00:06:42 <knurd> and remove the 5.0 directory when RHEL drops 5.0 completely 00:06:50 <dgilmore> as in hard disk space and scripst that hardlink and set multiple repositories 00:06:57 <f13> you'd need multiple scm branches too 00:07:03 <f13> one for each point release. 00:07:04 * nirik is here now finally. 00:07:05 <warren> RH ourselves builds something on 5.0 if it is meant for both 5.0 and 5.1 00:07:13 <knurd> f13, well, I don#t think we need to update the old branches 00:07:18 <knurd> f13, that is to much work for epel 00:07:23 <f13> knurd: you do if htere is a security issue 00:07:35 <dgilmore> knurd: it will blow up the world we dont have resouces to do such a thing 00:07:56 * mmcgrath tends to agree with dgilmore. 00:08:02 <knurd> dgilmore, it's in the guidelines 00:08:03 <knurd> for motnhs 00:08:07 <nirik> centos doesn't do that either, do they? 00:08:12 <knurd> why didn#t you speak up once about it 00:08:12 <mmcgrath> nirik: they don't. 00:08:28 <knurd> nirik, they have different directories for their releases as well 00:08:40 <dgilmore> knurd: I had assumed we would keep a single tree and create symlinks for releases 00:08:58 * quaid is here, had to come back from an unexpected reboot 00:08:59 <knurd> dgilmore, http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-a98bce5283ee33... 00:09:05 <knurd> nirik, mmcgrath read that as well 00:09:07 <nirik> they only build against the current tho I thought and the others were symlinks to the current 00:09:16 <knurd> that's why we agreed on months ago 00:09:35 <dgilmore> nirik: thats my take on it also 00:09:47 * nirik reads 00:09:51 --- knurd has changed the topic to: EPEL Meeting | RHEL / EPEL 5.1 -- unassigned 00:09:55 <mmcgrath> knurd: they keep the old trees around but they don't have anything in them. 00:09:58 <mmcgrath> http://mirror.steadfast.net/centos/4.4/readme 00:00:02 <nirik> yeah, that was my understanding too. ;( Sorry if I misread/misunderstood the written guideline... 00:00:05 <knurd> I thought they keept the old tree around for some weeks/months 00:00:21 <dgilmore> anyways it is not really my problem since i am no longer part of the EPEL SIG 00:00:23 <knurd> so users that don#t want to update yet don#t run into issues 00:00:29 <mmcgrath> knurd: the problem here is that someone (and its going to have to be a person) will need to track the trees if some packages have a different destination at different times. 00:00:43 <knurd> dgilmore, well, I wanted you opinion in general 00:00:48 <mmcgrath> they'll need to make decisions on what rpms end up where and when. 00:12:05 <knurd> mmcgrath, we would just keep the 5.0 tree around for some months 00:12:11 <knurd> no updates anymore 00:12:13 <mmcgrath> for what purpose? 00:12:21 <knurd> for users that are not yet on 5.1 00:12:27 <knurd> or don#t want to go there yet 00:12:47 <knurd> for example as yum-utils is iirc in 5.1 00:13:02 <knurd> we are oing to delete it in epel soon (I suppose) 00:13:08 <nirik> but they could just use the symlinked 5.1 repo. If there was some dependency that was in 5.1 and not 5.0 it would error or pull in the upgrade? 00:13:17 <knurd> but users still on 5.0 would run into broken deps problems then 00:13:55 <knurd> well, seems I'm the only one htat thinks that we do it like that 00:14:04 <knurd> so let's ignore the issue for now 00:14:20 <knurd> it's not that important (but I think it would be nice to have and shouldn#t be to much work to realize) 00:14:20 <nirik> knurd: we might bring it up on list... if we were confused, there might be others as well... 00:14:31 <knurd> yeah, maybe 00:14:34 <mmcgrath> so the specific use case is people who do not or cannot upgrade to 5.1 but still want to use epel for a few months. 00:14:40 --> mcepl () has joined #fedora-meeting 00:14:43 <knurd> mmcgrath, yes 00:15:12 <nirik> then the expectation is that they would upgrade after a few months? and not just always stay on 5.0 00:15:15 <mmcgrath> and to do that we'll have to create a directory full of hard links, decide when it should expire, update our scripts to point to the new location but possibly have it do security updates to 5.0. 00:15:43 <mmcgrath> I guess my concern is, if its on our mirror I would consider it supported so if I'm using 5.0, I'd expect it to be up to date until it disappears. 00:15:59 <mmcgrath> yeah, we should take it to the list for input. 00:16:09 <knurd> mmcgrath, k 00:16:52 <knurd> I suppose I'll do that then 00:16:56 * knurd moves on 00:17:03 --- knurd has changed the topic to: EPEL Meeting | push to stable easily -- knurd/nirik/dgilmore 00:17:19 <knurd> dgilmore, I suppose that I can remove that from the schedule for now? 00:17:20 <nirik> so the scripts are all setup now? 00:17:31 <knurd> nirik, seems so 00:17:35 * nirik hasn't had time to remove things that need to be removed... will try and do that today. 00:17:47 <knurd> dgilmore said they are working as expected now as far as he knows 00:17:48 <nirik> also there are some security updates that need to push direct to stable 00:17:58 <mmcgrath> I don't think we've fully tested the test -> stable part yet have we? 00:18:09 <knurd> mmcgrath, not sure 00:18:33 <nirik> yeah, I don't think we have. 00:18:53 <knurd> well, someone should 00:19:10 <knurd> nirik, are those packages that should go to testing a good testbed? 00:19:11 <nirik> I guess I can setup a mirror repo here, add in the security updates and make sure it's ok, delete the broken dep packages, and then if all looks ok try a push 00:19:42 <nirik> which packages? built but not in testing? 00:19:54 <knurd> nirik, wouldn#t it be easier for those security updates to just diff "requirements of old and new package"? 00:19:57 --> llaumgui () has joined #fedora-meeting 00:19:58 <knurd> those should be identical 00:20:21 <knurd> nirik, not sure; are those "security updates that need to push direct to stable" build already or in testing? 00:20:52 <knurd> I suppose we need to do the real testing -> stable move soon as well 00:20:55 <nirik> well, for example, thttpd is one... I think it's built but not in testing yet. So, it would need to go from nothing to stable, bypassing testing. 00:21:13 <knurd> RHEL 5.1 is planed for this quarter iirc 00:21:49 <nirik> I will try and clean up things and test pushing tonight... 00:21:54 <knurd> nirik, did you get instructions from michael about the new commands? 00:22:07 <nirik> yeah, in that orig email you forwarded I think. 00:22:13 <knurd> e.g. how to push to stable directly or how to move from testing to stable 00:22:16 <knurd> nirik, k 00:22:19 <knurd> so how about this: 00:22:24 <nirik> yeah, if they work I can do it. :) 00:22:31 <knurd> we create a backup on the master repo 00:22:34 <knurd> try the push script 00:22:48 <knurd> and abort if it does stupid things? 00:23:24 <nirik> well, I think the way it works is that it works on a copy until the final sync, then it syncs to the real repo... 00:23:40 <nirik> so in theory we can copy back if the script messes up. 00:23:47 <nirik> I can make a backup copy tho too. 00:24:17 <nirik> as long as their is space for it. 00:24:35 --> knurd_ (n=thl@fedora/thl) has joined #fedora-meeting 00:25:15 <knurd_> sorry, the machine with "knurd" on it just crashed afaics 00:25:17 <mmcgrath> knurd_: :) 00:25:24 <dgilmore> knurd, nirik: can one of you document that in the wiki 00:25:41 <knurd_> "that" -> what michael send us? 00:25:49 <dgilmore> knurd: yes 00:26:11 <nirik> sure... anywhere sound good, or just a new page? 00:26:27 <knurd_> nirik, can you take care of it? 00:26:31 <nirik> sure. will do now. 00:26:34 <knurd_> nirik, thx 00:27:02 <-- knurd has quit (Read error: 104 (Connection reset by peer)) 00:27:11 <knurd_> nirik, so can you try to move a pacakge from testing to stable? 00:27:18 <knurd_> and one from needsign directly to stable? 00:27:23 <knurd_> so we know that it works? 00:27:26 --- knurd_ is now known as knurd 00:27:33 <nirik> sure. What package from testing should be moved to stable? 00:28:13 <knurd> are there maybe two security updates in needsign? 00:28:18 <knurd> then push one to testing 00:28:24 <knurd> and from there to stable right after? 00:28:29 <knurd> and the other one directly? 00:28:50 <nirik> yeah, I can't recall, but I think there might be another one or two 00:28:55 <nirik> can try that 00:29:03 <knurd> nirik, that would be great 00:29:06 <knurd> thx for your help 00:29:16 <nirik> also, there are package s that need to be removed... 00:29:21 <mmcgrath> nirik rocks the house. 00:29:34 * knurd has really not enought time atm 00:29:35 --> fab__ () has joined #fedora-meeting 00:29:43 <knurd> should get better in two weeks again 00:29:47 <nirik> ha. I wish I had more time to figure out the scripts and have been able to get things going sooner. 00:30:00 --- knurd is now known as knurd_ 00:30:14 --> knurd (n=thl@fedora/thl) has joined #fedora-meeting 00:30:35 * knurd_ moves on 00:30:40 --- knurd_ has changed the topic to: EPEL Meeting | RHEL / EPEL 5.1 -- unassigned 00:30:43 <knurd_> forgot something 00:30:49 <knurd_> RHEL 5.1 is likely out soon 00:30:52 <knurd_> we don#t know when 00:30:56 --> linux_geek () has joined #fedora-meeting 00:31:14 <knurd_> so I suppose we need to do the EPEL testing -> stable move a week or two after 5.1 is out 00:31:26 <knurd_> is that fine for everybody? 00:31:47 <nirik> yeah, sounds good. Again, we will want to make sure there are no broken deps, etc. 00:31:50 <mmcgrath> that sounds reasonable. 00:32:08 <knurd> nirik, yeah, I suppose we should leave those broken deps in testing 00:32:10 <nirik> Also, there are a few packages that are pulled into 5.1 that were in EPEL. We will want to tell maintaners to dead.package them? 00:32:18 <knurd> nirik, good idea 00:33:09 * knurd moves on for real then again 00:33:17 --- knurd has changed the topic to: EPEL Meeting | do more on the list and less in the meetings; "Power to the people with no delay." aka "Steering Committee's are slow and old style" -- all 00:33:41 <knurd> I suppose we really somehow need to discuss this on the list and then just start it 00:33:44 <-- kital has quit (Read error: 104 (Connection reset by peer)) 00:33:46 <knurd> and see how it goes 00:33:52 <knurd> and fine-tune it while doing it 00:34:00 <mmcgrath> It'd be nice if we had an official way to make decisions on the list. 00:34:21 --> kital (n=Joerg_Si@fedora/kital) has joined #fedora-meeting 00:34:37 <knurd> mmcgrath, yeah, agreed 00:35:12 <knurd> like in "if no one objects within some days it's considered accepted?" 00:35:20 <-- enemy99 has quit (Remote closed the connection) 00:35:34 <warren> BTW, I inserted this rule into RH's processes for adding a new package to RHEL. 00:35:39 <mmcgrath> yeah. 00:35:53 <warren> something like "Check EPEL to be sure your new package is newer" 00:36:05 <nirik> warren: excellent. 00:36:11 <knurd> warren, thx 00:36:34 <warren> also "smooth upgrade from EPEL" 00:36:40 <knurd> mmcgrath, I'd say let's discuss that on the list 00:36:49 * knurd has to leave soon for some minutes 00:36:51 * tux_440volt will be back soon: Gone away for now. 00:37:17 <knurd> does that sounds sane? 00:37:32 <knurd> e.g. discuss on the list how to do more things on the list? 00:37:39 <nirik> sure. ;) 00:37:54 --- knurd has changed the topic to: EPEL Meeting -- Free discussion around EPEL 00:38:09 <knurd> if there anything else we need to discuss today? 00:38:10 <nirik> knurd, mmcgrath, dgilmore: http://fedoraproject.org/wiki/EPEL/EPEL_repositoryinfo (feel free to correct/add/etc) 00:38:28 <knurd> Generic Job Description? Communication plan] for enterprise customers/ISVs/IHVs? 00:38:37 <knurd> or shall we try to finish those on hte list as well? 00:38:55 <mmcgrath> knurd: yeah, especially since the meetings have just been the few of us. 00:39:07 <knurd> k 00:39:08 <nirik> so are we sticking with the alternate meeting time? it didn't seem to help much last week except that knurd wasn't able to make it. 00:39:29 <knurd> nirik, I'd say we try antoher two or three weeks and decide afterwards 00:39:32 <nirik> ok 00:39:56 <knurd> k, anything else? 00:40:09 <mmcgrath> nope 00:40:27 * knurd will close the meeting in 30 00:41:02 * nirik has nothing. 00:41:16 * knurd will close the meeting in 10 00:41:27 <knurd> -- MARK -- Meeting end 00:41:27 --- knurd has changed the topic to: Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel for meeting schedule 00:41:31 <knurd> thx everyone 00:41:40 <mmcgrath> thanks knurd 00:41:40 <-- knurd_ has quit ("knurd again") 00:41:59 * knurd afk for a few minutes 00:42:07 --> enemy99 () has joined #Fedora-Meeting 00:42:08 <nirik> thanks knurd
On Mon, 17 Sep 2007, Thorsten Leemhuis wrote:
00:35:34 <warren> BTW, I inserted this rule into RH's processes for adding a new package to RHEL. 00:35:53 <warren> something like "Check EPEL to be sure your new package is newer"
I would like to comment on this one.
It would be important to add that epoch-inflation is undesirable/unwanted. I know that in some cases it cannot be avoided, but still I would hate to see Red Hat ship some older release with a higher (non-zero) epoch for convenience when they at least could see if the EPEL version would pass QA testing.
epel-devel@lists.fedoraproject.org