[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Log from last weeks (200700829) EPEL SIG Meeting



00:00:46 <       knurd> | Meeting ping dgilmore, Jeff_S, knurd, mmcgrath, nirik, stahnma, quaid and everyone interested in EPEL -- EPEL meeting in #fedora-meeting now!
00:00:46 <       knurd> | Hi everybody; who's around?
00:00:46              * | knurd likes to remind people that the schedule and the topic list for todays meeting can be found on http://fedoraproject.org/wiki/EPEL/Schedule
00:00:46            --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
00:00:50 <    mmcgrath> | pong
00:00:57 <     stahnma> | pong
00:01:20              * | nirik is here. 
00:01:43              * | stahnma tried to solicit interest from #rhn 
00:02:12 <       knurd> | well, let's start
00:02:15            --- | knurd has changed the topic to: EPEL Meeting|push to stable easily -- knurd
00:02:25 <       knurd> | mschwendt did some improvements to the scripts
00:02:42 <       knurd> | they should make it easy to moev something from testing to stable
00:02:50 <       knurd> | the final patch was not applied yet
00:03:11 <       knurd> | I talked to dgilmore about it (he knows the scripts way better than I do) and wants to take a look
00:03:23 <       knurd> | if he doesn#t find the time i'll take the risk over the next few days
00:03:33 <       nirik> | we just need to be carefull that a update doesn't depend on something else in testing.
00:03:55 <       knurd> | ohh, and I'd like to say "thx for your  work mschwendt"
00:04:18 <     stahnma> | as someone not too familiar with the infrastructure side of things, were are these scripts at?
00:04:21 <       knurd> | nirik, well, with the current policy we only move updates for stable packages
00:04:24 <     stahnma> | and can I review them?
00:04:52              * | dgilmore is here
00:04:57 <    mmcgrath> | I actually don't know where the canonical spot for that stuff is
00:04:59 <       knurd> | stahnma, somewhere in http://cvs.fedora.redhat.com/viewcvs/?root=fedora
00:05:15 <    dgilmore> | extras-buildsys
00:05:20 <       nirik> | knurd: are you talking about moving single packages from testing-> stable, or moving all packages in testing-> stable?
00:05:37 <       knurd> | nirk, for now only single packages
00:05:37 <     stahnma> | ok, I can take that offline, I just would like to be a bit more involved in some of the infrastructure for EPEL
00:05:45 <       knurd> | e.g. in case of urgent bugixes
00:05:52 <       nirik> | the first we need to make sure the package is not built against any of the other packages that are still sitting in testing...
00:06:30 <       knurd> | dgilmore, I suppose you didn#t find time yet to look into the improvements from mschwendt?
00:06:46            --> | BobJensen (Robert 'Bob' Jensen)  has joined #Fedora-Meeting
00:06:51 <       knurd> | nirik, well, normally there should be any new stuff where in testing which could lead to problems
00:06:53 <    dgilmore> | knurd: not yet. its on my todo list after fixing plague
00:07:02 <       knurd> | nirik, but yeah, we shound not forget about it
00:07:06 <       nirik> | yeah, we also need that for security updates. I should perhaps see if we can add a audit file for epel and discuss on the list security.
00:07:06 <       knurd> | dgilmore, k, thx
00:07:10 <     stahnma> | dgilmore: are the EL-5 builders still amuck?
00:07:17 <     stahnma> | (I have no idea if I spelled that right)
00:07:52 <    dgilmore> | stahnma: all plague builds
00:08:20 <         rsc> | dgilmore: just to comment. I was one of the guys having such problems. I fired lots of builds the last days, no problems for me. But I can't speak for all.
00:08:36 <    dgilmore> | rsc: there has still been reports
00:09:33 <       knurd> | well, anything else for now?
00:09:42              * | knurd will move on soon
00:09:59            --- | knurd has changed the topic to: EPEL Meeting|new meeting schedule/scheme
00:10:13 <     stahnma> | I sent out some feelers on list
00:10:18 <       knurd> | stahnma, would you be willing to run the meetings every second week at 23:00 UTC?
00:10:20 <     stahnma> | didn't get much back other than the SIG
00:10:28 <       nirik> | I'm happy to try an alternate meeting time... we can always try and if no more people show we can stop doing it. ;)
00:10:29 <     stahnma> | knurd: I think so
00:10:29 <       knurd> | then I'd say we just try it
00:10:45 <       knurd> | (even if I never will be able to make those meetings)
00:10:59 <       knurd> | is the timeslot fee in this channel?
00:11:03 <     stahnma> | hmm
00:11:08 <     stahnma> | probably something I should ahve looked at
00:11:18 <     stahnma> | yeag
00:11:46              * | stahnma will add to the #fedora-meeting schedule
00:11:53 <       knurd> | k
00:12:33 <       knurd> | so agreed we agree on: one week at 17:00 UTC, the other week on 23:00 UTC, this channel and Wednesday
00:12:38 <       knurd> | is that correct?
00:12:45 <       knurd> | and fine for everybody?
00:12:57 <    mmcgrath> | we're still meeting weekly, just different times each week?
00:13:07 <       knurd> | mmcgrath, seems so
00:13:12 <       nirik> | so next week starts the other meeting time?
00:13:15 <       nirik> | or today?
00:13:19 <       knurd> | nirik, next week
00:13:29 <     stahnma> | next week
00:13:34 <       knurd> | nirik, or do you want to have two meetings on one day? ;-)
00:13:48 <       nirik> | ok, but we should note that it's a trial, and if there isn't much response we will not be doing it further.
00:13:52            --> | mpdehaan (Michael DeHaan)  has joined #fedora-meeting
00:13:54 <       nirik> | ha. No thanks. ;)
00:14:07 <       knurd> | nirik, "trial" > sounds like a good plan
00:14:28 <       knurd> | settled then? yell now or I'll consider it accepted
00:14:29 <     stahnma> | ok
00:14:39 <       knurd> | stahnma, will you write the meeting summaries for the reports as well?
00:14:45 <     stahnma> | sure
00:14:49 <       knurd> | great :)
00:15:22              * | knurd considers it as accepted and moves on
00:15:25 <       knurd> | ohh, wait, stop
00:15:35 <       knurd> | I think we nevertheless should try to do more on the list
00:15:39 <     stahnma> | +1
00:15:41 <       knurd> | or what do other think?
00:15:44 <       knurd> | others
00:15:52 <       nirik> | sure, I agree.
00:16:06 <       knurd> | k
00:16:13 <       knurd> | I hope to write something up about it
00:16:15 <       knurd> | soon
00:16:19              * | knurd moves on
00:16:21            --- | knurd has changed the topic to: EPEL Meeting| MetaData for all Packages available to contributors. -- stahnma
00:16:24 <       knurd> | stahnma ?
00:16:43 <     stahnma> | I've been trying to get a better definition of the problem
00:16:53 <     stahnma> | I understand the issue, but use-cases etc would be nice
00:17:09 <     stahnma> | we need a clear stance on EPEL not stepping on RHN provided material
00:17:17 <     stahnma> | and a way to hopefully enforce it
00:17:18 <       knurd> | stahnma, maybe it would be a good start to at lest have a package list online somewhere
00:17:21 <     stahnma> | but how, I haven't got there yet
00:17:25 <     stahnma> | ok
00:17:25 <       knurd> | for 5Desktop and 5Server
00:17:28 <     stahnma> | I can probably do that
00:17:33 <     stahnma> | if it's not already done
00:17:38 <       nirik> | I'm still unsure whats in all those hundreds of channels.
00:17:39 <       knurd> | not that I know of
00:17:52            <-- | TowerBE  has left #fedora-meeting ( "I'm outta here")
00:17:55              * | knurd doesn't know that either
00:17:56 <       nirik> | is that other packages or just a different set (like a fedora spin?)
00:17:57 <     stahnma> | nirik: packages :)  Many of them are old RH channels
00:18:00 <     stahnma> | like 7.2
00:18:01 <     stahnma> | and 7.3
00:18:03 <     stahnma> | and such
00:18:13 <       nirik> | ah ha.
00:18:15            --> | Jeff_S (Jeff)  has joined #fedora-meeting
00:18:19 <       nirik> | well, most of those can be ignored I bet.
00:18:21 <     stahnma> | and separate channels for each arch and each flavor (AS, ES, AP)
00:18:22 <     stahnma> | right
00:18:30 <     stahnma> | it's mostly a matter of sorting through them
00:18:32              * | Jeff_S on phone, sorry :(
00:18:40 <       nirik> | stahnma: perhaps a list of channels would be good to post? or is that info something redhat wouldn't want released?
00:18:49 <     stahnma> | I think I have it on fedorapeople
00:18:51 <     stahnma> | let me check
00:19:00 <     stahnma> | http://stahnma.fedorapeople.org/rhn_channels.txt
00:19:09 <     stahnma> | this is a week or two old
00:19:39 <       nirik> | ok, so what info can you get from each channel? packages names?
00:19:44 <     stahnma> | yes
00:19:49 <     stahnma> | and EVRs
00:19:50 <       nirik> | how about files?
00:19:51 <     stahnma> | if we want them
00:19:55 <     stahnma> | I *think* so
00:19:59 <     stahnma> | I have to check on that one
00:20:06 <       nirik> | or provides?
00:20:34 <     stahnma> | yup, I can get a list of files for each package
00:20:56 <       nirik> | basically what I think we want is a tool or something where we can do a lookup by name/provides/files so we can tell if a package someone wants to move into epel conflicts with that.
00:21:24 <     stahnma> | I can get provides
00:21:31 <     stahnma> | the RHN API is pretty cool
00:21:37 <       nirik> | ie, search on 'openmotif' and or 'Provides: libm.so.4' or whatever.
00:21:51              * | nirik guesses thats a bad example, but that kind of thing. 
00:22:02 <     stahnma> | I'll see what I can come up with
00:22:08 <       knurd> | I'd say we should not overengeneer the problem
00:22:18 <     stahnma> | knurd: ++
00:22:20 <       nirik> | perhaps just name is good enough.
00:22:26 <     stahnma> | I'll start there :)
00:22:26 <       knurd> | nirik, for the start
00:22:31 <       knurd> | then we can see what people need
00:22:35            <-- | mbacovsk has quit (Read error: 110 (Connection timed out))
00:22:41 <       knurd> | and provide more informations if really needed
00:23:26 <       nirik> | sounds good to me.
00:23:28 <       knurd> | stahnma, will you take care of it ?
00:23:48 <     stahnma> | yeah
00:23:59 <     stahnma> | give me a week or two
00:24:03 <       knurd> | k
00:24:07 <       knurd> | then let's move on now
00:24:25            --- | knurd has changed the topic to: EPEL Meeting| mandate for the Steering Committee
00:24:35 <       knurd> | I kicked the discussion of on fedora-devel
00:24:46 <       knurd> | I liked quaid's mail
00:25:13 <       knurd> | we just actually need to adjut some details to lower the influence of the Steering Committee
00:25:24 <       knurd> | to make "more power to the people" possible
00:25:34 <       knurd> | anything else regarding the topic?
00:25:48 <       nirik> | I liked that too...
00:26:03              * | knurd really should start sending out topic lists ahead of th meeting again
00:26:11 <       nirik> | so do we need to get any kind of ack from fesco? or we just switch to a SIG and move ahead as we like?
00:26:28 <       knurd> | nirik, well, I think we need a ack
00:26:48 <       knurd> | some kind of "we extend the mandate for the EPEL Steering Committe by 6 months / a year"
00:27:22 <       knurd> | nirik, can you make sure it gets discussed over the next two weeks maybe?
00:27:30 <       nirik> | yep.
00:27:38 <       knurd> | nirik, thx
00:28:05            --- | knurd has changed the topic to: EPEL Meeting | push quicker to stable
00:28:18 <       knurd> | seems this topic is getting discussed a bit more again
00:28:32 <       nirik> | I'm not opposed to faster pushes from testing... but we need to be carefull...
00:28:35 <       knurd> | my 2 cent: I'm fine with moving new packages over after four weeks or so
00:28:38 <    mmcgrath> | the current method has worked well for me both as a contributor and as a consumer.
00:28:52 <       knurd> | but updates to existing packages only should get over if there is a need to (and not automatically)
00:29:02 <       nirik> | are the redhat 'quarterly' updates really quarterly?
00:29:08 <     stahnma> | nirik: no
00:29:19 <     stahnma> | nirik: they are every-so-often
00:29:24 <       nirik> | yeah, thats what I thought.
00:29:31 <       knurd> | nirik, yeah, if they are not then we really should do them more often for new packages
00:29:32 <     stahnma> | 4-5 months lately, it seems like
00:29:46 <    mmcgrath> | But if we are trying to match RHEL as a great complimentary repo to RHEL, we just have to take their lead.
00:29:54 <       knurd> | with four people beeing alte to push we might have the manpower to do it soon
00:30:20              * | nirik is happy to do pushes after he gets trained on how to. ;) 
00:30:21 <       knurd> | but we'd need to prepare that one machine, check the deps, and after that do it in the repo
00:30:29 <       knurd> | to make sure all the deps are fulfilt
00:30:41 <       knurd> | mmcgrath, +1
00:30:45 <       nirik> | yeah.
00:30:48 <       knurd> | mmcgrath, but we are still in the early stages
00:31:01 <       knurd> | so pushing new packages (not updated ones) more often might be a good idea
00:31:22 <       knurd> | nirik, I'll tell you soon how to push
00:31:27 <    mmcgrath> | <nod>
00:31:47 <     stahnma> | ok
00:31:47              * | knurd has a headache today and will leave the keyboard right after the meeting
00:32:02 <       nirik> | yeah, how about weekly we push any new package that has been in testing for 4 weeks (provided it has no broken deps or anything)
00:32:21 <      Jeff_S> | I agree -- for the time being, it would be really nice to push 'new' packages to stable more often
00:32:30 <       nirik> | 5-6 months does seem a while to wait for your new package if it's all stable.
00:32:30 <       knurd> | nirik, well, I think that's do much work with the current tools
00:32:46 <       knurd> | nirik, I'd say one a months should be often enough
00:33:17 <       nirik> | yeah, I don't know how hard it would be... I am pretty good about doing scheduled tasks like that tho... so whatever works.
00:33:35 <    mpdehaan> | more often would be goodness
00:33:37 <       knurd> | nirik, I#d just say we try it once and see how much work it is
00:33:49 <       nirik> | yeah.
00:33:52 <       knurd> | and decide then if we do it each week, every two, or evrey four
00:34:01 <       nirik> | mpdehaan: yeah, would that meet your needs somewhat? you wanted faster pushes...
00:34:23 <      Jeff_S> | mpdehaan: btw, yum, createrepo, etc. are now in EPEL-4 testing if you hadn't noticed
00:34:24 <    mpdehaan> | haven't been following this chat too closely -- how often is how often?
00:34:42 <    mpdehaan> | anyhow, the problem is that testing can be any varying degree of unstable, while stable is very old
00:34:48 <    mpdehaan> | just some middle ground would would be great
00:35:01 <    mpdehaan> | Jeff_S, awesome
00:35:02 <       nirik> | it's not been decided yet. ;) We were thinking if a new package has been in testing a month it gets moved to stable.
00:35:02            <-- | LetoTo has quit (Read error: 110 (Connection timed out))
00:35:04 <      Jeff_S> | I think once a month or so is a good starting spot and we can see how that goes
00:35:04 <       knurd> | mmcgrath, I'd say "every four week" if likely for now
00:35:11 <    mpdehaan> | nirik, 1 month sounds great
00:35:12 <       knurd> | weeks
00:35:32 <       nirik> | bugfixes, updates, stay in testing until the next rhel quarterly unless they are security or major.
00:35:44 <       knurd> | well, anything else regarding this topic?
00:35:44 <    mmcgrath> | now are we saying the rpms have to be in testing for 4 weeks?  or if someone happens to build the night before a push, it goes?
00:35:51 <    mpdehaan> | umh, don't know about the quarterly business
00:35:53              * | knurd waits
00:36:01 <    mpdehaan> | just 4 weeks sounds great
00:36:10 <       knurd> | mmcgrath, we'd evaluate when we do it for the first time
00:36:23 <       knurd> | mmcgrath, we can check the buildtime of the packages
00:36:29 <      Jeff_S> | mmcgrath: I think they'd need to be in testing for some amount of time (which we can discuss)
00:36:34 <       nirik> | mmcgrath: I would say we try and look at whats in testing and only move things that are: a) new package and b) been there 4 weeks or longer
00:36:54 <       knurd> | should not be to hard, as we need to prepare it in a local test repo in any case, to make sure all deps are available
00:37:15 <    mmcgrath> | just a matter of the scripts.  It would be nice to keep this stuff as simple as possible though.
00:37:24 <       knurd> | mmcgrath, +1
00:37:41 <    mmcgrath> | thats one reason I like the current way, everyone knows what happens when and its easy to explain (even though we haven't actually done it yet really :)
00:37:42 <       knurd> | especailly as we might need new scripts once we switch to bodhi
00:37:56 <    mpdehaan> | X weeks is easy enough to explain :)
00:38:04            --- | stickster is now known as stickster_afk
00:38:42 <       knurd> | well, I'd say we move on now, and finetune the details somewhen else
00:38:50 <       nirik> | well, but it's not just X weeks everything pushes... so it's harder to explain. ;)
00:39:00 <    mmcgrath> | except that if we only do a push every 4 weeks, some people will have RPMs in there for 7.9 weeks.
00:39:29 <       nirik> | right. thats why I was thinking weekly, but not sure how much hassle it is.
00:39:29 <    mmcgrath> | s/there/testing/
00:40:00 <      Jeff_S> | nirik: or bi-weekly
00:40:15 <       knurd> | Jeff_S, let's seee how much work it is, and decide then
00:40:16 <       nirik> | I can post to the list and see what people suggest? or we just figure out whats feasable on the current scripts?
00:40:26 <      Jeff_S> | knurd: agreed
00:40:34 <      Jeff_S> | but it really depends on the people doing the pushing IMO
00:40:42 <       knurd> | nirik, let's try it once, and then decide or ask the list
00:40:46 <       nirik> | ok.
00:41:09              * | knurd moves on now if nobody yells
00:41:23            --- | knurd has changed the topic to: EPEL Meeting -- Free discussion around EPEL
00:41:28 <       knurd> | anything else to discuss?
00:41:49 <    mpdehaan> | I want a pony?
00:42:16 <       knurd> | the weather sucks
00:42:17 <       nirik> | I'm going to try and add security setup for epel... security team people are probibly greatfully accepted. ;)
00:42:50 <     stahnma> | I am trying to get some more #rhel and #rhn people involved here in EPEL
00:43:05 <     stahnma> | I just started today, so we'll see how it goes
00:43:22 <       knurd> | nirik, "security setup" as in: people that check security lists and makre sure all issues releavant to EPEL get solved?
00:43:24 <       nirik> | could we possibly get someone to write a redhat magazine article on epel? that might get to a lot more rhel folks...
00:43:40 <     stahnma> | can anyone write for RH magazine?
00:43:44 <       knurd> | nirik, mether indicated to write one weeks ago
00:43:46 <     stahnma> | if so, I would happily write it
00:43:49 <       knurd> | not sure if he ever did it
00:44:02 <    mmcgrath> | stahnma: I think so, I've written for it twice.  Send an email to gdk and ask for sure.
00:44:09 <     stahnma> | ok
00:44:15 <       nirik> | knurd: yeah, hopefully we can add it into the existing fedora setup. Make a audit/epel4 audit/epel5 files and track CVE's against epel packages... file bugs against them, make sure pushes happen for security, etc;
00:44:26 <       knurd> | stahnma, and ask mether if he prepared something already
00:44:31 <     stahnma> | ok
00:44:38 <       nirik> | oh, another thing... did folks see my clamav post?
00:44:38 <       knurd> | nirik, sounds great :)
00:45:24 <       knurd> | nirik, saw it, but I have a mental filter for anything with clamav in the topic ;-)
00:45:33 <       knurd> | well, no, I actually read it
00:45:57 <       nirik> | yeah, I can take it over if no one else wants to... (I'd prefer not to), but if I do, I would want to diverge a lot from the current package...
00:46:04 <       knurd> | and solving the problems with the packaging and compatapility with dag7rpmforge would be good
00:46:35 <       knurd> | nirik, well, I'd prefer if stuff is similar in Fedora and EPEL
00:46:40 <       nirik> | frankly, I would love to just use the dag version... perhaps even try and talk him into maintaining or something.
00:46:49 <       nirik> | yeah, thats the issue... :(
00:46:50 <       knurd> | but well, that won't work always, and this is such a case afaics
00:47:25 <       knurd> | nirik, I think going to use dag's version is fine 
00:47:27 <       nirik> | clamav is also a security nightmare. ;(
00:47:44 <       knurd> | (but I never looked to close at it in any case, so my opinion is not much worth)
00:48:05 <       nirik> | well, I didn't get much reply on the mailing list. I guess I will wait a while and then move forward.
00:48:23 <       knurd> | nirik, sounds good
00:48:25            --> | LetoTo (Paul Wouters)  has joined #fedora-meeting
00:48:42 <       knurd> | anything else?
00:49:03              * | nirik has nothing. 
00:49:11 <      Jeff_S> | nope
00:49:22              * | knurd will close the meeting in n
00:49:23 <    mmcgrath> | nothing here
00:49:25              * | knurd will close the meeting in 30
00:49:27            <-- | LetoTo  has left #fedora-meeting ( )
00:49:41              * | knurd will close the meeting in 15
00:49:42 <     stahnma> | thanks
00:49:46            <-- | stahnma  has left #fedora-meeting ( "Time for something else....")
00:49:56 <       knurd> | -- MARK -- Meeting end
00:49:56            --- | knurd has changed the topic to: Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel for meeting schedule
00:50:00 <       knurd> | thx everyone
00:50:02 <    mmcgrath> | thanks knurd
00:50:13 <       nirik> | thanks knurd


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]