epel-devel

epel-devel@lists.fedoraproject.org

5 participants
14304 discussions

EPEL acceptance policy
by Tim Burke 14 Mar '07

14 Mar '07

Hi, I was just checking out the acceptance policy listed here: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenance… There's a few acceptance criteria that I think it would help to blatantly spell out there. Perhaps this is really nit points and could be safely assumed, but I think it doesn't hurt to spell things out. I think the intention is to not ship in EPEL stuff which RH already ships. Specifically this is stated as: "Thus packages from EPEL should never replace packages from the target base distribution" I'm wondering if people may misinterpret that to think that things not on the base RHEL isos are fair game for replacement. Layered products from RH which are delivered separately from the OS come to mind. Another example would be packages which are only intended for certain release variants. For example, the GFS cluster components are not available to desktop / client configurations - server only. Tying to think of an alternative recommended wording: "thus packages from EPEL should never replace packages delivered by Red Hat - including those on the base distribution as well as layered products."

6 8

Fedora EPEL Package Build Report 2007-03-14
by Fedora Koji Build System 14 Mar '07

14 Mar '07

Packages built and released for Fedora EPEL 5: 5 NEW cfengine-2.1.22-1.el5 eggdrop-1.6.18-7.el5 NEW libsmbios-0.13.4-1.el5.1 NEW pastebin-0.50-3.el5 rpmlint-0.79-1.el5 Packages built and released for Fedora EPEL 4: 13 NEW cfengine-2.1.22-1.el4 eggdrop-1.6.18-7.el4 NEW libsmbios-0.13.4-1.el4.1 NEW nagios-plugins-1.4.6-3.el4 nfswatch-4.99.8-1.el4 NEW nrg2iso-0.4-2.el4 NEW pastebin-0.50-3.el4 NEW perl-Algorithm-Diff-1.1902-2.el4 perl-SOAP-Lite-0.68-5.el4 NEW perl-Text-Diff-0.35-3.el4 rpmlint-0.79-1.el4 NEW ssmtp-2.61-11.1.el4 NEW tcpxtract-1.0.1-7.el4 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/

1 0

Summary from yesterdays EPEL meeting
by Thorsten Leemhuis 12 Mar '07

12 Mar '07

Also in the wiki at http://fedoraproject.org/wiki/EPEL/Meetings/20070311 = Meeting 20070311 = [[TableOfContents]] == Attending == * dgilmore * mmcgrath (first part only) * nirik * quaid * thl == Summary == * getting RHEL5 on the builders is a priority now as we should use it before we actually tell contributors to "really start now"; dgilmore and mmcgrath will look into this; CentOS5 beta should hopefully be out soon for testing by users, too. * thl reworked the schedule a bit to reflect the current status a bit better * a shortcut for people wanting to branch lots of packages for EPEL might be helpful. Is anybody interested in writing two scripts? Maybe something like this: * a short script that parses owners.list for all your packages by e-mail and writes the list out on a single line (like "random(a)host.somewhere foo bar foobar") * another script then can be run on the branching machine that takes a string like "EL-4,EL-5 random(a)host.somewhere foo bar foobar" and then creates owners.epel.list entries for those packages (if they don't exists already; needs to get the description from owners.list) and creates the branches (the cvs admins would need to fill this part) Then we could use a wiki page and a branch method similar to the old Extras method for the EPEL start phase * quaid worked on http://fedoraproject.org/wiki/EPEL/CommunicationPlan ; "what I'm hoping is ... anyone here who knows something that should be in there, just pile it into the page if we get enough info, we'll spin off a stand-alone page for that topic; otherwise it can be covered in short there." * we'll probably remove all those "PLEASE READ: This is currently a being worked on and not yet finished -- consider it a draft and as not yet official" warning from the wiki at end of march. Guys, please review (and fix) what is written there! * some discussion about steering issues that got discussed on the list this week; seems people would like to prefer to stick to the current scheme as long as problems that need to be solved can get solved with an consensus on the list and in the meetings * discuss the meeting time on the list again (discussion kicked off already) Note: there are some takes on the schedule at http://fedoraproject.org/wiki/EPEL/Schedule that could need some help. Anybody for example interested in setting up a epel-release package, that people can install by "rpm -ivh foo.src.rpm" and contains key and repo files for EPEL so it is automatically used by up2date in RHEL 4, yum in RHEL 5 and yum on CentOS 4 + 5? == Full log == {{{ 00:00 * | thl looks around 00:00 < thl> | according to my clock it's EPEL meeting time 00:00 * | quaid kicks daylight savings in the shins 00:00 < thl> | ping dgilmore mmcgrath 00:00 < mmcgrath> | thl: pong 00:00 < thl> | hah 00:01 < thl> | quaid, yeah, we didn't change yet 00:01 < mmcgrath> | we had dst last night so it may be odd for people to get in. 00:01 < thl> | we'll change in two weeks from now 00:01 < thl> | I'm fine moing the meeting time so the effective meeting time stay the same 00:01 * | nirik is here, but also sick and on the phone. ;)_ 00:01 --> | jmbuser (John Babich) has joined #fedora-meeting 00:01 * | thl has some food in the oven that will be read in 15 minutes 00:01 < mmcgrath> | I've got an alarm clock that changes automatically but its at least 7 years old. I woner what will happen this year. 00:03 * | thl wonder if we should start the meeting or wait another hour 00:03 < mmcgrath> | hmm 00:03 < EvilBob> | waiting and hour would be bad 00:04 * | thl wonders if waiting an hour would be the wrong direction 00:04 < thl> | stupid dst changes 00:04 < jmbuser> | EvilBob: so you want to wait an hour? :-) 00:05 < EvilBob> | thl: FDSCo is waiting for the room 00:05 < thl> | EvilBob, k, noted, thx :) 00:05 < thl> | EvilBob, is that a regular meeting? then add it to http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel ;-) 00:06 < thl> | well, then let's start 00:06 < dgilmore> | pong 00:06 < thl> | I updated the schedule a bit 00:06 < thl> | hi dgilmore 00:06 < thl> | the two most important things afaics are: 00:06 < thl> | get RHEL5 onto the builders 00:07 < thl> | so people can actually start 00:07 < thl> | and find some kind oft shortbut for branching for people that have a lot of pacakges 00:07 < thl> | mmcgrath, quaid, do you have access to RHEL5 already? 00:07 < thl> | could you get it onto the builders? 00:07 < thl> | dgilmore, seems quite busy already afaics 00:08 < mmcgrath> | thl: Possibly, I'm waiting to hear back from the cusotmer service people. 00:08 < dgilmore> | thl: there is supposed to be a way using up2date to pull all teh packages i need to work it out. 00:08 < mmcgrath> | Just so the people here know for the future, our licenses have to go through Red Hat's customer service. 00:08 < quaid> | mmcgrath has much better theoretical chance than I do 00:08 * | dgilmore has not used up2date in many years 00:09 < mmcgrath> | and be extra careful about saying you need RHEL entitlements for Fedora not "Fedora Entitlements" Someone about killed me. 00:09 < nirik> | thl: is the centos 5 beta out yet? last time I checked it was not... 00:09 * | dgilmore really wants to just be able to rsync it 00:09 < dgilmore> | nirik: soon 00:09 < thl> | nirik, not yet; it was supposed to be out some days ago but then they delayed it "to fix some more bugs" 00:09 < quaid> | mmcgrath: are you forming an internal group through CS for all Fedora machines? 00:09 < nirik> | also, I think we should require all EL-4 branches to also branch EL-5... we don't want to drop packages in upgrade, do we? 00:09 < thl> | mmcgrath, for now it would be enough to get RHEL5 00:09 < thl> | building against the beta1 sucks 00:10 < thl> | I don't want to tell people to actually start before we have RHEL5 in the buildroots 00:10 < mmcgrath> | quaid: We actually have 150 RHEL licenses (I didn't realize that) 00:10 < thl> | nirik, well, there are some people that moved to core (and thus to RHEL5); we don#t want branches for those 00:10 < nirik> | well, it's also hard to start when you don't have any way of testing it (at least I prefer to be able to test builds on a new release) 00:10 < dgilmore> | mmcgrath: i noticed that the other day 00:11 < mmcgrath> | I'm still trying to get in touch with the right people to see what we can do with them and how to renew, they expire in May currently. 00:11 < thl> | nirik, I think it's okay to build blindly atm 00:11 < thl> | as stuff goes into a testing branch 00:11 < dgilmore> | RHEL 5 rhgb is ugly 00:11 < thl> | and hopefully CentOS5 will be out soon 00:11 < quaid> | mmcgrath: I recently set up a new group for the online services, I'll find the details and fwd. to you 00:11 < mmcgrath> | quaid: danke 00:11 < dgilmore> | thl: hopefully before the end of march 00:12 < thl> | dgilmore, I hope so 00:12 * | dgilmore installed beta2 as a kvm guest last night 00:12 < thl> | so, who takes over the RHEL5 on the builders task? mmcgrath? 00:12 < dgilmore> | thl: im fine with doing it 00:12 < thl> | is it possible to get RHEL5 until next week? 00:13 < mmcgrath> | I'll get the content (rpms) then dgilmore or I will set up the configs. 00:13 < thl> | dgilmore, k, also fine for me :) 00:13 < dgilmore> | i just need to work out the best way to do so and maintain them 00:13 < mmcgrath> | I wonder if we have a TAM or something :-D 00:13 < thl> | dgilmore, mmcgrath, well, is there any chance to get RHEL5 stuff onto the builders by next week? 00:13 < thl> | s/by/during/ 00:14 <-- | FrancescoUgolini has quit ("Quit") 00:14 * | thl looks after his food in the oven 00:14 < dgilmore> | thl: :) it is doable in one way or another 00:15 < mmcgrath> | thl: I think that should be doable, I've been having trouble finding the right email address to contact. 00:15 < thl> | dgilmore, mmcgrath that would be great; thx for your help 00:16 * | thl will leave soon for a while to eat the stuff that cooking 00:16 * | mmcgrath too might have a small interuption this morning 00:17 < thl> | sorry for the trouble 00:17 < mmcgrath> | and there it is, br 00:17 < mmcgrath> | b 00:17 < thl> | the schedule is at http://fedoraproject.org/wiki/EPEL/Schedule 00:17 < thl> | maybe you guys want to talk about other things? 00:17 < thl> | or we stop and meet again next week 00:18 < thl> | what about the steering issues thimm brought up? 00:18 < thl> | should we discuss them now? 00:18 < dgilmore> | there are alot of people not here 00:18 * | thl now afk for a while; sorry 00:18 < dgilmore> | quaid: how goes your work? 00:19 < quaid> | dgilmore: heh, which? for the most part, pretty good 00:19 < dgilmore> | quaid: :) cool anything to report in regards to EPEL 00:20 < quaid> | ah, you mean, on this topic :) 00:21 < quaid> | I haven't found the right people to propose subscriptions for EPEL maintainers 00:21 < dgilmore> | cool 00:21 < nirik> | dgilmore: I see there isn't a epel el5 version in bugzilla... should there be along with el4? or not until we get buildroots, etc spun up and happy? 00:21 < quaid> | I may want to coordinate with mmcgrath and have those added as aspecial subs to the Fedora group 00:22 < dgilmore> | nirik: i asked for it when it was setup and he didint do it 00:22 < nirik> | bummer 00:22 < dgilmore> | i figured ill bug him when RHEL 5 is released as final 00:22 * | quaid had several Firefox crashes while writing up CommunicationPlan, but there is at least a start there now 00:22 < dgilmore> | quaid: possibly 00:23 < quaid> | http://fedoraproject.org/wiki/EPEL/CommunicationPlan 00:23 < quaid> | what I'm hoping is ... 00:23 < quaid> | anyone here who knows something that should be in there, just pile it into the page 00:23 < quaid> | if we get enough info, we'll spin off a stand-alone page for that topic; 00:24 < quaid> | otherwise it can be covered in short there. 00:24 < dgilmore> | sounds good 00:24 * | thl back at the keyboard, with some food besides him 00:25 * | thl will take a closer look at http://fedoraproject.org/wiki/EPEL/CommunicationPlan later 00:25 < quaid> | thl's food is on the keyboard! 00:26 < thl> | btw, when do we plan to remove all those "PLEASE READ: This is currently a being worked on and not yet finished -- consider it a draft and as not yet official" warning from the wiki? 00:26 < dgilmore> | thl: what do you have to eat? 00:26 < nirik> | I would say we could do that when we offically announce and move things from testing to a main repo? 00:27 < quaid> | personally, I need to spend a few hours going over the language clarity, etc., before I want to remove draft warnings :) 00:27 < quaid> | but I'm always wanting to do that, so don't let that hold us back 00:28 < thl> | dgilmore, some pasta 00:28 < dgilmore> | thl: : 00:28 < dgilmore> | ;) yum 00:29 < thl> | quaid, I'd say we should plan to remove those in two or three weeks 00:29 < thl> | quaid, so there is still some time to fix all those stupid typos and grammatical mistakes thl made ;-) 00:29 < quaid> | :) 00:30 < thl> | shall we plan 20070401 as target date for remoal of those warnings? 00:30 < dgilmore> | wy is rhn down again 00:30 < f13> | dgilmore: RHEL5 syncup 00:30 < dgilmore> | thl: sounds good 00:30 < thl> | I can send a mail to the list asking people to look over it 00:30 < dgilmore> | f13: ahh 00:31 < quaid> | new code, too 00:31 < dgilmore> | f13: do you know of anyone we could bug that would let us be able to rsync trees from cvs-int 00:32 < mmcgrath> | Sorry guys I have to scoot, an out of town friend just dropped by :-/ 00:32 < dgilmore> | mmcgrath: have fun 00:32 < thl> | mmcgrath, yeah, have fun! 00:33 < thl> | btw, is anybody willig to work out two small scripts? 00:33 < thl> | so make it a bit easier for dgilmore to branch packages for EPEL? 00:34 < thl> | one script that looks at owners.list for all packages owned by foo 00:34 < thl> | and another script that creates owners.eple.list entries and the branches from a string like "EL-4 foo@bar baz foobar ..." 00:35 < thl> | quaid, btw, what's your take on the steering issues? 00:35 < thl> | should we have a steering committee soon? 00:35 < quaid> | thl: sorry, which? 00:35 < quaid> | oh 00:36 < quaid> | are we prepared to have an election for it? 00:36 < thl> | quaid, I'd say FESCo should appoint people 00:36 < thl> | and then we target for a election three months later 00:37 < nirik> | so all thats just so we can vote on fedora-usermanagement? 00:37 < dgilmore> | thl: if we have one thats how i would say we do it 00:37 < thl> | nirik, well, I think it's a general problem 00:37 < quaid> | thl: that's interesting, in that I don't think FP has a process for that 00:37 < thl> | the question "who decides" in not regulated afaics 00:38 < thl> | I can ask FESCo what they would prefer 00:38 < quaid> | http://fedoraproject.org/wiki/DefiningProjects 00:39 < quaid> | it's the last section 00:39 < thl> | quaid, I'd say we should not make a official project yet 00:39 * | thl takes a look 00:39 < quaid> | right, so to have a steering committee implies formal project 00:40 * | thl wonders why can't we have a SIG that has a steering committee without being a official project 00:40 * | quaid adds anchors and toC to that page 00:40 < quaid> | thl: maybe we can 00:40 < quaid> | thl: in which case, appointment is the form, i guess 00:41 < thl> | quaid, FESCo should be able to regulate it 00:41 < thl> | the question still is if we want one... 00:41 < quaid> | maybe wait until the SIG is too big? 00:42 < thl> | quaid, or until problems that need to be solved can't get solved without an real consensus 00:42 < quaid> | yeah 00:43 < thl> | other opinions? dgilmore, nirik ? 00:43 < nirik> | well, I hate to add a bunch of overhead just to solve one contentious issue... 00:44 < dgilmore> | nirik: indeed 00:44 < nirik> | didn't ensc say fedora-user-mgmt won't work on EL4? we could then remove it for now and let fedora come up with a solution down the road? 00:44 < thl> | nirik, well, having a steering committee might makes things easier sometimes, too 00:44 < dgilmore> | i think if we have a steering committe we are likely to diverge from fedora 00:44 < thl> | nirik, the lates version doesn#t work on EL4 00:44 < thl> | nirik, older ones do 00:44 < dgilmore> | id like to do whatever we can to make sure we dont 00:45 < nirik> | dgilmore: +1 00:45 < dgilmore> | thl: the version in EL-4 should be FC-3's 00:45 < dgilmore> | so it should work 00:46 < thl> | yeah, it should 00:47 < thl> | so we leave this open as see how it envolves over time? 00:48 < nirik> | I think it should be possible to come to some technical consensus... not easily, but it should be possible 00:49 < nirik> | I do see ensc has been putting up ideas for what should be addressed in a replacement, which is good. 00:49 < thl> | k 00:49 < thl> | so anything else? 00:50 < thl> | or shall we adjourn and meet again next week? 00:50 < nirik> | do we want to look at a new meeting time where more of the people from the list can make it? 00:51 < nirik> | might help solve some of the issues if we can get everyone talking... 00:51 < nirik> | s/talking/typing/ 00:51 < thl> | nirik, I asked once on the mailing list if people would like a new meeting time 00:51 < thl> | one or two weeks ago 00:51 < thl> | I got no replay 00:51 < thl> | reply 00:51 < quaid> | we should discuss it on list :) 00:51 < thl> | but I agree, we should ask once again on the list 00:51 < quaid> | now that we all experienced DST pain, it will be back on people's minds 00:52 < nirik> | huh... not sure I ever say it... ok. 00:52 < nirik> | ever saw it. Sorry, cold meds must be affecting my typing. ;) 00:53 < thl> | nirik, I think it was in a meeting summary 00:53 < thl> | so anything else? 00:53 < thl> | or close for today? 00:53 < nirik> | ok, we should post again now about it in it's own post. Can you do that thl ? or would you like me to? 00:53 < dgilmore> | i have nothing else 00:54 < dgilmore> | my time available for meetings is limited 00:54 < dgilmore> | i cant do it during work time 00:54 < thl> | nirik, I'll do 00:54 * | thl will close the meeting in 30 00:54 * | thl will close the meeting in 15 00:55 <-- | jmbuser has left #fedora-meeting ( "Leaving") 00:55 < thl> | -- MARK -- Meeting end 00:55 < thl> | thx guys 00:55 < nirik> | dgilmore: yeah, but after business hours some weeknight might work? 00:56 < nirik> | thanks thl 00:57 < thl> | nirik, thx in the middle of the night for me.... 00:57 < thl> | s/thx/that's/ 00:57 < nirik> | whats your TZ offset? if it's late enough here wouldn't it be your morning? 00:57 * | quaid notes that FDSCo is meeting currently in #fedora-docs 00:57 < thl> | everything later in the evening than FESCo is problematic for me 00:57 < thl> | nirik, UTC-1 00:58 < thl> | nirik, UTC-2 when in two weeks, when we get DST 00:58 < thl> | I'm on the yeboard at round about 6:40 local time in the mornings 00:58 < nirik> | quaid: might suggest switching to here? it's nice to have all the meetings in one place so people can lurk and hear about things they normally don't know about... 00:58 < dgilmore> | nirik: yep but i think its to late for europe 00:58 < quaid> | nirik: it's an ongoing discussion at the moment, actually 00:59 * | thl really likes #fedora-meeting -- that way one gets a chance to look what the others are discussing 00:59 < dgilmore> | thl: :) yep i like it to }}}

3 4

rename fedora-usermgmt?
by Rahul Sundaram 10 Mar '07

10 Mar '07

Hi I see fedora-usermgmt has been made available for EPEL. That is probably going to cause some confusion. Maybe rename it into system-usermgmt or something more distribution neutral. The other packages except for fedora-ds-base are all indeed specific to Fedora. Rahul

15 81

RFP: octave and octave-forge for EL5
by Phil Schaffner 10 Mar '07

10 Mar '07

Apparently Octave has been orphaned for EL5 , although it is still in Fedora Extras. Seems like octave and octave-forge are excellent candidates for EPEL. They do successfully build from FC6/7 src.rpm packages under the CentOS5 beta that is currently undergoing QA testing, albeit with a few additional requirements... octave SRPMS: fftw-3.1.2-3.fc6.src.rpm glpk-4.13-1.fc6.src.rpm hdf5-1.6.5-7.fc7.src.rpm octave-2.9.9-1.fc6.src.rpm rpmdevtools-5.3-1.fc6.src.rpm ufsparse-2.1.1-1.fc6.src.rpm octave RPMS: fftw-3.1.2-3.el5.i386.rpm fftw-debuginfo-3.1.2-3.el5.i386.rpm fftw-devel-3.1.2-3.el5.i386.rpm glpk-debuginfo-4.13-1.el5.i386.rpm glpk-devel-4.13-1.el5.i386.rpm glpk-utils-4.13-1.el5.i386.rpm hdf5-1.6.5-7.el5.i386.rpm hdf5-debuginfo-1.6.5-7.el5.i386.rpm hdf5-devel-1.6.5-7.el5.i386.rpm octave-2.9.9-1.el5.i386.rpm octave-debuginfo-2.9.9-1.el5.i386.rpm octave-devel-2.9.9-1.el5.i386.rpm rpmdevtools-5.3-1.el5.noarch.rpm ufsparse-2.1.1-1.el5.i386.rpm ufsparse-debuginfo-2.1.1-1.el5.i386.rpm ufsparse-devel-2.1.1-1.el5.i386.rpm For octave-forge: octave-forge SRPMS: cln-1.1.13-2.fc6.src.rpm ginac-1.3.6-1.fc7.src.rpm gsl-1.8-2.fc7.src.rpm libdap-3.7.2-3.fc7.src.rpm libnc-dap-3.6.2-5.fc7.src.rpm octave-forge-2006.07.09-7.fc6.src.rpm qhull-2003.1-6.fc6.src.rpm octave-forge RPMS: cln-1.1.13-2.el5.i386.rpm cln-debuginfo-1.1.13-2.el5.i386.rpm cln-devel-1.1.13-2.el5.i386.rpm ginac-1.3.6-1.el5.i386.rpm ginac-debuginfo-1.3.6-1.el5.i386.rpm ginac-devel-1.3.6-1.el5.i386.rpm ginac-utils-1.3.6-1.el5.i386.rpm libdap-3.7.2-3.el5.i386.rpm libdap-debuginfo-3.7.2-3.el5.i386.rpm libdap-devel-3.7.2-3.el5.i386.rpm libnc-dap-3.6.2-5.el5.i386.rpm libnc-dap-debuginfo-3.6.2-5.el5.i386.rpm libnc-dap-devel-3.6.2-5.el5.i386.rpm octave-forge-2006.07.09-7.el5.i386.rpm octave-forge-debuginfo-2006.07.09-7.el5.i386.rpm qhull-2003.1-6.el5.i386.rpm qhull-debuginfo-2003.1-6.el5.i386.rpm qhull-devel-2003.1-6.el5.i386.rpm This is not necessarily the exact set of packages that might be selected to address the goals of enterprise-level stability that have been discussed in recent posts, just what worked for me in a test-of-concept build. (e.g. not my "best effort" :-) Phil P.S. Could someone please fix the spelling in the Reply-to string? EPEL development disccusion <epel-devel-list(a)redhat.com>

3 3

Request for voting SIG
by Axel Thimm 10 Mar '07

10 Mar '07

Hi, we need to get a voting body set up asap. Nominate a bunch of folks, maybe the ones in the wiki plus a couple more and give them fesco to ratify (by vote) and to formulate our mandate. -- Axel.Thimm at ATrpms.net

4 13

package stability
by Patrice Dumas 09 Mar '07

09 Mar '07

Hello, Do we want to keep API/ABI stable over the corresponding RHEL release? I think yes, but then we should really make sure that some libs don't go to EPEL (for an example of a lib I maintain there is libdap which changes API every 6 months or so). Is there something similar for apps, for example that searching paths command-line options, config files, file formats, are backward compatible? If we impose such constraints, maybe there could be a discussion before a package enters EPEL. Not a formal review because there should be no packaging/usability issues, but a verification that the package is stable enough and there are enough people/firms interested such that if the maintainer stops maintaining a package that needs work it won't be really unmaintained. -- Pat

9 35

Release and update procedure for EPEL
by Matthias Saou 08 Mar '07

08 Mar '07

FP! :-) Joke aside, I'd like to see which views we have on the release and update procedure to apply to EPEL. - Do we want a moving (and potentially breaking) set of packages which is constantly being updated? - De we want a fixed set of packages when a RHEL release is made and focus on major bugfixes and security updates from there on? Or maybe something in between, or even both at the same time in separate repositories... all is possible, as long as we have enough man power to make it happen. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 1.10 1.28 1.18

14 35

EPEL vs Fedora main
by Axel Thimm 08 Mar '07

08 Mar '07

The current discussion about fedora-usermgr is an example of most probably a bad choice in Fedora which stalls EPEL. What will the general consensus be in this and further conflicting situations? Bringing this upstream, e.g. to Fedora main, is a noble thing, but waiting for such things to resolve in Fedora-land takes a long time, and in Fedora many people are more willing to compromise on stuff they consider sub-optimal than in RHEL. So will we be able to decide on anything deviating from Fedora or will everything that comes up in RHEL land need to go through the Fedora machinery? Of course, the highest commandment remains to be compatible to Fedora, but only as much as is really possible, and not blindly inherit everything that's being semi-tolerated in Fedora. If we can stand on our own feet, then we should start by voting on whether we want fedora-usermgmt to be part of RHEL or not. We can then move on to other important things as EPEL sig, and hope that the issue will be ironed out on Fedora someday. -- Axel.Thimm at ATrpms.net

4 13

noticing the list for new packages?
by Patrice Dumas 07 Mar '07

07 Mar '07

Hello, I think that it would be nice if people doing branches in EPEL noticed the list such that it can be seen, and maybe discussed. This is not relevant for all packages, for example it is not interesting for an old stable utility package or a deprecated lib nobody uses anymore anyway, or some graphical apps that cannot have issues of compatibility or perl and python modules that haven't been changed in years. But for most libs, some modules and apps that are to be used by other apps for example compilers, doc apps translators, etc. I think it would be interesting that people wanting to maintain them post a short notice describing: * how stable is the software upstream * what kind of updating is intended (use latest versions, backport with explanation on what will be backported and even how...) * whether comaintainers are wanted * other? That way there could be a discussion, I am a bit scared that packages enter EPEL without discussion. I don't want this kind of stuff to become bureaucratic either. -- Pat

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

epel-devel