20:59:50 <smooge> #startmeeting EPEL SIG (2010-02-12)
20:59:50 <zodbot> Meeting started Fri Feb 12 20:59:50 2010 UTC.  The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:59:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:59:59 <smooge> #topic roll call
21:00:11 <smooge> Hello guys I will be running the meeting today
21:00:15 <derks> I'm here for epel meeting
21:00:25 <smooge> stahnma is unavailable and nirik might also be
21:00:31 <smooge> hello derks
21:00:32 <nirik> I'm around...
21:00:38 <smooge> thank you for arriving
21:00:39 <tremble> I'm here...
21:00:57 <smooge> hi tremble
21:01:06 <smooge> ok today's meeting should be pretty quick
21:01:13 <smooge> the agenda should be:
21:01:25 <smooge> - Status update on action items
21:01:25 <smooge> - smooge: Blocking packages already in RHEL
21:01:25 <smooge> - Fuse for 5.4 status
21:01:25 <smooge> - RHEL 5.5
21:01:25 <smooge> - Dead packages.. need for no frozen rawhide?
21:01:26 <smooge> - Open Floor
21:01:40 <smooge> anything I have missed or need to add?
21:02:02 <smooge> #topic status of itmes
21:02:43 <smooge> I have downloaded the latest packages and such and am going through what items should be blocked
21:03:04 <smooge> I should have a list of packages that need to be dropped/added/changed for 5.5 this weekend.
21:03:10 <nirik> of course 5.5 will be along soon too. ;)
21:03:19 <nirik> oh, you are checking 5.5 beta?
21:03:38 <smooge> yes
21:03:59 <nirik> cool.
21:04:10 <smooge> they rarely add or subtract packages after the beta
21:04:17 <smooge> so its a good place to check from
21:05:16 <smooge> the package list for blocking I am going to look at core stuff
21:05:29 <smooge> and items that have been added in.
21:05:47 <smooge> the blockage will be for i386 and x86_64. ppcXX is a bit funky
21:05:59 <nirik> yeah. ;(
21:06:22 <smooge> I would be happy to drop it like an itanium bomb. but not my call :)
21:07:03 <smooge> ok anyone want to talk about FUSE and 5.x
21:07:29 <nirik> I think things are going well there... we have a number of fuse packages no
21:07:30 <nirik> now.
21:07:45 <smooge> #topic FUSE is go for throttle up
21:08:08 <smooge> so FUSE packages have been added and that looks good.
21:08:26 <smooge> cool
21:08:38 <smooge> #topic RHEL-5.5 anyone playing with it?
21:08:58 * nirik hasn't. The changes didn't look all that major...
21:09:07 <smooge> ok so this week RHEL-5.5 was released for testing.
21:09:16 * tremble hasn't had chance yet.
21:09:35 <smooge> I have started downloading the ISO but will probably be ready by Monday due to super fast net speeds at home
21:10:12 <smooge> skvidal downloaded the channel and it looked like there were a couple hundred packages updated.. but not much new
21:10:22 <skvidal> more than couple hundred
21:10:26 <skvidal> 900 pkgs for x86_64
21:10:29 <skvidal> and 517 for i686
21:10:38 <skvidal> or thereabouts
21:10:56 <smooge> skvidal, I am an astro-physicist .. I am within an order of magnitude :)
21:11:03 <skvidal> :)
21:11:06 <skvidal> excellent, sorry
21:11:07 <skvidal> carry on
21:11:08 <skvidal> :)
21:11:38 <smooge> so within our 10^2(+/-1) package changes there will probably be some additions.
21:12:10 <smooge> I am going to get that list dealt with this weekend and see what got dropped to
21:12:23 <smooge> the ppc of course is probably going to be our weird one again.
21:13:06 <smooge> what I would like to do is organize a 'test' day on an off meeting friday.
21:13:23 <smooge> basically install 5.5 and then install epel stuff to see what cracks up or not
21:13:31 <smooge> does that sound workable
21:13:51 <nirik> possibly... nothing should break... ABI should stay the same...
21:13:57 <smooge> correct
21:14:06 <smooge> but well
21:14:25 <smooge> my main worry will be with the FUSE stuff.. and conflicts
21:15:00 <smooge> that kind of testing
21:15:08 <nirik> yeah...
21:15:22 <derks> that sounds more than feasible
21:15:49 <smooge> ok cool
21:16:17 <smooge> well then.. I have a special speaker for the class now.
21:16:29 <smooge> all the way from winter wonderland of Virginia.
21:16:34 <stickster> Well, maybe not so much special as "special K"
21:16:37 <smooge> #topic RH EPEL relations
21:16:42 <stickster> Hi gang
21:16:58 <derks> welcome
21:16:59 <nirik> hi stickster
21:17:05 <tremble> 'lo
21:17:07 <stickster> So I know that a few weeks ago there was some concern about RHN channel content wrt. EPEL.
21:17:26 <stickster> The concern being, are Red Hat maintainers working with EPEL like they should?
21:17:45 <stickster> And what's going to happen come RHEL-6?
21:18:46 <stickster> So several months back, Spot and I worked with some internal folks to make sure that both our new-package and RHEL update processes include checklist items regarding EPEL
21:19:13 <smooge> cool
21:19:15 <stickster> so that engineers inside Red Hat understand they need to be working with EPEL as an upstream
21:19:27 <derks> that's great
21:19:52 <stickster> The unanimous response I got from the folks I talked to was, "Yup, we're doing that now, and will keep doing so"
21:20:18 <nirik> cool.
21:20:21 <stickster> I think there was some discussion, too, about whether the EPEL community needed to be concerned about content beyond the RHEL Advanced Platform (AP) package content
21:20:29 <smooge> yes
21:20:50 <stickster> So I have an answer to that as well, which is "No."
21:20:55 <stickster> :-)
21:21:03 <nirik> great. :)
21:21:05 <stickster> In other words, the policy that you guys have centered on, IIRC, is the right one.
21:21:13 <stickster> Finally, regarding RHEL 6
21:21:22 <stickster> RHEL 6 channel content is not set at this point
21:21:45 <stickster> But at such time as that happens, Red Hat is committed to continuing to work with EPEL as an upstream
21:22:01 <smooge> I have heard it has ponies
21:22:04 <stickster> working with EPEL contributors to manage any changes or transitions that might be involved
21:23:02 <nirik> Cool. If they have questions, the epel-devel list is the best communications channel...
21:23:09 <stickster> nirik: Precisely
21:24:33 <stickster> That's all I have unless there are quesetions
21:24:35 <stickster> *questions, even
21:24:36 <stickster> <eof/>
21:24:55 <smooge> question) how can we work with RH better
21:25:31 <smooge> as in how can we make this a 'relationship' where we are helping each other grow the commons.
21:26:17 <stickster> smooge: I asked about where there was any perceived friction here, and mostly I got "huh?" as a response. In other words, the internal maintainers and other folks look at EPEL as an upstream which is their preferred choice to grow/cultivate packaging of software
21:27:24 <smooge> I think the issue is that we want to make it more of a conversation. Its not as much friction as "oh look they put X in the next release."
21:28:27 <smooge> I am glad the Red Hat engineers are using the work of the EPEL engineers but I want to make sure that we have a partnership (we like this but could you make it more flavorful here?) versus just a customer relationship (you want fries with that?)
21:28:29 <derks> smooge, agreed...  seems we are reacting to RHEL changes (pulling in packages, etc) rather than proactively communicating changes
21:28:30 <stickster> smooge: Right. Always at odds with that is the pressure for Red Hat to be just broadcasting its future product strategies. But I think there's middle ground where for example we could encourage engineers to be co-maintainers
21:28:34 <smooge> does that make sense?
21:29:49 <stickster> smooge: derks: As I said earlier, everyone I talked with is committed to *not* doing that in the future. We've got process in place to discourage it now, too, which helps.
21:30:12 <smooge> yeah.. I don't expect us to know that "next release we will be putting in XYZ-4.3, and taking out A#FD-2.0" before beta testers would.. but a co-maintainership so that "oh we found this helpful at a customer site, but had to change this to make it really work for them." would be nice
21:30:14 * stickster corrects earlier statement -- encourage *more* engineers
21:30:33 <stickster> smooge: Exactly
21:31:08 <stickster> And that's what Spot and I conveyed to the team managers internally -- that EPEL can deliver that value in the same way that Fedora does
21:31:15 <smooge> thanks.
21:31:20 <stickster> To which the unanimous answer was "Yeah! Right on!"
21:31:42 <smooge> well if they need to ask for things.. let them know its ok for them to join :)
21:32:06 <stickster> I think at times we tend to turn up old cruft that creates the perception that people are not communicating -- when it's really just dust bunnies
21:32:41 <stickster> by which I don't mean to minimize issues -- we should continue to open up any communication blockages we find
21:33:06 <smooge> yes understood
21:33:11 <stickster> But what we *shouldn't* need to worry about is that there's anyone unwilling to help!
21:33:27 <smooge> ok cool.
21:33:31 * stickster yields
21:33:41 <stickster> to the gentleman from NM :-D
21:33:48 <derks> i would have thought that more redhat engineers would already be contributers to epel...  is that not the case?
21:34:02 <derks> as in RHEL packagers... also packaging for epel
21:34:21 <stickster> derks: I believe we do. I will certainly continue to stump for even more wherever I can.
21:34:54 <derks> right on
21:35:16 <smooge> ok any other questions at the moment?
21:35:37 <stickster> Thanks for letting me horn into the meeting guys :-)
21:35:38 <smooge> stickster, could you hang on a minute in case someone scrolls up and asks in a couple
21:35:47 <stickster> I'm lurking, no problem
21:35:50 <smooge> ok cool
21:36:06 <smooge> Ok I think I can switch topics to my next one
21:36:35 <smooge> #topic Dead Packages OR No Frozen EPEL (or how to drive dgilmore to distraction)
21:37:06 <smooge> so our long running problem with web applications is reaching the fore as I am trying to make mediawiki a usable package
21:37:14 <smooge> and well it don't upgrade too well
21:37:41 <smooge> and then we have moin, nagios, and a host of other web applications which are making problems
21:38:27 <jds2001> smooge: mediawiki is sorta a known quantity if you will.
21:38:35 <smooge> there are a couple of ideas on how to deal with this
21:38:52 <smooge> jds2001, how so?
21:38:56 <jds2001> there are going to be DB changes at every update, and your installation wont work without them, and they're impossible to automate.
21:39:57 <smooge> yes. its the same with moin and most other opensource db oriented packages I have seen
21:40:18 <jds2001> however, if you just wanna backport security stuff, you could try that.
21:40:25 <jds2001> and stay with one version of the schema.
21:40:31 <jds2001> but that's *hard*
21:40:43 <tremble> That's an understatement
21:41:28 <smooge> s/hard/impossible unless prime developer/
21:41:37 <tremble> "Yeah we know that was a bug, we ended up reengineering that whole chunk"
21:42:20 <smooge> well in the long run we can run for a couple of different strategies:
21:42:42 <smooge> 1) break the customer all the time. [oops you shouldn't make yum update a nightly cron job.]
21:43:08 <tremble> 1) As a sysadmin - please don't do that to me
21:43:17 <smooge> 2) try a packaging schema that puts more work on us but keeps compatible parts together until they EOL
21:43:23 <nirik> 1) this breaks our promise to end users, should be rejected. ;)
21:44:22 <nirik> problem with 2 is that if you have mediawiki and mediawiki2 and mediawiki3... people who are doing new installs will install the oldest one. Also, keeping the old ones around could leave them vulnerable to security issues.
21:44:24 <smooge> 2) has the problem that you need to know not to install mediawiki you need to isntall mediawiki19 and 18 and 16 are security hazards
21:45:15 <derks> so, if we aren't maintaining the original anymore... couldn't it be removed?
21:45:31 <tremble> Except we say we won't
21:45:37 <derks> so if you try to install 'mediawiki'...  fail, yum search would show the alternatives
21:46:13 <tremble> And then you break KS build scripts and annoy us Sysadmins.
21:46:13 <derks> err.... i guess you would still need it there for a mediawiki original user to restore a system
21:46:41 <tremble> It's a shame there
21:46:56 <tremble> 's no clen way to "alais" an RPM for yum
21:47:05 <tremble> alias even
21:47:10 <smooge> 3) break the customer at regular intervals. Have a 'rawhide/slipstream' channel where stuff gets built. Have a regular update timed with upstream sub-releases to move things into a stable channel. Have updates meet old criteria only hit the updates
21:48:09 <smooge> 4) backport fixes to people who pay us to get a stable of developers.
21:48:12 <jds2001> 3) sounds doable, but still not ideal.
21:48:52 <jds2001> but the issue with it is that most people wont upgrade to say RHEL5.5 on the day it comes out
21:49:00 <tremble> 3) feels vile, and kinda breaks the principals.
21:49:05 <jds2001> whereas we'd be rebasing EPEL on 5.5 on that day.
21:49:37 <smooge> jds2001, actually we would time it with that but it doesnt mean we would release on the same day
21:49:59 <nirik> well, why does slipstream need to merge over to stable? can't it stay seperate?
21:50:15 <smooge> I was thinking it would be when the beta comes out you build your stable against that into "testing" and when 5.5 final came out you would build and release say 2 weeks later with that
21:50:31 <smooge> nirik, I was thinking slipstream would be the cherry picker
21:50:42 <smooge> but I stole the name from you so what did you think
21:51:10 <nirik> there should be no need to rebuild against minor releases... upstream promises ABI compatibility (although I know they have broken it a few times)
21:51:11 <smooge> in any case, all the ideas above break some 'principles/promises' people feel the EPEL sig should deliver on
21:52:04 <nirik> yeah, or there is: 5) just don't ship incompatible updates at all as we are doing now... you need to go to another repo to get an updated version. ;(
21:52:09 <smooge> nirik, the idea would be that at the minor editions you could move from say mediawiki-1.5 to mediawiki-1.7
21:52:19 <tremble> Splitting them, like eg unison.  UnisonAB, UnisonCD...  might be the best option
21:53:10 <smooge> it basically is about creating the infrastructure and pain of having a 'Z' channel for epel
21:54:05 <nirik> tremble: thats option 2 above.
21:55:35 <smooge> tremble, the issue is probably the most doable of the 5
21:56:10 <nirik> the pain there is making them so they can parallel install.
21:56:28 <jds2001> why would you?
21:56:29 <nirik> and getting them reviewed, etc.
21:56:43 <smooge> I just want to get them all listed for people to mull over and then working on a document for Dummies like me to follow to do parallel installs
21:56:45 <jds2001> i would expect mediawiki15 and mediawiki17 to have file conflicts.
21:57:02 <tremble> Same here
21:57:20 <nirik> well, in the case of say rdiff-backup you wouldn't.
21:57:24 <smooge> the issue would be when you need mediawiki15 to dump stuff for mediawiki17 to update
21:57:31 <nirik> you want both versions because they can talk to other versions.
21:57:50 <nirik> also, packages are supposed to "avoid conflicts whenever possible" :)
21:58:09 <jds2001> sure, but we could make an exception here.
21:58:34 <jds2001> rdiff-backup is a special case.
21:59:18 <jds2001> where someone needs to figure out what to do :)
21:59:43 <nirik> I guess I would like to see if the FPC would be ok with us doing this... conflicts suck. ;(
21:59:46 <tremble> To be fair, paralell installs may well be the better option, and with web apps it's less of a nightmare than many options.
21:59:48 <jds2001> but in general, I think conflicts are OK in this particular problem space.
21:59:54 <smooge> jds2001, I will be honest to say I don't know how many of these packages are going to eb "special" cases
22:00:19 <tremble> RT fits into that category too.
22:00:31 <smooge> for moin I know its a special case as you need the old toy to get the new one to work
22:00:59 <nirik> The error you get from yum/pk when you try and install a conflicting package is not good.
22:00:59 <jds2001> to what end? Can't you just install a new version and run the db migration script?
22:01:40 <tremble> Actually RT comes with POST install update scripts.
22:01:58 <jds2001> right, that's sane.
22:04:10 <nirik> perhaps we could compile a list of these items so we know what option might be best?
22:04:25 <smooge> ok
22:04:28 <nirik> nagios 3, rdiff-backup 1.2, mediawiki, ... ?
22:04:32 <smooge> moin
22:05:00 <smooge> actually I am trying to think of a webapp+db that doesn't have a problem
22:05:35 <nirik> wordpress/wordpress-mu sorta... but they are a mess.
22:06:33 <nirik> so, all options kinda suck. ;)
22:07:29 <smooge> now speaking about how to handle this using option 2
22:07:51 * derks sees why RHEL doesn't package web apps
22:08:18 <smooge> I would like to work with FESCO on seeing if we can make this a general 'policy' if they so wish. I remember when we talked about this in 2008? that people wanted us to look at it first as we were a smaller sample than all of Fedora
22:08:40 <smooge> oh and for nonwebapps
22:08:43 <nirik> I would think FPC would be the better place to start the dialog...
22:08:50 <smooge> snort and clamav
22:09:00 <smooge> nirik, sorry I forgot about FPC
22:09:08 <derks> so i have an idea
22:09:12 <smooge> I couldn't remember which one went away a while back
22:09:15 <derks> ..... regarding #2
22:09:50 <derks> mv mediawiki -> mediawiki1 (or whatever)... it obsoletes mediawiki... then sometime after introduce the new mediawiki
22:10:15 <derks> or introduce mediawiki2, and have mediawiki just be a metapackage that requires mediawiki2
22:10:40 <derks> while mediawiki1 just stays stagnent (cause it obsoleted all the old mediawiki users)
22:11:02 <tremble> Trouble with it being a metapackage is that when you update it, it'll try to update the dependancy.
22:11:16 <smooge> and you can't confirm that people caught the earlier update
22:11:25 <nirik> the other problem with this is "some time" is impossible to judge. ;(
22:11:44 <derks> smooge, no you can't.  but how can you really account for that if people aren't updating after say...  a month?
22:11:46 <tremble> And would probably want to be a major EL version increment
22:12:02 <maxamillion> sorry I'm late :(
22:12:14 * derks looks at watch
22:12:28 <smooge> you're fired
22:12:34 <maxamillion> oh noes!
22:12:37 <maxamillion> >.>
22:12:53 <smooge> oh wait.. I can't fire a volunteer. Ok you are getting a pay cut
22:13:07 <maxamillion> LOL
22:13:08 <smooge> anyway. we are still discussing the same thing we have been doing for a while
22:13:11 <tremble> 50% of your EPEL salery ?
22:13:24 <maxamillion> tremble: meh, 50% of 0 is still 0
22:13:35 * tremble winks
22:14:26 <maxamillion> No Frozen EPEL ... lets do that
22:14:28 <derks> this is the one area i actually like satellite server over just yum repos....  you can query satellite for boxes running XYZ package
22:14:48 <maxamillion> derks: ooo, that's cool
22:15:03 <maxamillion> derks: we don't have satellite in production yet, still have a lackie working on it
22:15:04 <smooge> yeah.. something I am not sure people would allow us to update their systems for them :)
22:15:10 <derks> then we just upgrade those boxes manually... of course those boxes are our customers, and not random people on the internetz
22:15:16 <maxamillion> smooge: pffft
22:15:32 <tremble> I wonder if we might want to work with the RPM/YUM developers and see if they can think of a way to implement metapackages where the meta package doesn't get installed
22:16:00 <derks> tremble, so what was the problem with dependencies you were saying?
22:16:30 <derks> say if mediawiki is a metapackage that requires: mediawiki2
22:16:40 <tremble> Run yum update
22:16:53 <tremble> It'll update the metapackage to the latest version
22:17:04 <tremble> Which then requires mediwiki3
22:17:10 <skvidal> tremble: that's call a group
22:17:24 <derks> oh
22:17:25 <skvidal> tremble: and if you don't install the metapackage then how would you know to update it later?
22:17:27 * nirik doesn't see how metapackage or groups help.
22:17:27 <derks> yep
22:17:39 <nirik> I guess for the 'default new people installing X'
22:17:54 <tremble> You wouldn't, the real package would have been installed and that would get updated
22:18:02 <derks> skvidal, it wouldn't need to be updated (the metapackage)
22:18:16 <skvidal> derks: if you want to add a new pkg to the metapkg of course it would
22:18:27 <skvidal> otherwise how would the users get the new pkg?
22:18:40 <derks> its only purpose would be to link you to the latet version of X package
22:18:49 <derks> more like an alias
22:18:53 <tremble> yum install mediwiki3 (obseletes mediawiki2)
22:19:03 <derks> 'yum install mediawiki' is interpretted as 'yum install mediawiki2'
22:19:23 * maxamillion is now confused
22:19:25 <skvidal> umm
22:19:26 <smooge> skvidal, I think what he is looking at it is the evil step-dad of groups from back in the day. package base requires glibc, blah blah blah so you install base and get a base system
22:19:30 <skvidal> you know how provides work, right?
22:19:33 <derks> tremble....  you can't obsolete mediawiki2 via the package though
22:19:43 <skvidal> yum install foo
22:19:46 <skvidal> if there is no pkg named foo
22:19:49 <skvidal> then yum looks at provides
22:19:52 <skvidal> to see what provides foo
22:19:55 <skvidal> and installs that
22:20:02 <smooge> what id multiple things provide foo?
22:20:13 <skvidal> it uses compare_providers to see which one is 'best'
22:20:35 <derks> you know, i didn't think about that if....  the package doesn't exist
22:21:45 <smooge> skvidal, here is what I am trying to 'solve'. Currently updating mediawiki in enterprise sucks. So I want to replace mediawiki with mediawiki15 which would provide mediawiki and I want mediawiki19 to provide mediawiki too.
22:22:04 <smooge> I want people who have the old mediawiki to stay on mediawiki15 and the ones who want mediawiki19 to get that.
22:22:11 <smooge> I don't know how to do it withiout pain
22:22:16 <smooge> does that make sense
22:22:58 <skvidal> umm
22:22:58 <skvidal> yah
22:23:00 <skvidal> good luck
22:23:01 <derks> from what skvidal is saying, if mediawiki15 obsoletes mediawiki.... and then we remove mediawiki from the repos....  if a user does 'yum install mediawiki' they will get the latest based on compare providers
22:23:19 <skvidal> even if you don't remove it
22:23:24 <skvidal> yum won't install an obsoleted pkg
22:24:11 <smooge> yeah that is what I thought.
22:25:44 <smooge> heck I am not sure what I would have to do with it package wise (eg do I make a new package called mediawiki15 and go through approval process or do I do some cvs magic to subbranch it from mediawiki
22:25:45 <skvidal> it's silly to do so
22:25:52 <skvidal> the next update run will remove the obsoleted pkg
22:26:08 <skvidal> smooge: what is it you want users to be able to do?
22:26:16 <skvidal> yum install mediawiki and have it what?
22:26:21 <skvidal> magically work?
22:26:25 <smooge> ok we have issues that most web applications do not upgrade sanely without manual work
22:26:59 <smooge> actually I want it so that if they had the old mediawiki installed they aren't fucked when they do yum update
22:27:09 <smooge> but get pushed onto a line that works for them
22:27:38 <derks> while new users get the latest mediawiki19
22:27:41 <smooge> if they want to have updates and all that they can manually do it but we aren't screwing them over at 4 am when yum-updatesd runs
22:28:00 <smooge> well personally I don't care if new users have to install mediawiki19 to get the latest
22:28:10 <derks> smooge, neither do i
22:28:25 <smooge> it would be nice that yum install mediawiki worked but hey I can't have ponies with horns
22:28:35 <skvidal> smooge: then here's what you do
22:28:42 <skvidal> whatever pkg you want to be the definitive mediawiki
22:28:48 <skvidal> you make it provide: mediawiki
22:28:50 <skvidal> the other ones don't
22:29:07 <skvidal> so if 19 is the right one - then it Provides: mediawiki
22:29:16 <skvidal> so: yum install mediawiki
22:29:16 <skvidal> works
22:29:25 <skvidal> if you update to mediawiki 22 as the new 'real' mediawiki
22:29:26 <derks> so, it mediawiki15 obsoletes mediawiki... isn't that an implied provide?
22:29:35 <skvidal> derks: then don't have the obsoletes
22:29:46 <skvidal> and no and obsoletes is NOT an implied provide
22:29:56 <derks> ok
22:29:58 <smooge> ok so in our current fucked up state of having mediawiki as a package... put in the obsoletes for a while then remove it later?
22:30:08 <skvidal> yes
22:30:14 <smooge> ok cool.
22:30:19 <derks> i like this
22:30:19 <smooge> I can live with that
22:30:25 <skvidal> but here's the catch
22:30:50 <tremble> Hopefully EL6 will be along soon enough that you make the switch with EL6
22:31:13 <nirik> so in this case what happens with the old mediawiki packages? they just stick around?
22:31:18 <tremble> (removing the obsolete)
22:31:29 <skvidal> nirik: yes
22:31:57 <nirik> unmaintained, unloved, possibly insecure?
22:32:02 <derks> skvidal, wouldn't compare_providers pick the package named mediawiki over one that provides it
22:32:28 <derks> i remember having these issues with the IUS project and going through similar loops as this
22:32:35 <smooge> nirik, as far as I can tell thats going to happen.. we can mark them EOL inside or such.. but we either break people, don't ship the stuff, or don't update
22:33:22 <nirik> yeah, there is no good answer.
22:33:24 <smooge> or try to fix things and say "you got this from us. please update to something newer, but if you really need to keep this old one.. here is the code for you to fix."
22:34:09 <smooge> nirik, as far as I can tell we are doing our best. our customers are getting what they paid for, and we can put out stuff that works as best it can
22:34:37 <smooge> and I am not saying paid as in no money.. if they want to help and maintain say mediawiki15 then they can join in
22:34:52 <skvidal> derks: so you're asking me how to unscrew a screwed situation?
22:35:04 <skvidal> derks: you ask about REMOVING the mediawiki pkg from the repos
22:35:24 <derks> skvidal, right... that is where i was confused. you just said to leave it
22:36:40 <derks> in which case, base on the way i understand compare_providers, the package named mediawiki would win out over mediawiki19 that provides it.  i just wanted to clarify... I would image it would be better to remove the original mediawiki package
22:36:58 <derks> ... from the repo
22:38:07 <skvidal> or start some other scheme
22:38:26 <smooge> irc conversations tend to lead to misparsing at times :)
22:38:42 <smooge> I think we need to write up a guideline and mail it to the list.
22:38:53 <smooge> then try it out with mediawiki and then go from there
22:39:00 <smooge> does that sound good?
22:39:18 * tremble nods at smooge
22:39:24 <derks> i think that would be best
22:39:28 <smooge> any others?
22:39:38 <smooge> thank you very much for your advice skvidal
22:40:04 <skvidal> np
22:40:08 <derks> agreed, thank you
22:40:36 <nirik> smooge: I would say write it up and ask packaging list for feedback...
22:40:51 <nirik> see if they think of problems or come up with a more clever way to do things.
22:41:09 <smooge> ok. I will do so and have it ready for next weke
22:41:15 <smooge> which list?
22:41:46 <nirik> packaging@lists.fedoraproject.org I think it is.
22:42:16 <smooge> ok thanks
22:42:37 <smooge> alright I think we have filled our hour with a lot of stuff and our borrowed 42 mnutes with even more
22:42:49 <smooge> does anyone have any open items?
22:42:56 <smooge> #topic Open Floor
22:43:21 * nirik has nothing.
22:43:32 <smooge> ok then I will close in 60 seconds
22:44:18 <smooge> thank you all for coming. see you in two weeks
22:44:21 <smooge> #stopmeeting
22:44:49 <smooge> #endmeeting