21:00:00 <nirik> #startmeeting EPEL Meeting
21:00:00 <zodbot> Meeting started Fri Oct  2 21:00:00 2009 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:06 <nirik> #topic Init process
21:00:43 * jds2001 here
21:00:44 * derks is here
21:01:49 * nirik will wait a few more minutes for folks to wander in.
21:02:03 * wolfy is here, but for lurking purposes only
21:03:14 <nirik> smooge / rayvd: you guys around today?
21:04:19 <smooge> I am here
21:04:36 <nirik> cool.
21:04:41 <nirik> lets go ahead and get started.
21:04:41 <smooge> I am working on getting downloads of DVDs of CentOS and 5.3/4.8/5.4 of RHEL to comapre RPMS
21:04:49 <nirik> #topic Old action items
21:04:52 <smooge> been dealing with cold
21:05:14 <nirik> smooge: ok, so you should be able to generate a full list then? I guess go to the list with the list. ;)
21:05:30 <smooge> yes. I will generate the list and go to the list
21:05:57 * Jeff_S here now
21:06:03 <smooge> it will show whats different between CentOS/RHEL (as in -devel or other packages missing) and what is different between 53./54
21:06:04 <smooge> hello Jeff_S
21:06:10 <Jeff_S> hi
21:06:14 <smooge> hello spoleeba
21:06:14 <nirik> hey Jeff_S
21:06:21 <nirik> ok, sounds good.
21:07:02 <nirik> #topic Incompatible upgrades policy
21:07:16 <nirik> ok, so jds2001 posted a draft to the list.
21:07:18 <jds2001> so I posted a draft to the list earlier today
21:07:27 <jds2001> sorry that took so long :(
21:08:05 <jds2001> is it along the lines of what people were thinking, or am I out in left field?
21:08:19 * nirik re-reads
21:08:21 <Jeff_S> I haven't had a chance to read that yet
21:08:41 <smooge> rereass
21:08:49 <smooge> rereads that is
21:09:13 <jds2001> https://fedoraproject.org/wiki/EPEL_incompatible_upgrades_policy btw
21:10:17 <nirik> I think we should add a section noting the normal 2 weeks in testing (or perhaps it should be longer)?
21:10:40 <derks> I would vote that it should be longer if it is expected to break existing installs
21:10:48 <nirik> perhaps: build -> testing -> send email to announce -> push stable -> another email to announce
21:10:54 <Jeff_S> I don't see a reason to require a long testing period.  Isn't that was the pre-discussion is about?
21:10:57 <Jeff_S> (partly)
21:11:13 <nirik> well, it needs to be at least 2 weeks per our normal policy.
21:11:16 <Jeff_S> yes
21:11:22 <jds2001> a little bit, but it needs to be tested too
21:11:37 <nirik> and that might give people enough time to notice it on announce before suddenly getting hit with it.
21:11:42 <nirik> (in stable)
21:12:23 <jds2001> and other communications methods are welcome too, I should put that announce is all that's required, but to blog/tweet/dent/send to other relevant ML's/deliver to users via carrier pidgeon
21:12:37 <jds2001> if you can do any of that
21:12:50 <smooge> I think that 2 weeks and at least 3 announcements after its been "okd"
21:13:02 <inode0> Anyone know if there is a similar policy for RHEL itself?
21:13:04 <derks> smooge: that sounds good
21:13:13 <Jeff_S> inode0: I think RHEL does wtf they feel like... ?
21:13:22 <jds2001> inode0: i think it's "dont do that"
21:13:25 <Jeff_S> *surprise*
21:13:44 <smooge> As in "I am putting it in testing", "Its been in a week and no-one has emailed me", "Hey tomorrow its going live, don't email me when it eats babies."
21:13:49 <inode0> well, speaking as customer I prefer don't do that as the policy :)
21:13:49 <jds2001> inode0: they'll upgrade desktop apps for example that have low risk of breakage.
21:13:54 <derks> inode0: I don't think incompatible upgrades would be allowed
21:14:12 <derks> in rhel
21:14:13 <nirik> firefox got updated...
21:14:17 <smooge> inode0, the general RHEL policy is "Put it in the beta release notes" and "tell customers not to autoupgrade the day the new release comes out."
21:14:45 <inode0> there is a big difference between upgrading because customers demand newer versions and this
21:14:47 <Jeff_S> smooge: so you are suggesting we request (require?) an email to the list:  1) before discussion; 2) after it goes to testing; 3) when pushing to stable
21:14:57 <derks> nirik: well.. i guess it depends on the package really.  IMHO I could care less if FF broke... but apache/mysql/php/etc...
21:15:10 <nirik> I think we should at least have 2 announcements... 1) when the package is built and going to testing (hey, heads up), and 2) when it's going to go to stable (it's happening, get ready)
21:15:13 <smooge> Jeff_S. yes
21:15:18 <jds2001> inode0: i wanted to avoid "customers demand newer version" with this policy
21:15:42 <nirik> derks: sure, but it's happened with less exciting/popular/used packages.
21:15:44 <smooge> I am going to be a test case soon (real soon).
21:15:45 <inode0> so would I, and I'm not interested in what Red Hat does in that case either
21:15:47 <derks> Also on the note of RHEL policy, I am fairly confident that our TAM would notify us of such an update
21:16:09 <nirik> smooge: for what use case?
21:16:11 <smooge> mediawiki in EPEL has issues and my trying to backport fixes was a mess. And they don't support it anymore
21:16:13 <jds2001> not all customers have TAM's
21:16:23 <jds2001> I do too, but not everyone does.
21:16:33 <derks> jds2001: I know...
21:16:33 * maxamillion is here ... sorry (just got out of $dayjob meeting)
21:16:59 <nirik> well, I know we have a few packages waiting for this. I have rdiff-backup as well.
21:17:07 <smooge> so a newer version has to go in, but it has a different schema
21:17:54 <jds2001> so what's the deal with rdiff-backup?
21:18:15 <inode0> any of those intractable security backporting difficulty? or just we want newer stuff now?
21:18:56 <nirik> rdiff-backup: epel has 1.0.5. It's old and no longer supported. Fedora has 1.2.8. They don't interoperate, so you can't backup machines from one via the other. So if you have a rhel backup host you can't backup fedora and such.
21:19:11 <maxamillion> oh ouch
21:19:40 <jds2001> with this policy though as it is, seems that we're stuck.
21:19:45 <smooge> inode0, all my cases are intractable security issues
21:20:12 <smooge> the other point I would look at is where intractable protocol issues come up
21:20:22 * jds2001 not sure how to get un-stuck from that without opening the floodgates.
21:20:26 <nirik> well, we have discussed the policy simply being 'no'. But I think there was enough desire to allow them in rare case by case basis.
21:20:44 <nirik> but yes, where do we draw the line?
21:21:54 <jds2001> so if you have one rhel machine, update it to 1.2.8, it can no longer talk to your other rhel machine too.
21:22:04 <jds2001> that may or may not even be under your control
21:22:48 <nirik> well, if the other rhel machine is using the old version, yeah.
21:22:58 <maxamillion> but if you are in an environment where you have to interoperate then you should at least be able to get in contact with the controller of the other machine
21:23:56 <inode0> I would probably make that change on the fedora side since they would be far outnumbered but ...
21:24:16 <smooge> inode0, do you have a suggestion for this? My original idea was to 'branch' mediawiki and such by name. but that got into other kinds of overhead
21:24:48 <smooge> as in mediawiki114 mediawiki115
21:25:24 <maxamillion> for thinkgs like mediawiki, what exactly is incompatible? is there some sort of conversion process that can be put in a script in %pre ?
21:25:32 <inode0> if it is a security thing though you want the bad one to go away don't you
21:25:32 <derks> smooge: personally I like that idea as it gives the users that are 'in the know' a chance to upgrade manually
21:26:27 <maxamillion> inode0++
21:27:06 <derks> inode: I think it would have to be a conflicting packge, not a parallel package.  a parallel package doesn't solve the problem because the other doesn't go away.. but also the end user will have to migrate data
21:27:11 <smooge> maxamillion, not sure for all cases that the scriptment would work well enough
21:27:41 <smooge> oi
21:28:01 <nirik> the downsides of that: it would confuse the fedora packages since it would be epel only. It would require review (which isn't so bad), and conflicts are to be avoided.
21:28:17 <nirik> have a split. ;)
21:28:37 <jds2001> add to that the fact that in fedora infra (and therefore I suspect many other environments), I have no control of the DB environment, and permissions on the DB are fairly locked down.
21:28:38 * inode0 like parallel installs for feature differences that cause incompatibilities but not so much for insecure versions
21:28:55 <jds2001> So I have to go hunt down somebody, get them to set me up a user with the right perms, and then throw that user into the script
21:29:01 <derks> inode0: agreed, parallel install for security issue would be a bad idea
21:29:03 <maxamillion> jds2001: then maybe write a conversion script and include it in the %doc ?
21:29:05 <jds2001> maxamillion: it's already in the maintenance directory of MW itself.
21:29:09 <maxamillion> oh ... well then
21:29:09 <nirik> maxamillion: still would break installs on update tho...
21:29:10 <jds2001> but it needs to be customized to the site.
21:29:12 <smooge> inode0, the issue that came up was that this was basically redoing various engineering stuff upstream (Fedora) already does and decides on
21:30:14 <maxamillion> nirik: yeah, I know ... but what SLA do we currently have with the EPEL user community? ... we've gotta draw the line at "broke" or "open for blatant security breach"
21:30:23 <smooge> inode0, I am not against it myself.. it was more of how much trouble does it cause reviewers and standards
21:30:36 <nirik> so, where do we draw the line here? or do we do case by case?
21:31:03 <maxamillion> I honestly think it needs to be a written policy, case by case can get complicated
21:31:41 <nirik> ok, then whats the policy? security only? incompatible protocols? no longer supported upstream? shinyer ?
21:32:12 <derks> nirik: maybe a check list?  If X, and Y, and Z... AND it's approved by EPEL SIG then yes
21:32:29 <inode0> you can make a case for all those, but I really like to limit the shinier to desktop stuff
21:32:30 <derks> i'd say security
21:32:44 <maxamillion> I don't think shinyer should be sole merit for an upgrade if the version is still supported and the shinyer version breaks things on upgrade
21:32:45 <derks> is a 'we have no choice' situation
21:32:45 <jds2001> i dont think that no longer supported upstream really matters, except for security
21:32:55 <maxamillion> derks: agreed
21:33:02 * inode0 wants rdiff-backup or similar to work for the duration as it does today
21:33:09 <maxamillion> jds2001: right, that's essentially what I mean by no longer supported upstream
21:33:32 <maxamillion> inode0: is it vulnerable to some security exploit that is known?
21:33:36 <jds2001> right, but if there's no known security vulnerability in them, then who cares?
21:33:42 <nirik> ok, so security thats difficult/impossible to backport seems fine.
21:33:46 <derks> My thought is:  If it is non-backportable security then do the update as outlined above.  If it is just feature compatibility then create a parallel package
21:33:48 <inode0> maxamillion: is what?
21:33:51 <maxamillion> jds2001: right, if there is no security issue then upstream doesn't matter
21:33:53 <nirik> what about incompatible protocols?
21:34:02 <maxamillion> inode0: rdiff-backup
21:34:09 <inode0> not that I know about
21:34:24 <maxamillion> nirik: I think incompatible protocols should be viewed as "breaks things"
21:34:30 <nirik> maxamillion: not that I know of either off hand.
21:34:35 <jds2001> tjat
21:34:46 <jds2001> that's a tough one though
21:34:56 <jds2001> what if someone is depending on the old protocol?
21:35:18 <maxamillion> jds2001: exactly, makes it a "breaks things" situation
21:35:31 <inode0> If I build an enterprise infrastructure using EPEL don't we all want that infrastructure to be as close to RHEL in terms of user expectations as possible?
21:35:48 * jds2001 sends http://www.youtube.com/watch?v=8To-6VIJZRE to the rdiff-backup upstream :D
21:36:05 <maxamillion> inode0: we do, but there needs to be an understanding that we aren't on salary as the redhatters are
21:36:06 <jds2001> inode0: yep, that's my feeling
21:36:58 <inode0> the end user doesn't really care who is being paid by whom
21:37:02 <jds2001> right, but it's entirely within our control (and free) to not upgrade rdiff-backup.  Not say that's the right choice here, but it doesn't cost anyone anything or any time.
21:37:03 <nirik> ok, so it sounds like the thought for rdiff-backup is a new rdiff-backup128 package... thats parallel installable?
21:37:34 <nirik> btw, this is bug 466720
21:37:36 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=466720 medium, medium, ---, kevin, ASSIGNED, Backup stopped working after upgrade to version 1.2.1
21:37:36 <inode0> I think that is the sort of upgrade where that makes good sense nirik
21:37:47 <derks> nirik: that is my vote, unless it is a security issue then it should break-and-overtake
21:37:58 <nirik> I'm not sure it's possible without alternatives. yuck.
21:38:02 <maxamillion> inode0: they don't, and that's great but as soon as they complain then I will instruct them to request a refund for all money spent on EPEL ... because as a volunteer I think it is a little much to be expected to maintain single handedly what is essentially a fork of a code base
21:38:44 <inode0> maxamillion: you get to chew what you bite off
21:38:59 <maxamillion> and the user gets the option of not using EPEL
21:39:08 <nirik> ok. So, we want to amend the policy to say 'only security updates where upstream no longer supports this package and backporting is not possible by the maintainer' ?
21:39:30 <maxamillion> nirik: in what context is that bit being entered into?
21:39:40 <derks> maxamillion: I hear you on this... the thing to really consider is, we are talking about really extreme cases...  not a large percentage of packages
21:39:50 <nirik> in the context that the incompatible upgrades policy only covers that case?
21:40:39 <maxamillion> nirik: right, but what I meant was ... what course of action is to be taken, does that scenario then make it ok to upgrade and break the users old install?
21:41:10 <jds2001> a security update? sure.
21:41:15 <maxamillion> derks: true, but I don't think anyone really has an interest in maintaining a fork of mediawiki or rdiff-backup
21:41:15 <jds2001> per the policy
21:41:20 <nirik> well, we get down to witch is better: a) known insecure software or b) broken on upgrade, but can be fixed by manual intervention.
21:41:22 <maxamillion> ok, just making sure I understood it correctly
21:41:46 <jds2001> nirik: obviously b
21:42:00 * nirik was hoping he could just update rdiff-backup, but if folks don't want that I can look at the horrors of alternatives. ;(
21:42:00 <inode0> users ultimately control that one
21:42:09 <derks> maxamillion: of course not... what i meant was, its a small set of circumstances...  we aren't breaking everything all the time...  just these critical upgrades
21:42:25 <nirik> inode0: true.
21:42:26 <maxamillion> derks: right, and I'm all for the breakage if it is necessary
21:42:26 <nirik> inode0: but if we don't produce the upgrade, many won't take choice b.
21:43:39 <derks> as soon as EPEL gets a rep. for not fixing security issues...  it's hard to recover from that
21:43:40 <inode0> nirik: right, but I don't worry about admins using EPEL being careful updating critical stuff to them so they can hold off if they want to stay with insecure longer
21:43:51 <inode0> so just release secure ...
21:44:23 <jds2001> inode0: i failed to parse that, try again?
21:44:23 <inode0> so they have to actively choose a :)
21:44:57 <inode0> release the fix that breaks things, I can delay applying it until it is convenient for me
21:45:10 <jds2001> ok, but you have to know that it will break things.
21:45:21 <nirik> ok, so proposed: update the policy to mention it applies to:  'only security updates where upstream no longer supports this package and backporting is not possible by the maintainer' and mention all other things need a parallel installable package. Also, note that email needs to be sent when going to testing and again when going to stable?
21:45:21 <inode0> you are going to tell me aren't you :)
21:45:32 <jds2001> which is what the communication part is about
21:45:37 <jds2001> yeah
21:45:41 <maxamillion> is there currently a community outlet that we send "errata" reports to for information circulation to users about potential breakage?
21:46:01 <jds2001> maxamillion: fedora-package-announce? :D
21:46:07 <nirik> maxamillion: epel-announce
21:46:07 <derks> maxamillion: wouldn't that be the announce list?
21:46:36 <maxamillion> nirik: ah, that does exist? ... we should probably make it more visible on the "How to use EPEL" page in the wiki ... or something similar
21:46:42 <jds2001> yeah, that's where it is in this new policy
21:46:43 * maxamillion should probably join it as well
21:46:45 * derks thinks if end users don't subscribe to the announce list, and blindly auto update... well...  kind of their fault
21:47:18 <smooge> inode0, my question though is that do other repos give such promises?
21:47:20 <nirik> there are 22 people on the announce list right now.
21:47:25 <inode0> they can at least read the changelog in advance
21:47:29 <nirik> but it's never had a post either. ;)
21:47:45 <maxamillion> 23 now :)
21:48:00 <nirik> so, does everyone agree to the above proposal? jds2001: can you make those changes to the wiki page?
21:48:12 <maxamillion> +1
21:48:20 <jds2001> yep
21:48:38 <smooge> +1 myself
21:48:47 <derks> +1
21:49:05 <inode0> smooge: other repos do whatever they want for the most part scratching their own itches
21:49:29 <smooge> inode0, I should have worded that differently.
21:50:13 <smooge> inode0, I was more thinking of "hey this is a great way we can actually work with other enterprise repos that have policies in place." and it didn't come out that way
21:50:40 <nirik> ok, I guess I can look at a rdiff-backup12 this weekend. ;(
21:51:01 <nirik> #topic Open Floor
21:51:06 <nirik> anything for open floor?
21:51:17 <inode0> smooge: I don't think so, I think this is something that makes EPEL stand above them
21:51:24 <maxamillion> kind of a piggy back on the previous topic
21:51:31 <inode0> perhaps you will set an example they can follow
21:51:36 <smooge> nirik, let me know how I can help
21:51:48 <maxamillion> do we have a policy on branching versions?
21:52:05 <nirik> I think a lot of the pressure should die down once rhel6 is out (for a while :)
21:52:05 <smooge> branching versions?
21:52:06 <nirik> maxamillion: branching versions?
21:52:29 <maxamillion> nirik: yeah, like rdiff-backup and rdiff-backup12
21:52:36 <nirik> same as fedora.
21:52:45 <maxamillion> fedora has a policy on that?
21:52:51 <nirik> so it's a new package, it needs a review, it has to meet all the guidelines, etc
21:52:58 <maxamillion> oh .... ok
21:53:05 <maxamillion> didn't know there was a policy for it
21:53:14 <maxamillion> nvm :)
21:53:33 <smooge> cool. nirik I would like to really help then go through this because I have not done that part before
21:54:02 <nirik> https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Multiple_packages_with_the_same_base_name
21:54:25 <nirik> smooge: cool.
21:55:06 <nirik> ok, anything else? or shall we close up and call it a meeting?
21:55:25 <maxamillion> nirik: ah, thanks for the link .... learn something new everyday :)
21:55:30 * derks nothing from me
21:55:31 <maxamillion> I'm good
21:55:34 <smooge> i have nothing til the list
21:56:25 <nirik> thanks everyone!
21:56:35 <derks> actually.... where is the epel-announce list? I don't see it here: https://www.redhat.com/mailman/listinfo
21:57:09 <nirik> project.org/mailman/
21:57:11 <nirik> oops.
21:57:19 <nirik> https://admin.fedoraproject.org/mailman/admin/epel-announce
21:57:24 <derks> ah
21:57:27 <nirik> it's on lists.fedoraproject.org
21:57:44 <derks> oh... my bad.  thanks
21:57:53 <nirik> #endmeeting