21:00:02 <nirik> #startmeeting EPEL meeting
21:00:02 <zodbot> Meeting started Fri Sep 18 21:00:02 2009 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:07 <nirik> #topic init process
21:02:00 * nirik waits around for anyone to arrive for the meeting.
21:02:53 * stahnma is here
21:03:03 <derks> sorry... was in the wrong channel.  here for epel
21:03:14 * nirik needs to step away for just a minute...
21:03:29 * rayvd is here sorta
21:04:18 * maxamillion is here
21:06:34 <nirik> sorry about that. ;(
21:07:08 <maxamillion> nirik: no worries
21:07:10 <maxamillion> :)
21:07:10 <nirik> #topic Status update on action items
21:07:24 <nirik> well, both our folks with action items are not here. ;(
21:07:28 <nirik> so, I guess we will move along. ;)
21:07:31 <maxamillion> I had one didn't I?
21:07:45 * nirik doesn't remember. oh yeah, iotop
21:07:49 <derks> maxamillion: yeah, about iotop
21:07:51 <nirik> whats the status on that?
21:08:12 <maxamillion> email sent, still waiting on response from upstream but there was someone else who posted to the mailing list saying they've been playing with it
21:08:17 <nirik> #topic Action item: iotop
21:08:24 <derks> nirik: seems to me we'd have to backport the _netlink implementation from Python 2.5
21:08:48 <nirik> yeah... sounded like some 2.5 specific module there.
21:09:01 <maxamillion> derks: question would be ... how hard would that be to implement?
21:09:10 * maxamillion hasn't looked at it
21:09:14 <derks> iotop references some mythical _netlink C module outside of python 2.5, but i couldn't find anything on it
21:09:17 <nirik> maxamillion: is the fedora iotop maintainer involved? or just upstream?
21:09:34 <derks> maxamillion: didn't have a chance to dig through the Python 2.5 code to consider it yet
21:09:35 <maxamillion> nirik: just upstream so far, I can ping the fedora iotop maintainer also
21:09:43 <nirik> he might know more...
21:10:01 <maxamillion> derks: might be something we could just compile and make a python24-netlink package or something
21:10:07 <maxamillion> just a thought
21:10:14 <derks> certainly
21:10:15 <maxamillion> .whoowns iotop
21:10:16 <zodbot> maxamillion: drago01
21:10:39 <maxamillion> pinging him now in #fedora-devel
21:11:10 <nirik> ok, cool.
21:11:26 <drago01> hi
21:11:43 <maxamillion> he was already here, I just failed to look at the channel list
21:11:57 <drago01> the only thing that is blocking iotop where the kernel and python
21:12:02 <drago01> kernel is fixed now
21:12:04 <nirik> #topic Action item: fuse
21:12:14 <rayvd> good timing...
21:12:33 <rayvd> sent out the email to all fuse package maintainers in rawhide inviting them to branch for epel
21:12:44 <maxamillion> drago01: right, and we were talking about backporting the _netlink function that it appears to rely on in python2.5 and make a python24-netlink package or something similar
21:13:00 * nirik got a net lag here. Sorry, would have left it on the old topic, but thought we were done.
21:13:10 <nirik> rayvd: any responses so far?
21:13:39 <drago01> maxamillion: yeah or let iotop dlopen libnl
21:13:42 <rayvd> got one.. don't recall which package off the top of my head, but the user was willin to let someone comaintain it in epel
21:13:55 <rayvd> do we want to go further than just blasting out the email?
21:14:13 <rayvd> we could open bz tickets for each
21:14:24 <rayvd> or track via the wiki
21:14:25 <nirik> rayvd: cool. I would say lets wait with that for now, but move on to branching/finding maintainers if people don't respond by the time centos 5.4 comes out.
21:14:26 <maxamillion> drago01: would that be something that would be an "easy" patch?
21:14:32 <rayvd> alright.
21:14:49 <drago01> maxamillion: actually I have not looked into it
21:14:50 <nirik> rayvd: thanks for mailing them. ;)
21:15:01 <rayvd> np!
21:15:28 <drago01> maxamillion: but such a patch would never go upstream so I doubt it is the right thing to do
21:15:32 <maxamillion> drago01: I haven't either in all honesty, its just kind of an idea gathering phase right now I suppose ... need to pick a plan of attack
21:16:15 <maxamillion> drago01: right, I have emailed upstream asking for guideance (sp?) in the concept of backporting to RHEL5 but still haven't gotten a response
21:19:38 <maxamillion> drago01: because while I don't want to deviate from upstream, its most likely going to be required in one way or another and if need be I'd like to make the differences as minimal as possible
21:22:54 <nirik> ok, any other action items?
21:24:08 <nirik> #topic newer packages brainstorming
21:24:18 <nirik> so, I thought we could revisit this a bit from last meeting...
21:24:28 <nirik> subtopics I had:
21:24:40 <nirik> What can we do to help efforts like http://iuscommunity.org? and Should we try and bring an effort like this into EPEL infrastructure?
21:25:37 <maxamillion> I don't necessarily know that we should do it within EPEL, I think those who are interested should just show support for iuscommunity
21:25:40 <derks> nirik: i'm curious how would updates be maintained via that route?  following upstream source?
21:25:42 <maxamillion> but that's just my opinion
21:26:06 <derks> I (IUS) follow every upstream source release
21:26:14 <derks> and backport or upport changes as necessary
21:26:40 <derks> like redhat/fedora patches.
21:26:44 <nirik> yeah, I would say upstream stable releases...
21:27:09 <nirik> unless you think picking one and backporting only bugfixes/security is possible... but then you run into it possibly getting too old
21:27:31 <derks> i was thinking another way to do it would be to follow package releases for versions of fedora...  and follow fedora changes... but personally, from my experience people start asking for the latest source version soon as its out
21:27:52 <maxamillion> I don't know that I'd want to get ahead of Fedora
21:27:56 <derks> so FC12, follow php5X for that, FC13... etc...
21:28:00 <derks> but i think it would be messy
21:28:00 <maxamillion> Fedora's pretty cutting edge as it goes
21:28:39 <nirik> yeah... could get messy. ;)
21:28:46 <derks> a bit of history: we started IUS specifically due to the demand for customers wanting the latest from upstream
21:29:01 <nirik> derks: have you had folks that have asked for newer than what you have?
21:29:17 <derks> being that its been mostly me tracking PHP/MySQL for 3 years...  it was also easier to follow upstream source rather than backport changes
21:29:32 <derks> nirik: like what in particular?
21:29:39 <derks> mysql 5.4?
21:29:50 <derks> (which is still beta)
21:30:10 <maxamillion> wow
21:30:17 <maxamillion> people want beta on their production servers?
21:30:19 <nirik> yeah, I guess in the time you have been doing it, has upstream had a major release? and if so, have you followed that, or just left it on the older version?
21:30:21 * maxamillion doesn't understand
21:30:35 <derks> Occasionally we'll have someone wanting something...  internally we still haven't release php 5.3 (but IUS has it)
21:30:54 <derks> every stable, active branch
21:31:03 <derks> started at php-4.4.x
21:31:11 <derks> then PHP 5.1.x
21:31:18 <derks> then PHP 5.2, then eol'd php-4
21:31:20 <derks> etc..
21:31:31 <nirik> so do you only keep the newest one there? or all of them?
21:31:38 <derks> so the goal is to maintain the branches people want/need as long as they are actively maintained upstream
21:31:49 <maxamillion> derks: solid goal imho
21:31:51 <derks> all of them
21:32:01 <derks> we can based on the packaging scheme
21:32:07 <derks> php52, php53, mysql50, mysql51
21:32:09 <derks> all in one repo
21:32:12 <derks> conflicting
21:32:39 <derks> with that scheme, you can have beta packages introduced
21:32:48 <nirik> so are all those supported upstream? ie for a php52 security issue, would they issue a patch/release, or tell you to upgrade to 53?
21:32:50 <maxamillion> derks: so you do leave them conflicting?
21:32:54 <derks> becuase it won't do anything unless you remove a previous version and replace it
21:33:01 <maxamillion> ah, ok ... nice
21:33:03 <derks> maxamillion: yes, conflicting
21:33:26 <maxamillion> derks: awesome, that way someone can't shoot themselves in the foot
21:33:39 <derks> hah... yep
21:33:47 <derks> but they have to do it to themselves.
21:33:48 <derks> ;)
21:33:50 <derks> Provides:  %{real_name} = %{version}-%{release}
21:33:50 <derks> Conflicts: %{real_name} < %{basever}
21:33:52 <derks> Conflicts: php51, php53
21:34:07 <derks> that is from php52
21:34:08 <maxamillion> awesome
21:34:39 <maxamillion> derks: now if you introduce a new one php54 will you have to retroactively go back and add it as a Conflicts to all the others and rebuild?
21:34:43 <derks> nirik: yes..  php 5.2, and php 5.3 are still actively maintained upstream
21:35:14 <nirik> so when they are not do you just remove them? or put in a obsoletes/provides to get people to go to the supported one?
21:35:15 <derks> maxamillion: you can, but I think as long as the latest package has the proper conflicts you'll be ok
21:35:41 <derks> nirik: haven't gotta that far yet.
21:35:52 <derks> php 4 is the only thing i've eol'd
21:36:13 <derks> but internally, we have a different scheme (rhn satellite channels rather than one repo... and the packages don't conflict)
21:36:15 <nirik> yeah, letting people know something is EOL is not easy.
21:36:35 <derks> nirik: this is something i need to figure out.  ;)
21:36:52 <nirik> yeah, there is no magic answer I don't think. ;(
21:36:53 <derks> but i don't think having php53 obsolete php52 will ever be preferred
21:36:58 <maxamillion> derks: makes sense
21:37:24 <nirik> yeah, sometimes that would be very bad (break apps, etc)
21:37:38 <derks> perhaps adding something to ius-release... a cronjob check that emails root saying 'XXX package is no longer maintained'
21:37:43 * derks shrugs
21:38:00 <nirik> ok, not sure I had anything more for this, just thought we could discuss it a bit more. ;)
21:38:22 <derks> nirik: I'm available for more discussion anytime
21:38:35 <nirik> cool.
21:38:47 <derks> i like the idea of possibly moving it next to epel if there was enough buy in, just not sure it fits there
21:39:03 <maxamillion> mailing list is good too ... my schedule is unstable but I always check my email at least 2 or 3 times a day
21:39:06 <nirik> yeah, not sure either. There are tradeoffs either way.
21:39:27 <nirik> but I think for now, we are happy to let you run with the ball and see where we end up. ;)
21:39:39 <derks> I imagine things will move forward as there are for the near future... so i need to get koji setup soon
21:39:41 <maxamillion> would it be worth considering migrating ius into a subproject of EPEL?
21:40:04 <nirik> maxamillion: thats what we were talking about... but it's not clear thats a good idea right now at least...
21:40:18 <maxamillion> ah, ok ... I misunderstood
21:40:30 <derks> maxamillion: I think the EPEL name would be confusing based on the packaging guidelines that conflict with IUS
21:40:44 <derks> i.e. not replacing RHEL packages
21:40:47 <derks> not sure
21:40:48 <maxamillion> right
21:41:17 <nirik> yeah, we would need different guidelines... and we could confuse EPEL users.
21:41:24 <derks> either way, I want it to be as open and useful as possible... so any suggestions are welcome...  be it hosting myself, or merging into a fedora-ish project
21:41:27 <maxamillion> well then maybe migrate IUS into a sub project of Fedora? just like EPEL is ... have it "sit next to EPEL" instead be a subproject of
21:41:35 <nirik> on the other hand, it would allow community to be involved and use the already existing infrastructure.
21:42:07 <derks> nirik: the infrastructure is definitely the big piece... and maxamillion: I would say IUS would be next to EPEL... under fedora
21:42:32 <nirik> yeah.
21:42:39 <derks> any idea how involved that would be?
21:43:14 <maxamillion> so ... maybe start a wiki page to put together some planning bits and then file a ticket with infrastructure team to add it to koji and as a repo?
21:43:26 <maxamillion> file the ticket once all the planning is done*
21:43:29 <nirik> if we wanted it to be another Fedora subproject, I guess you would need to write up a proposal for it... (what resources would you need? how much work? what policies do you have? etc)
21:43:51 <nirik> maxamillion: I would say it would at least need to get approved by FESCo, and possibly the board...
21:44:03 <derks> nirik: that makes sense.  I have documentation i've been working on since inception, hoping to get that online soon.
21:44:17 <derks> regarding packaging guidelines and such
21:44:18 <nirik> a wiki page might be good... could also ask people to note there that they would be interested in helping.
21:44:23 <maxamillion> nirik: ah yes, definitely FESCo
21:44:33 <maxamillion> I kinda missed a step there :/
21:45:17 <nirik> derks: if you want to look at putting something like that together I'd be happy to review it/provide feedback. ;)
21:45:31 <derks> really, as far as our 'corporate needs' i think our ideas all align... so we still get the results from the 'community' we need
21:45:43 <derks> we i mean my company
21:46:08 <maxamillion> rgr
21:46:10 <derks> nirik: thanks, I will certainly get with you on that
21:46:11 <nirik> yeah... good when everyone is moving the same way and can help each other out. ;)
21:46:21 <maxamillion> Its really nice to see companies reaching out to the community
21:46:30 <nirik> ok, shall we move along then? or anything further on this topic?
21:46:44 <derks> nirik: not from me
21:46:44 <maxamillion> nope, pretty good over here
21:46:50 <nirik> #topic Open Floor
21:46:54 <nirik> the floor is open! :)
21:47:01 <maxamillion> uhhhmmm
21:47:01 <derks> i have something....
21:47:05 <derks> well, question..
21:47:08 <maxamillion> shoot
21:47:19 <derks> a while ago on the list was the discussion of moin -> moin18
21:47:27 <derks> i guess that is smooge's action item?
21:47:38 <derks> err... jds2001
21:47:45 <derks> incompatible version upgrades
21:47:49 <maxamillion> yeah, he's out today
21:48:03 <maxamillion> incompatible version upgrades is a tough one
21:48:19 <derks> Ok...  was wondering if there was anything i could help with... cause I really need an updated moin and would prefer it to go through epel
21:48:46 <nirik> well, we were waiting for a writeup on the policy to vote on/tweak.
21:48:55 <derks> OK...  I'll wait for that.
21:49:12 <derks> Maybe I can just submit a src.rpm to bugzilla with whatever I come up with
21:49:14 <nirik> I think we had decided in some cases it was ok to do an incompatible version, but we would want to announce it, allow for time, etc.
21:49:17 <derks> should it be needed in the future
21:49:29 <derks> nirik: makes sense
21:49:40 <nirik> it's pain, but in some cases, such is life. ;(
21:50:01 <nirik> I assume the moin in epel not won't upgrade to 18 without tweaking?
21:50:24 <derks> right...  i'm more concerned with starting with moin18 than upgrading
21:50:36 <derks> hense the conflicting package
21:51:01 <nirik> yeah.
21:51:15 <derks> if that is something we can do through EPEL then you can really add a lot of new packages...  if not, i guess IUS can replace EPEL packages too.  ;)
21:52:15 <nirik> yeah, not sure we want to do that. I think we agreed to allow some cases of incompatible upgrades... which would allow old moin in epel to update to 18
21:52:29 <maxamillion> think that could cause an issue if IUS were to also be a Fedora project in the long run ... don't want to run over our own repos ;)
21:52:31 <derks> via Obsoletes?
21:52:50 <derks> maxamillion: agreed
21:53:32 <nirik> derks: no, just a update... moin-1.5.9-1.el5 -> moin-1.8.5-1.el5 (but we would need to make sure the case was compelling to break older installs)
21:53:42 <nirik> a better case is nagios.
21:53:49 <derks> nirik: right on... i see what you mean
21:54:01 <nirik> nagios is 2.x in epel... which is not supported upstream anymore.
21:54:28 <derks> nirik: I can see that being a nightmare to educate the EPEL user community on
21:54:29 <nirik> or rdiff-backup... 1.0.5 is in epel, but 1.2.x is stable now upstream and they can't talk to each other. ;(
21:54:43 <nirik> yeah, we have an announce list, but not sure how much it is known.
21:55:19 <nirik> anyhow, I guess we should close up for this week... unless someone has anything else?
21:55:20 <derks> Well... what about patching moin-1.5.9
21:55:25 <derks> to have a warning banner
21:55:26 <derks> ;)
21:55:33 <maxamillion> nirik: is FESCo or $other working to resolve the policy on these types of upgrades?
21:55:43 <nirik> yeah, possible I guess... but thats going to be case by case if it works with a specific app
21:56:27 <nirik> maxamillion: no, this is a epel issue. In fedora the maintainer can just upgrade on a release boundry... which is every 6 months, not every 3 years.
21:56:54 <nirik> ie, we could update moin for RHEL6... ;) but that doesn't help the 5 people wanting a newer version now.
21:57:55 <derks> can't win them all
21:58:10 <nirik> ok, I am gonna close out the meeting now... feel free to continue discussion over in #epel. ;)
21:58:18 <nirik> thanks for coming everyone.
21:58:22 <derks> nirik: thank you
21:58:36 <nirik> #endmeeting