21:00:00 #startmeeting EPEL Meeting 21:00:00 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:00:06 #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 smooge / rayvd: you guys around today? 21:04:19 I am here 21:04:36 cool. 21:04:41 lets go ahead and get started. 21:04:41 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 #topic Old action items 21:04:52 been dealing with cold 21:05:14 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 yes. I will generate the list and go to the list 21:05:57 * Jeff_S here now 21:06:03 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 hello Jeff_S 21:06:10 hi 21:06:14 hello spoleeba 21:06:14 hey Jeff_S 21:06:21 ok, sounds good. 21:07:02 #topic Incompatible upgrades policy 21:07:16 ok, so jds2001 posted a draft to the list. 21:07:18 so I posted a draft to the list earlier today 21:07:27 sorry that took so long :( 21:08:05 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 I haven't had a chance to read that yet 21:08:41 rereass 21:08:49 rereads that is 21:09:13 https://fedoraproject.org/wiki/EPEL_incompatible_upgrades_policy btw 21:10:17 I think we should add a section noting the normal 2 weeks in testing (or perhaps it should be longer)? 21:10:40 I would vote that it should be longer if it is expected to break existing installs 21:10:48 perhaps: build -> testing -> send email to announce -> push stable -> another email to announce 21:10:54 I don't see a reason to require a long testing period. Isn't that was the pre-discussion is about? 21:10:57 (partly) 21:11:13 well, it needs to be at least 2 weeks per our normal policy. 21:11:16 yes 21:11:22 a little bit, but it needs to be tested too 21:11:37 and that might give people enough time to notice it on announce before suddenly getting hit with it. 21:11:42 (in stable) 21:12:23 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 if you can do any of that 21:12:50 I think that 2 weeks and at least 3 announcements after its been "okd" 21:13:02 Anyone know if there is a similar policy for RHEL itself? 21:13:04 smooge: that sounds good 21:13:13 inode0: I think RHEL does wtf they feel like... ? 21:13:22 inode0: i think it's "dont do that" 21:13:25 *surprise* 21:13:44 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 well, speaking as customer I prefer don't do that as the policy :) 21:13:49 inode0: they'll upgrade desktop apps for example that have low risk of breakage. 21:13:54 inode0: I don't think incompatible upgrades would be allowed 21:14:12 in rhel 21:14:13 firefox got updated... 21:14:17 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 there is a big difference between upgrading because customers demand newer versions and this 21:14:47 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 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 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 Jeff_S. yes 21:15:18 inode0: i wanted to avoid "customers demand newer version" with this policy 21:15:42 derks: sure, but it's happened with less exciting/popular/used packages. 21:15:44 I am going to be a test case soon (real soon). 21:15:45 so would I, and I'm not interested in what Red Hat does in that case either 21:15:47 Also on the note of RHEL policy, I am fairly confident that our TAM would notify us of such an update 21:16:09 smooge: for what use case? 21:16:11 mediawiki in EPEL has issues and my trying to backport fixes was a mess. And they don't support it anymore 21:16:13 not all customers have TAM's 21:16:23 I do too, but not everyone does. 21:16:33 jds2001: I know... 21:16:33 * maxamillion is here ... sorry (just got out of $dayjob meeting) 21:16:59 well, I know we have a few packages waiting for this. I have rdiff-backup as well. 21:17:07 so a newer version has to go in, but it has a different schema 21:17:54 so what's the deal with rdiff-backup? 21:18:15 any of those intractable security backporting difficulty? or just we want newer stuff now? 21:18:56 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 oh ouch 21:19:40 with this policy though as it is, seems that we're stuck. 21:19:45 inode0, all my cases are intractable security issues 21:20:12 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 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 but yes, where do we draw the line? 21:21:54 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 that may or may not even be under your control 21:22:48 well, if the other rhel machine is using the old version, yeah. 21:22:58 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 I would probably make that change on the fedora side since they would be far outnumbered but ... 21:24:16 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 as in mediawiki114 mediawiki115 21:25:24 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 if it is a security thing though you want the bad one to go away don't you 21:25:32 smooge: personally I like that idea as it gives the users that are 'in the know' a chance to upgrade manually 21:26:27 inode0++ 21:27:06 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 maxamillion, not sure for all cases that the scriptment would work well enough 21:27:41 oi 21:28:01 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 have a split. ;) 21:28:37 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 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 inode0: agreed, parallel install for security issue would be a bad idea 21:29:03 jds2001: then maybe write a conversion script and include it in the %doc ? 21:29:05 maxamillion: it's already in the maintenance directory of MW itself. 21:29:09 oh ... well then 21:29:09 maxamillion: still would break installs on update tho... 21:29:10 but it needs to be customized to the site. 21:29:12 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 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 inode0, I am not against it myself.. it was more of how much trouble does it cause reviewers and standards 21:30:36 so, where do we draw the line here? or do we do case by case? 21:31:03 I honestly think it needs to be a written policy, case by case can get complicated 21:31:41 ok, then whats the policy? security only? incompatible protocols? no longer supported upstream? shinyer ? 21:32:12 nirik: maybe a check list? If X, and Y, and Z... AND it's approved by EPEL SIG then yes 21:32:29 you can make a case for all those, but I really like to limit the shinier to desktop stuff 21:32:30 i'd say security 21:32:44 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 is a 'we have no choice' situation 21:32:45 i dont think that no longer supported upstream really matters, except for security 21:32:55 derks: agreed 21:33:02 * inode0 wants rdiff-backup or similar to work for the duration as it does today 21:33:09 jds2001: right, that's essentially what I mean by no longer supported upstream 21:33:32 inode0: is it vulnerable to some security exploit that is known? 21:33:36 right, but if there's no known security vulnerability in them, then who cares? 21:33:42 ok, so security thats difficult/impossible to backport seems fine. 21:33:46 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 maxamillion: is what? 21:33:51 jds2001: right, if there is no security issue then upstream doesn't matter 21:33:53 what about incompatible protocols? 21:34:02 inode0: rdiff-backup 21:34:09 not that I know about 21:34:24 nirik: I think incompatible protocols should be viewed as "breaks things" 21:34:30 maxamillion: not that I know of either off hand. 21:34:35 tjat 21:34:46 that's a tough one though 21:34:56 what if someone is depending on the old protocol? 21:35:18 jds2001: exactly, makes it a "breaks things" situation 21:35:31 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 inode0: we do, but there needs to be an understanding that we aren't on salary as the redhatters are 21:36:06 inode0: yep, that's my feeling 21:36:58 the end user doesn't really care who is being paid by whom 21:37:02 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 ok, so it sounds like the thought for rdiff-backup is a new rdiff-backup128 package... thats parallel installable? 21:37:34 btw, this is bug 466720 21:37:36 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 I think that is the sort of upgrade where that makes good sense nirik 21:37:47 nirik: that is my vote, unless it is a security issue then it should break-and-overtake 21:37:58 I'm not sure it's possible without alternatives. yuck. 21:38:02 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 maxamillion: you get to chew what you bite off 21:38:59 and the user gets the option of not using EPEL 21:39:08 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 nirik: in what context is that bit being entered into? 21:39:40 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 in the context that the incompatible upgrades policy only covers that case? 21:40:39 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 a security update? sure. 21:41:15 derks: true, but I don't think anyone really has an interest in maintaining a fork of mediawiki or rdiff-backup 21:41:15 per the policy 21:41:20 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 ok, just making sure I understood it correctly 21:41:46 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 users ultimately control that one 21:42:09 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 inode0: true. 21:42:26 derks: right, and I'm all for the breakage if it is necessary 21:42:26 inode0: but if we don't produce the upgrade, many won't take choice b. 21:43:39 as soon as EPEL gets a rep. for not fixing security issues... it's hard to recover from that 21:43:40 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 so just release secure ... 21:44:23 inode0: i failed to parse that, try again? 21:44:23 so they have to actively choose a :) 21:44:57 release the fix that breaks things, I can delay applying it until it is convenient for me 21:45:10 ok, but you have to know that it will break things. 21:45:21 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 you are going to tell me aren't you :) 21:45:32 which is what the communication part is about 21:45:37 yeah 21:45:41 is there currently a community outlet that we send "errata" reports to for information circulation to users about potential breakage? 21:46:01 maxamillion: fedora-package-announce? :D 21:46:07 maxamillion: epel-announce 21:46:07 maxamillion: wouldn't that be the announce list? 21:46:36 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 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 inode0, my question though is that do other repos give such promises? 21:47:20 there are 22 people on the announce list right now. 21:47:25 they can at least read the changelog in advance 21:47:29 but it's never had a post either. ;) 21:47:45 23 now :) 21:48:00 so, does everyone agree to the above proposal? jds2001: can you make those changes to the wiki page? 21:48:12 +1 21:48:20 yep 21:48:38 +1 myself 21:48:47 +1 21:49:05 smooge: other repos do whatever they want for the most part scratching their own itches 21:49:29 inode0, I should have worded that differently. 21:50:13 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 ok, I guess I can look at a rdiff-backup12 this weekend. ;( 21:51:01 #topic Open Floor 21:51:06 anything for open floor? 21:51:17 smooge: I don't think so, I think this is something that makes EPEL stand above them 21:51:24 kind of a piggy back on the previous topic 21:51:31 perhaps you will set an example they can follow 21:51:36 nirik, let me know how I can help 21:51:48 do we have a policy on branching versions? 21:52:05 I think a lot of the pressure should die down once rhel6 is out (for a while :) 21:52:05 branching versions? 21:52:06 maxamillion: branching versions? 21:52:29 nirik: yeah, like rdiff-backup and rdiff-backup12 21:52:36 same as fedora. 21:52:45 fedora has a policy on that? 21:52:51 so it's a new package, it needs a review, it has to meet all the guidelines, etc 21:52:58 oh .... ok 21:53:05 didn't know there was a policy for it 21:53:14 nvm :) 21:53:33 cool. nirik I would like to really help then go through this because I have not done that part before 21:54:02 https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Multiple_packages_with_the_same_base_name 21:54:25 smooge: cool. 21:55:06 ok, anything else? or shall we close up and call it a meeting? 21:55:25 nirik: ah, thanks for the link .... learn something new everyday :) 21:55:30 * derks nothing from me 21:55:31 I'm good 21:55:34 i have nothing til the list 21:56:25 thanks everyone! 21:56:35 actually.... where is the epel-announce list? I don't see it here: https://www.redhat.com/mailman/listinfo 21:57:09 project.org/mailman/ 21:57:11 oops. 21:57:19 https://admin.fedoraproject.org/mailman/admin/epel-announce 21:57:24 ah 21:57:27 it's on lists.fedoraproject.org 21:57:44 oh... my bad. thanks 21:57:53 #endmeeting