EPEL meeting summary/minutes - 2009-07-17

Fri Jul 17 22:04:17 UTC 2009

=============================
#fedora-meeting: EPEL meeting
=============================

Meeting log
-----------
* **Init process**  (nirik-21:00:22_)

* **Bug day recap**  (nirik-21:03:59_)

  * *INFO*: will revisit ideas for bugday in a few months.
    (nirik-21:12:01_)

* **Dealing with incompatible upgrades**  (nirik-21:13:43_)

  * *INFO*: epel users should all subscribe to epel-announce
    (nirik-21:31:30_)

* **Wiki pages cleanup**  (nirik-21:38:10_)

* **Repotags Redux**  (nirik-21:42:35_)

* **Open Floor**  (nirik-21:54:39_)

People Present (lines said)
---------------------------
* nirik (92)
* stahnma (75)
* smooge (40)
* jds2001 (38)
* maxamillion (20)
* dgilmore (16)
* Jeff_S (15)
* onekopaka (9)
* inode0 (1)

kevin
--
21:00:11 <nirik> #startmeeting
21:00:17 <nirik> #meetingtopic EPEL meeting
21:00:22 <nirik> #topic Init process
21:00:27 <nirik> who all is around for an EPEL meeting?
21:01:38 <onekopaka> nirik: I thought things usually started with #topic Who's here?
21:01:59 <nirik> I like to mix things up... ;)
21:02:14 <onekopaka> mmkay.
21:02:20 * onekopaka will be in here because.
21:02:32 <maxamillion> I'm here
21:02:33 <maxamillion> sorry
21:02:43 <maxamillion> couple minutes late, I ran to snag something to drink
21:02:51 <stahnma> Im here
21:03:22 * jds2001 sits in the cheap seats
21:03:54 <nirik> ok, lets go ahead and get started then...
21:03:59 <nirik> #topic Bug day recap
21:04:04 <nirik> so, how did the bug day go?
21:04:11 <nirik> what can we do better? or should we do them again?
21:04:23 <stahnma> I think the planning went better than the execution
21:04:32 <stahnma> weekend may have been a bad pick
21:04:34 <stahnma> I am not sure
21:04:46 <stahnma> summer weekends (for us northern Hemisphere people) are probably bad
21:04:53 <nirik> yeah, possibly true.
21:05:01 <onekopaka> bad?
21:05:08 <onekopaka> what makes them bad?
21:05:11 <stahnma> total number of bugs did reduce, but very little bug activity on actual bug day
21:05:16 <stahnma> people want to play outside :)
21:05:18 <nirik> I did poke a few bugs, but nothing very amazing.
21:05:25 <onekopaka> stahnma: ah.
21:05:40 <stahnma> the pre-work caused many (dozens) of bugs to be updated and closed
21:05:43 <stahnma> so that was worthwhile
21:05:52 <nirik> should we do another one? or is it just not something thats good?
21:06:03 <stahnma> I am not 100% sure
21:06:09 <maxamillion> I think its a good idea, I just don't know how practical it is that people will show up
21:06:12 <stahnma> I like the idea of a focus on bugs
21:06:25 <stahnma> but not sure if a bug day is the right way for it
21:06:34 <maxamillion> Thought I think the emails about it did make people go and check their packages for bugs
21:06:37 <nirik> yeah, perhaps we should revisit in the fall or something?
21:06:54 <stahnma> yes, and until then I will keep trying to touch some bugs and get some things closed
21:07:07 * onekopaka notes that Mozilla succeeds at bugdays
21:07:39 <stahnma> I'd be interested to hear/see how other projects engage/involve people in bug day.  I did what I could, but certainly need to learn more
21:07:56 <maxamillion> maybe run weekly reports? I know some people don't like the "spam" but I do think others would benefit from the reminder
21:08:03 <nirik> I think it's hard for epel, as we arent really a big project.
21:08:08 <Jeff_S> hi, sorry I'm late
21:08:14 <nirik> welcome Jeff_S
21:08:36 * dgilmore is here
21:09:11 <nirik> maxamillion: you mean a list of bugs to the list each week? might be a bit daunting... ;( Perhaps we could highlight some per week or something?
21:09:47 <stahnma> yeah, i probably need to play with python-bugzilla a bit and see if we can do anything that would present usable metrics/datas
21:09:54 <maxamillion> nirik: that's possible ... maybe pull a report and sift through it a little, but what would we use as a criteria?
21:10:00 <nirik> or pick on the oldest ones each week.
21:10:04 <maxamillion> ah
21:10:10 <jds2001> stahnma: maybe coordinate with comphappy?
21:10:13 <maxamillion> that'd be a good one
21:10:16 <jds2001> over in #fedora-bugzappers?
21:10:25 <jds2001> he's writing a whole metrics app
21:10:40 <maxamillion> oooo
21:10:56 <maxamillion> that'd be infinitely useful in situations like this ... kudos to him
21:11:12 <jds2001> bashton at fp.o if you're interested :)
21:11:44 <nirik> ok, anything else on bugday? or shall we move on?
21:12:01 <nirik> #info will revisit ideas for bugday in a few months.
21:12:19 <stahnma> sounds good
21:13:37 <nirik> ok, moving on...
21:13:43 <nirik> #topic Dealing with incompatible upgrades
21:13:50 <nirik> smooge posted some ideas on this...
21:14:14 * onekopaka wonders where smooge might be..
21:14:16 <nirik> basically do a 'whateverXY' package when there is a need to upgrade
21:14:38 <smooge> oh sorry
21:15:02 <stahnma> it's not a horrible idea
21:15:09 <nirik> one question is how this would affect fedora.
21:15:21 <stahnma> also, which lists should an end-user be on that is using #epel?
21:15:23 <nirik> or would it only be in epel land.
21:15:23 <smooge> ok I proposed some ideas but I think it needs to be dealt with upstream also
21:15:23 <maxamillion> I liked the idea, and I know that fedora does it as whatever and whateverXY such that whateverXY is the old version, but I don't know it is possible for our use case
21:15:24 <stahnma> mailing lists
21:15:46 <smooge> there are a lot of packages upstream that do this sometimes and othertimes no
21:15:54 <stahnma> upstream will break api/abi at times. I don't think we can mandate they can't
21:15:58 <nirik> yeah, we would need 'trac010' and 'trac011' for example.
21:16:01 <jds2001> nirik: im thinking only on epel-land
21:16:09 <jds2001> so only epel branches
21:16:13 <Jeff_S> so this leaves <whatever> being possibly unmaintained? with the maintainer concentrating on whateverXY
21:16:19 <stahnma> and suddenly we're very debiany
21:16:20 <jds2001> nirik: trac011 wont work til rhel6 :(
21:16:33 <nirik> jds2001: sure it will... just no git plugin. ;)
21:17:28 <smooge> Jeff_S, yes.. the idea is to give them the access to the source code for X amount of time but say we aren't fixing it anymore. At some time in the future it would be removed from the repo
21:17:50 <nirik> smooge: so we don't even ship the older one then?
21:17:52 <smooge> stahnma, I want to apologize about last saturday.. I got stuck in an all day meeting elsewhere
21:17:56 <Jeff_S> smooge: and users that don't read the list are left with something unsecure/unmaintained
21:18:17 * onekopaka slips out to go someplace
21:18:24 <jds2001> there needs to be some way to notify em
21:18:24 <smooge> Jeff_S, they are left with either unsecure unmaintianed ore completely broken/removed software
21:18:40 * jds2001 is on enterprise-watch-list for instance
21:18:43 <smooge> Jeff_S, a couple of the moin updates really hose the DB to be unusable after you do an rpm -ivh
21:18:45 <jds2001> do we do something similar?
21:18:50 <smooge> s/ivh/Uvh/
21:19:00 <nirik> we have the following lists:
21:19:11 <nirik> epel-announce - end use announcements
21:19:15 <nirik> epel-devel
21:19:21 <nirik> (main devel discussion, etc)
21:19:36 <nirik> epel-package-announce - bodhi stable updates announcements.
21:19:40 <dgilmore> nirik: and epel-package-announce
21:19:49 <nirik> yep.
21:19:57 <jds2001> epel-announce seems to be the right place for something enterprise-watch-listy
21:20:02 <smooge> the idea would be: a) announce dead-line package, b) split package into deadline, c) push d) wait e) retire
21:20:03 <jds2001> :)
21:20:06 <dgilmore> an end user should subscibe to epel-announce and epel-package-announce
21:20:06 <nirik> so, in theory if all our users were on the epel-announce list we could tell them about breaking updates there.
21:20:30 <smooge> nirik, I would assume that very few people are subscribed to it
21:20:35 <nirik> smooge: so, why bother to split then? why not just announce and update?
21:20:39 <nirik> smooge: yeah.
21:20:56 <jds2001> if im not on enterprise-watch-list (and the various rhel announce lists) I'd have no way to know what's going to change when I do a yum update
21:21:28 <jds2001> so why should epel be any different?  Don't subscribe to epel-announce at your own peril :D
21:21:35 * jds2001 subscribes to epel-announce :D
21:21:36 <smooge> nirik, the choice seems to be "announce to few users, and break more.." or put users who would be broken onto a dead-end RPM that they could take over maintenance if needed.
21:22:11 <smooge> the idea is that if someone wants moin-1.5 really really badly they can share their work to keep it updated.
21:22:15 <nirik> you think anyone will want to step up to maintain a eol package?
21:22:43 <dgilmore> nirik: not likely
21:22:46 <jds2001> likely not
21:23:00 <Jeff_S> not very often anyway
21:23:03 <smooge> no and after 6 months its dropped from the repo
21:23:09 <nirik> but I would expect some people would want to keep using it forever...
21:23:12 <smooge> just like any other orphaned package
21:23:12 <Jeff_S> smooge: why wait at all?
21:23:23 <nirik> "but it's only internal, I don't care if it's insecure", etc.
21:23:41 <nirik> it's not an easy problem. ;(
21:23:43 <smooge> Jeff_S, I don't know.. why don't we do daily recompiles of rawhide and push to stable
21:24:01 <maxamillion> this is where we need to draw out the expectations of what EPEL will provide to the end user ... are we willing to maintain old software internally or are we going to cut and run and let the users worry about it?
21:24:08 <nirik> on the one hand, you break sites with incompatible upgrades. On the other hand you keep old cruft thats not really being maintained.
21:24:51 * nirik wishes there was some better way to communicate to end users that a package is dying.
21:25:04 <smooge> my point is that if we want to be a stable repo we need to put in some sort of rules about how we handle that stuff.
21:25:19 <Jeff_S> maxamillion: +1 -- this needs to be made clear to the average user who just wants to enable epel to get a few packages and assumes those will keep working "forever"
21:25:45 <smooge> we can go with updates will break things.. but lets be clear on it instead of saying we have 'stable' or Enterprise packages
21:25:51 <stahnma> agreed, it needs to be clear
21:25:56 * nirik nods.
21:25:57 <stahnma> but we certainly are not clear yet
21:26:22 <smooge> no reading through the pages gives you a feeling that we only push stable stuff and we don't break things.
21:26:26 <stahnma> the 'only internal' problem is very real
21:27:03 <nirik> in some cases we don't know something is broken, just that it's not maintained or people want a newer one.
21:27:16 <Jeff_S> stahnma: so let them keep a local copy if needed
21:27:31 <Jeff_S> otherwise this gets out of hand real quick
21:27:33 <smooge> nirik, s/some/lots of/
21:27:36 <stahnma> I agree.  I brought that up last time :)
21:27:50 <nirik> we could also just say 'no new incompatible upgrades', wait for rhel6.
21:28:04 <nirik> which is kinda where we have been. There are a number piled up now.
21:28:18 <stahnma> which isn't that bad now
21:28:25 <stahnma> but in 3 years it will really suck
21:28:30 <smooge> well that then runs into the issue with a couple of the packages.. where security fixes can't/wont be backported so we would need to drop moin, nagios, etc
21:28:49 <smooge> at which point we would need to remove them from the repo
21:28:57 <stahnma> I think upgrades are needed at times.  they need to be communicated the best we can do.
21:29:33 <jds2001> we aren't RHT, that has lots of resources to put into backporting stuff
21:29:47 <jds2001> but if there are upgrades required, we need to scream about it :)
21:30:25 <Jeff_S> I agree with stahnma & jds2001 on that
21:30:34 <stahnma> agreed
21:30:39 <stahnma> 30 days notice would be nice
21:30:57 <jds2001> epel-announce currently has the whole of 16 members, btw
21:31:05 <stahnma> w00t
21:31:18 <nirik> yeah, not many. ;(
21:31:24 <stahnma> perhaps we should update (or even include) a readme in epel-release
21:31:24 <jds2001> we need to make that number bigger :)
21:31:26 <smooge> ok so we put non-upgradable stuff in testing for a 1 month 'embargo'
21:31:30 <nirik> #info epel users should all subscribe to epel-announce
21:31:44 <stahnma> that suggests users subscribe and such
21:32:04 <nirik> stahnma: might not be a bad idea.
21:32:09 <smooge> nirik, I wonder if we can do a import of the epel users and have them unsubscribe
21:32:22 <nirik> some people might look at why the epel-release updated and see it.
21:32:31 <nirik> smooge: import from where?
21:32:37 <stahnma> and of course we could post to the list about it
21:32:43 <smooge> epel-devel list
21:32:58 <stahnma> could we post on any of the RHEL/CentOS lists, or is that bad form?
21:33:06 <smooge> i thought that was what we did when the list was created...
21:33:11 <stahnma> just to remind people if they are using EPEL, being on epel-annouce will be a good idea
21:33:30 <jds2001> unfortunately epel-devel is @redhat.com
21:33:34 <smooge> I would then say we need to add something to epel-release which explains our policies on things
21:33:42 <jds2001> though dgilmore and I are talking this weekend about that :D
21:34:06 <nirik> I don't think we should ever subscribe people against their will.
21:34:07 <smooge> I don't care if people whine if we can say "Did you read /usr/share/doc/epel-release-1.0/README
21:34:22 <nirik> just suggest it. Perhaps some blog posts?
21:34:26 <stahnma> ----------------------------------------------------------------------------------------------------------------------
21:34:30 <stahnma> we can blog and tweet it
21:34:44 <jds2001> sounds good.
21:34:53 <stahnma> we need to figure out the exact verbiage to put in a README
21:35:02 <stahnma> do we decide that today, or next week?
21:35:14 <stahnma> or on list
21:35:16 <smooge> next week someone post on the list what it should look like
21:35:17 <stahnma> which is probably best
21:35:18 <jds2001> next week, we need some sort of draft
21:35:26 <smooge> we +1/-1 patch until its ready by next week
21:36:23 <nirik> sounds good.
21:36:25 <maxamillion> smooge: +1 on the README, if the documentation is provided and referenced to on the wiki page then it would then be the user's responsibility
21:36:42 <nirik> so, we didn't really decide this topic, right? just that we want better ways to communicate with our users?
21:37:10 <stahnma> yeah, that's what I thought
21:37:39 <stahnma> further discussion for content/policy on list?
21:37:48 <stahnma> this topic has lingered enough for today, IMHO
21:37:53 <nirik> ok
21:37:56 <Jeff_S> yes please
21:38:10 <nirik> #topic Wiki pages cleanup
21:38:21 <nirik> so, I suck and haven't updated the updates policy page yet.
21:38:32 <nirik> but looking at it, we have a bunch of wiki pages that could use cleanup.
21:38:35 <nirik> or reorg
21:38:37 <stahnma> I've done a couple
21:38:41 <stahnma> but yes, we need a lot
21:38:48 <stahnma> I thought quaid signed up for that one :)
21:38:52 <smooge> nirik, we decided that branching was not in EPEL interest which is ok for me.
21:39:05 <smooge> stahnma, yes quaid signed up for it
21:39:13 <nirik> yeah. :)
21:39:15 <jds2001> smooge: branching what?
21:39:33 <smooge> branching moinmoin to moin16, nagios to nagios15 etc
21:39:37 <nirik> smooge: well, I don't think we decided anything other than it's a hard problem... ;( unless I missed some consensus.
21:39:44 <jds2001> oh...
21:39:53 <smooge> nirik it seemed that I was the only one for it :)
21:40:05 <smooge> that seemed like consensus to me :)
21:40:33 <nirik> I'm not totally against it. I'm just not sure how if it would do best by our users. I guess it depends on what our users want. ;(
21:40:34 <jds2001> i dont think anyone was against it, per se.
21:40:53 * jds2001 not sure of a way to survey the users :D
21:40:56 <stahnma> not really against, just want to be sure it's actually do-able with the current manpower (which is minimal)
21:40:58 <nirik> anyhow, on the wiki. I will try and update the updates policy page or make a new one.
21:41:11 <nirik> but if others want to clean up pages, please do so.
21:42:04 <nirik> anything else on the wiki? or shall we move on?
21:42:35 <nirik> #topic Repotags Redux
21:42:48 <nirik> do we want to re-open the repotags debate?
21:43:04 <jds2001> yes, it has strong support from our users.
21:43:13 * jds2001 wasnt around for the previous one, though
21:43:31 <jds2001> but if you hang out in #rhel, you here about that a lot.
21:43:39 * dgilmore says shut it in a closet and let it rot in its on hell
21:43:40 <nirik> jds2001: oh? they have strong support for this, but don't know about incompatible upgrades? ;)
21:43:44 <Jeff_S> ... at this point I will abstain
21:43:56 <jds2001> nirik: yeah :/
21:44:05 <nirik> jds2001: so what do people there ask? how they can tell if a package is from epel? how does it come up?
21:44:18 <jds2001> yes, that's one thing.
21:44:21 <stahnma> it comes up any time I mention epel
21:44:23 <stahnma> at all
21:44:23 <stahnma> ever
21:44:26 <stahnma> seriously
21:44:28 <maxamillion> yeah, I get yelled at a lot for EPEL not having repotags when I hang out in #rhel ... which is why I asked
21:44:41 <dgilmore> jds2001: id prefer to add a script to epel-release that prints all packages from epel that are installed
21:44:43 <maxamillion> on the mailing lists*
21:44:55 <jds2001> dgilmore: what's the reasoning against it?
21:44:56 <nirik> stahnma: really? as in "oh, try the epel package of foo" "EPEL? REPOTAGS!!!!!!!!!!!!!!!!!!!!!!!" :)
21:45:03 <maxamillion> dgilmore: that would honestly fix the complaints I've heard
21:45:05 <stahnma> nirik: basically
21:45:25 <maxamillion> nirik: close ... strangely close actually
21:45:31 <dgilmore> jds2001: ill talk to you about it outside of here
21:45:32 <stahnma> I think people want an easy way to see what repo packages came from
21:45:33 <nirik> it's a poor indicator of where a package is from.
21:45:37 <stahnma> in a massive view
21:45:42 <stahnma> like rpm -qa or yum list
21:45:51 <stahnma> only one that includes repo
21:45:59 <stahnma> I wrote something that does that using the GPG key value
21:46:11 <stahnma> but it's probably not foolproof
21:46:12 <inode0> no one wants to do that
21:46:26 <smooge> nirik I think a LOT of people just do the following to get into EPEL. Google for a package. Install epel-release. yum install. Oh look I need another pakcage. Its in rpmforge. Repeat
21:46:37 <stahnma> exactly
21:46:37 <dgilmore> nirik: right its not a win at all and easily faked
21:46:47 <nirik> smooge: sad. ;(
21:47:00 <stahnma> but very real (not in my shop though :) )
21:47:14 <smooge> I thought that it would be a minor thing.. but I had 40 computers at a government lab with different people following other advice
21:47:18 <nirik> stahnma: what would you think about adding your script to epel-release?
21:47:25 <dgilmore> stahnma: your special though, thats a well established fact :)
21:47:36 <Jeff_S> so let's wait for rhel 6 when yum will show repo in yum list? :)
21:47:39 <stahnma> it needs to be re-written.  It's currently in ruby and really kind of dumb
21:47:40 <Jeff_S> problem solved?
21:47:59 <nirik> ideally it would be nice for rhel to get a script/package to list that info
21:48:03 <smooge> Jeff_S, no because people do rpm -qa not yum list
21:48:22 <dgilmore> nirik: there is a script in rhel already
21:48:28 <stahnma> teh best solution is to have a tag/field in RPM for it
21:48:29 <Jeff_S> smooge: that's their own problem then and they'll find something else to complain about if there were dist tags
21:48:39 <dgilmore> nirik: the one that puts your system info together for gss
21:49:06 <dgilmore> stahnma: no because it can be faked
21:49:08 <nirik> dgilmore: oh? how to use? ;)
21:49:23 <jds2001> dgilmore: actually it might not be to bad as an sos plugin
21:49:37 <jds2001> but one that can be manually executed too.
21:49:46 <jds2001> nirik: sosreport
21:49:55 <dgilmore> nirik: sosreport
21:50:08 <nirik> in any case I think education is better than repotags. ;)
21:50:15 <dgilmore> jds2001: right or even epelreport
21:50:16 <nirik> how about a wiki page on this stuff?
21:50:21 <nirik> we can point people to?
21:50:24 <dgilmore> that reports on installed epel packages
21:51:21 <maxamillion> dgilmore: I like that idea also
21:51:53 <dgilmore> stahnma: lets worktogether on putting something together
21:52:29 <maxamillion> I've gotta run
21:53:07 <stahnma> ok
21:53:17 <stahnma> I like the idea of reporting on all packages if possible
21:53:31 <stahnma> but epel vs core el for sure
21:53:36 <nirik> I think a wiki page or other place to point people would be good too. ;)
21:53:51 <nirik> just group them by gpg key. ;)
21:54:05 <nirik> anything else on this?
21:54:21 <smooge> no I have brought it up for the year of 2009
21:54:39 <nirik> #topic Open Floor
21:54:44 <nirik> smooge: :)
21:54:53 <nirik> anyone have anything else they would like to bring up?
21:55:38 <smooge> personally I like repotags, but I am not going to harp about it more than once a year. I will let someone else bring it up from #rhel next time.
21:56:57 <nirik> yeah, on a first glance I like them too, but then I realize how fakable/unreliable they are, so would prefer to have a better method.
21:57:12 <stahnma> I think it might do us some good to jump into #rhel and see what our users like/dislike about epel
21:57:18 <stahnma> and what we can do to make it more widely used
21:57:40 <nirik> stahnma: yeah, not a bad idea I guess. I'm already in a billion channels, I guess I can hang out there too.
21:58:16 * nirik will close out the meeting in 60seconds if nothing else comes up.
21:58:19 <stahnma> well, we certainly don't have to
21:58:23 <stahnma> oh, one more thing
21:58:27 <stahnma> who's going to the RH summit?
21:58:31 <stahnma> or we can bring it up next time
21:59:07 * nirik isn't planning on it.
21:59:24 <nirik> a EPEL bof or whatever there might be good though if we have enough people going.
21:59:49 <Jeff_S> OSCON?
22:00:02 <stahnma> I'm not at OSCON
22:00:07 <stahnma> but at the RH Summit
22:00:23 <smooge> I wont be at the Summit
22:00:51 <nirik> #endmeeting
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20090717/297c769b/attachment.sig>