Archive:EPEL/Meetings/20070304

Meeting 20070304

Attending

• dgilmore
• Jeff_S
• mmcgrath
• nirik
• quaid
• stahnma
• thl

Summary

• thl created a status page in the wiki to track which Fedora contributors are interested in EPEL; see http://www.fedoraproject.org/wiki/EPEL/ContributorStatus got a bit enhanced by him after some feedback he received during the meeting; he will announce this to fedora-maintainers during the wiki after he added some more questions and answers to the FAQ that especially Fedora Contributors might have

• one thing should be agreed on soon: rolling release, latest and greatest or a more carefull update approach? Answering that question is quite important before the mass of Fedora contributors starts to build packages for EPEL. The plan is to actually work out a solution during the next week (thl will try to write something up) on the list and ratify it in the next meeting on 20070311. Some highlights from the meeting log regarding this topic are between 00:16 and round about 00:32

• who is allowed to participate in EPEL -> the plan is to allow all Fedora contributors for EPEL. If you dislike that speak up now.

• dgilmore created a gpg key for signing RPMS

• dgilmore created the upload location and uploaded the first bunch of packages http://download.fedora.redhat.com/pub/epel/

• branching: EPEL5 currenly branches from devel, but and will soon be branched from FC-6 as devel might be to new for EL5. EPEL4 gets branched from FC-3. If one or both of those is not existent then the EPEL branch will get created from the Fedora devel branch

Full log

00:00 <     stahnma> | hello
00:00            --- | thl has changed the topic to: EPEL meeting!
00:00 <         thl> | hy stahnma
00:00 <         thl> | hi een
00:00 <         thl> | even
00:00            --> | jwb_gone (Josh Boyer)  has joined #fedora-meeting
00:00            --> | jwb_gone (Josh Boyer)  has joined #fedora-meeting
00:00            --> | quaid (Karsten Wade)  has joined #fedora-meeting
00:00            --> | quaid (Karsten Wade)  has joined #fedora-meeting
00:00 <         thl> | sorry, the "v" on my keyboard has some problems and works only half of the time :-/
00:01 <     stahnma> | thl needs a new keyboard
00:01 <         thl> | stahnma, a new notebook
00:01 <         thl> | laptop
00:01 <     stahnma> | ah
00:01 <       nirik> | sorry I'm late... here now. ;)
00:01              * | nirik just switched over to using his new d820 last night... so far so good.
00:02 <         thl> | nirik, welcome, you din#t miss anything yet :)
00:02            --> | jmbuser (John Babich)  has joined #fedora-meeting
00:03 <         thl> | I#d say that was enough time to wait for people to show up
00:03              * | quaid finally got the regular alert programmed into his cellphone, so made it this time
00:03 <         thl> | so let's get slowly started
00:03 <         thl> | I just created a new page in the wiki
00:03 <         thl> | see http://www.fedoraproject.org/wiki/EPEL/ContributorStatus
00:04 <         thl> | the stuff in the head explains the background for that page
00:04 <       nirik> | is that everyone from the fedora owners.list?
00:04 <         thl> | if people like the idea I'd like to send out a mail to arious fedora lists asking people to update their status
00:04 <         thl> | nirik, all from cvsextras in the Accounts system
00:05 <         thl> | the number of packages is from owners.list
00:05 <         thl> | but it's not exact, as some people use different e-mail adresses
00:05              * | thl waits for people to read the page
00:05 <       nirik> | humm... what does "interested" mean here... that they want to maintain packages? or that they will someday? or that they don't mind if others do?
00:06 <         thl> | good question
00:06 <       quaid> | thl: recommend the {{Template:Warning}} be swapped to be at the top, and set it up so people can just read that and go on (some people don't read :)
00:06 <         thl> | should probably be "interested in maintain packages..."
00:07 <         thl> | quaid, okay, will do
00:07 <       nirik> | I guess we could use 'yes' (ready to branch and maintain), 'no' don't want to branch and maintain, or 'perhaps' willing to help, but not now, or how no packages that should go into epel?
00:07 <     stahnma> | if it is a 'no' are we going to add a co-maintainer?
00:08 <         thl> | stahnma, no, only if there is a co-maintainer that actually wants to do the job
00:09 <     stahnma> | I suppose that is dependant on the packages that person has or doe snot have
00:09 <       nirik> | yeah...
00:09 <       quaid> | this page is contributor focused ...
00:09 <       quaid> | could it be package focused?
00:09 <       quaid> | or isthat too hard ?
00:09 <       quaid> | that is, hard to do on a Wiki
00:09 <         thl> | quaid, much to hard
00:10 <         thl> | we have oer 2500 packages
00:10 <         thl> | some people have more then hundret packages
00:10 <         thl> | your don#t want to flip yes/no for all of them
00:10 <         thl> | this way people see that the status of the contributor is
00:10 <         thl> | and can ask him, if a particular page is missing
00:10 <         thl> | that should be good enough
00:11 <         thl> | sure, a package based approach with a DB might have some adantages, but would be hard to set up
00:11 <       nirik> | yeah, I think this is usefull in that someone might have been asked before... we don't want to keep bugging someone if they don't want to deal with it.
00:11 <         thl> | this should do it afaics
00:11 <         thl> | nirik, +1
00:12            --> | aa33d (entr0py)  has joined #fedora-meeting
00:12 <         thl> | nirik, btw, regarding "I guess we could use 'yes' (ready to branch and maintain)," -- I'll put a more detailed section in the document that decribes what the different values mean
00:12 <       nirik> | ok, sounds good.
00:13 <         thl> | is it okay for you guys if I bug the mailig lists with it later?
00:13 <       quaid> | +1
00:14 <      Jeff_S> | sounds good to me
00:14 <       nirik> | +1 from me
00:14 <     stahnma> | +1
00:15 <         thl> | k, thx guys
00:15 <         thl> | I further plan to add a "EPEL for Fedora contributors" section to the FAQ
00:15 <         thl> | so people know how eerything is currently expected to work
00:15 <         thl> | but one thing should be agreed on soon:
00:16 <         thl> | rolling release, latest and greatest, more carefull update approach?
00:16 <         thl> | people might be wondering what they should build for RHEL4
00:16 <         thl> | (for RHEL5 is obvious: build what's currently in the FC-6 branch)
00:17 <       nirik> | I think it should be: release stable things, if there is a version update it only pushes out on minor release updates, ie, 4.4 to 4.5...
00:17 <     stahnma> | from a maintainer view, if the the current FC6 stuff will build against RHEL4, I would think they want to do that
00:17 <     stahnma> | perl modules for example
00:17 <         thl> | stahnma, well, there is a problem: a lot of current stuff won't build for RHEL4 as GTK2 for example is quite old
00:18 <     stahnma> | right
00:18 <       nirik> | in some cases it will... GUI still will not be as easy
00:18 <         thl> | and having a repo where some stuff is quite new, and others old, makes not that much sense
00:18            <-- | entr0py has quit (Read error: 110 (Connection timed out))
00:18 <     stahnma> | well, I agree with that
00:18 <         thl> | for perl-modules having "latest" might be okay and possinble most of the time
00:18 <     stahnma> | will we be asking quite a  lot of our maintainers though?
00:18 <       nirik> | well, part of the problem is that "stable" depends on the upstream project.
00:19            --- | BobJensen-Away is now known as BobJensen
00:19 <     stahnma> | have any people asked to do EPEL in RHEL 5 only and nor 4?
00:19 <     stahnma> | s/nor/not
00:19 <       nirik> | Perhaps instead of saying that people must backport everything, or always upgrade we should just have a "Goal: stable software. Backport if you can/need to, update if the new version is very stable"
00:19 <         thl> | stahnma, scop (Ville) indicated he's more interested in RHEL5 than RHEL4
00:19 <         thl> | s/RH//
00:20 <         thl> | nirik, +1
00:20 <         thl> | nirik, I'll try to put that into the faq before sending the mail out
00:20 <     stahnma> | defining "very stable" will be rough
00:20 <     stahnma> | unless we have some type of test suite
00:20 <      Jeff_S> | I think that's something best left to the contributor(s) to decide for each package
00:21 <       nirik> | yeah. There is upstream stable, and what the maintainer thinks is stable, and what the end user thinks is stable.
00:21 <     stahnma> | probably
00:21 <         thl> | Jeff_S, well, we should have a mostly common look and feel
00:21            --> | trondd (Trond Danielsen)  has joined #fedora-meeting
00:21 <      Jeff_S> | I think most people will not be willing to backport patches for very long, since it becomes quite a chore once you drop too far behind the current upstream release
00:21 <         thl> | a repo that in parts has quite old software while other parts are quite new is a bit confusing IMHO
00:21 <       quaid> | what if people want to update the dependencies by e.g. updating GTK2 for EL4? etc.
00:22 <         thl> | Jeff_S, well, the thing IMHO is: update only if there is a good reason
00:22 <       quaid> | pretty soon we're going to be looking at a stable and unstable branch
00:22 <     stahnma> | I think the rolling release when minor updates are released make the most sense to e
00:22 <         thl> | quaid, well, that would be replacing, and we don#t want that afaics
00:23 <     stahnma> | seems like if you want to start replacing EL components or core, you should run Fedora
00:23 <         thl> | quaid, one could come up with a GTK2 pacakge that lives in /opt and is used by rpaths -- but I doubt we really want that
00:23 <         thl> | stahnma, +1 to "I think the rolling release when minor updates are released make the most sense to me"
00:23              * | nirik shudders. No.
00:23 <       nirik> | replacing rhel stuff sounds like a bad idea to me. ;)
00:24 <       nirik> | I do like doing non security/bug updates only on minor version upgrades tho.
00:24 <         thl> | +1 for "I do like doing non security/bug updates only on minor version upgrades"
00:24 <     stahnma> | so should we commit a statement of direction then?
00:24              * | thl wonders where nirik got the impression we want to replace stuff from rhel
00:25 <     stahnma> | this will help each contributor decide if they are interested in EPEL
00:25 <         thl> | stahnma, that's why I brought the topic up
00:25 <       nirik> | well, there was talk about it on the list... not sure people were serious tho, or just didn't understand what it was...
00:25 <       quaid> | thl: it was my comment and your reply
00:25 <    mmcgrath> | Sorry guys,
00:25 <       quaid> | oh, ok
00:25              * | mmcgrath is here now.
00:25 <     stahnma> | thl, yeah, I mean, like, are we agreed on this?
00:25              * | mmcgrath reads up
00:25 <       nirik> | thl: yeah, I think we should get some consensus on the list before we push it out to the world tho.
00:26 <         thl> | nirik, I in parts agree, but that might take weeks :-((
00:26 <       quaid> | +1 to work it out on list, make a decision here in 7 days
00:26 <         thl> | +1 for quaid
00:26 <     stahnma> | +1 quaid
00:26 <       nirik> | one still unknown is if we push updates on minor release upgrades, is there any criteria for those updates? anything goes? or try and maintain stability, but new features/upgrades are ok?
00:26 <       nirik> | +1 quaid
00:27 <         thl> | nirik, +1 for "try and maintain stability, but new features/upgrades are ok" (maybe with the add-on "if there is a good reasons for them)"
00:27 <     stahnma> | nirik I think we try to move with upstream.  This is easiest for the maintainer and the admin running EPEL can look into the release before moving.  All the shops I know don't just go from update 4 to update 5 wtihout research and testing
00:28 <       nirik> | yeah, agreed.
00:28 <         thl> | stahnma, well, but the base we build for doesn#t move -- so why should we without a reasons?
00:28 <     stahnma> | thl trumps me with his logic
00:28 <         thl> | people use RHEL because it nearly doesn't move; I think EPEL should be similar
00:29 <     stahnma> | well, if look at EL each update normally *does* include movement from upstream, they just don't change hte version number
00:29 <       nirik> | so when rhel goes from X.N to X.N+1, would we want to start building and testing then? or would we want to have a testing repo ready with the updates?
00:29 <     stahnma> | for example, 3.6p1 of OpenSSH on RHEL3 has many features of 4.0 and greather
00:29 <         thl> | stahnma, some movement yes, but not much afaics
00:30              * | mmcgrath agrees with thl.
00:30 <         thl> | nirik, I'd say we should have a  testing repo in parallel, that becomes stable in parallel with the update
00:30 <         thl> | & of RHEL
00:31 <       nirik> | yeah, although if the new rhel minor bumps some things, it could break things that previously compiled in testing...
00:31 <    mmcgrath> | RHEL's just a rolling release with snapshots in time.
00:31 <     stahnma> | in theory a new RHEL minor shouldn't break anything (100% api/abi compat) :)
00:31 <    mmcgrath> | There's minor exceptions.
00:31 <         thl> | nirik, should be seldom afaics (and isnn't this a bug in RHEL then?)
00:32 <       quaid> | the way things are now, are EPEL maintainers going to be able to get access to the EL bits early enough?
00:32 <         thl> | quaid, no, I don't think so
00:32 <       nirik> | ok, just wanted to bring that up... ;) WOuld be fine if it didn't break anything.
00:32 <       quaid> | i.e., do we need to arrange some kind of beta channel for EPEL maintainers
00:32 <         thl> | they will get it when CentOS shipps them, and that some days/weeks after HEL
00:32 <     stahnma> | quaid: that would be ideal
00:32 <         thl> | quaid, I don't think that is needed
00:33 <         thl> | quaid, and we can do that later if we really need it
00:33 <       quaid> | ok
00:33 <    mmcgrath> | hmm
00:33 <     stahnma> | probably not a priority
00:33            <-- | aa33d has quit (Read error: 110 (Connection timed out))
00:33 <         thl> | quaid, would RHEL be willing to have such a channel for EPEL maintainers?
00:33 <       quaid> | it's likely we can do something, but it may require (just guessing) an NDA or something; OTOH, maybe the CLA is good enough there, we'd have to Seek Legal Advice
00:33 <         thl> | quaid, remember, some EPEL maintainers might not have RHEL at all
00:33 <    mmcgrath> | thl: What will be more likely is a xen instance people can 'reserve'
00:34 <       quaid> | thl: well, it's done for customers; can't see why it wouldn't work, but ...
00:34 <         thl> | mmcgrath, ohh, hmm, yes, that could work; I like the idea
00:34 <     stahnma> | mmcgrath: that would probably ok
00:34 <       quaid> | mmcgrath +1
00:34 <         thl> | mmcgrath, but nevertheless: probably not a priority
00:34 <    mmcgrath> | That just seams like less red tape.
00:35            <-- | kital has quit (Remote closed the connection)
00:35 <         thl> | so, who brings the discussion about the "packge upgrade guidelines" to the list?
00:36              * | thl probably has to do it
00:37 <         thl> | I'm not sure if I find time for it in the next two or three days, but I'll try
00:38              * | thl brought up the topics he wanted to see discuessed today
00:38 <       nirik> | yeah, I could try, but I need to try and catch up with core reviews soon. ;)
00:38 <     stahnma> | quaid: any progress on the Communication plans?
00:38 <         thl> | nirik, it's okay, I'll do it
00:38              * | thl simply ignores the merge reviews most of the time
00:39              * | stahnma tries to do one merge review a night
00:39              * | thl doesn't even read the fedora lists in that detail as in the past
00:39 <       nirik> | I was trying to do that, but got swamped at work and now new laptop fun. ;)
00:39 <         thl> | the benefits of not being in FESCO anymore
00:39 <       quaid> | stahnma: not yet; some of it is wanting to have our details make sense first
00:39 <       nirik> | anyhow, back to epel... anything else we want to discuss?
00:40              * | thl hasn't anything
00:40 <    mmcgrath> | I have one, branching.
00:40 <     stahnma> | quaid: agreed.
00:40 <    mmcgrath> | I swear this was discussed but I can't find it, who's allowed to request branches right now?
00:40 <       quaid> | stahnma: but I'll start to stub out a page today, and we can throw our pieces into it to stitch together later
00:40 <       nirik> | last I heard it was: sponsors and anyone with more than 5 packages...
00:40 <     stahnma> | dgilmore told me it wsa something about 5 packages
00:40 <    mmcgrath> | nirik: Is that written down somewhere?
00:41 <         thl> | mmcgrath, I think everyone is now
00:41 <    dgilmore> | sorry guys i slept in
00:41 <         thl> | we'll set up the release team soon to make sure that everything is properly maintained, even if the maintainers vanishes -- we afaics have to do this anyhow
00:41 <         thl> | hi dgilmore !
00:42 <    dgilmore> | hey thl
00:42 <         thl> | dgilmore, gpg-key? new rhel5 buildroot? did pushing work?
00:42 <       nirik> | mmcgrath: not that I know of. Perhaps we want to revisit it now?
00:42 <    dgilmore> | thl: gpg key is done
00:42 <    dgilmore> | what was built is pushed
00:42 <         thl> | dgilmore, great :)
00:42 <    dgilmore> | I havent been able to get the build root updated yet
00:43 <         thl> | mmcgrath, "Is that written down somewhere?" -> should be in a FESCo meeting log somewhere
00:43 <         thl> | mmcgrath, but I'd say we should allow everyone now
00:44 <         thl> | dgilmore, thx for your work
00:44 <       quaid> | +1 we don't want it to be too difficult to get in new EPEL maintainers
00:44 <       nirik> | +1 for allowing any maintainer to branch.
00:44 <     stahnma> | +1
00:44              * | thl takes that as accepted, and will add it to the wiki somewhere
00:44 <    dgilmore> | im ok with that
00:44 <       quaid> | esp. as we're advocating for customer-types to do it, standard Fedora process seems fine
00:44 <       nirik> | hopefully we won't get too many new folks who want to push a new game or something.
00:45              * | thl will at least write about it once to the list, before he adds it to the wiki
00:45 <     stahnma> | well initially not having dependencies will probably hinder game packages and several other larger packages
00:45 <    dgilmore> | thl: EL-5 is being branched from devel not FC-6
00:45 <         thl> | dgilmore, shoudn#t that be FC-6 now?
00:45 <       nirik> | stahnma: true.
00:45 <    dgilmore> | thl: i dont think so
00:46 <    dgilmore> | maybe it should be
00:46 <       nirik> | I haven't built any of my branched packages for el5... I have no way of test building or testing them yet.
00:46 <         thl> | devel might have quite new stuff (see bittorent)
00:46 <    dgilmore> | EL-4 is FC-3 if it exists if not devel
00:46              * | thl votes to create EL-5 branches for FC-6
00:46 <         thl> | dgilmore, that's fine afaics
00:47 <         thl> | s/for/from/
00:47 <    dgilmore> | i can make it so EL-5 does FC-6 if it exists devel if not
00:47 <         thl> | dgilmore, +1
00:47 <         thl> | other opinions?
00:48 <       nirik> | sounds fine to me.
00:48 <       nirik> | I don't think it much matters... maintainer can adjust as needed.
00:48 <         thl> | nirik, but FC-6 is better as safe default IMHO
00:49 <       nirik> | sure.
00:50 <         thl> | anything else to discuss?
00:50              * | thl takes that as "no"
00:50 <    mmcgrath> | nope :-)
00:51 <         thl> | shaltt we close the meeting ?
00:51 <         thl> | shall
00:51 <       nirik> | dgilmore: with the push, do we have mirrored repos yet?
00:51 <    dgilmore> | nirik: im not sure
00:51 <       nirik> | ie, is there yum.repos.d files that we can install and test with now?
00:51 <       nirik> | yeah, I don't have anything else, so closing down is fine with me.
00:51 <    dgilmore> | nirik: i need to create a epel-release package that can be installed and set everything up
00:52 <       nirik> | yeah. ok.
00:52 <    dgilmore> | along with mirrorlist stuff
00:52 <         thl> | dgilmore, +1 (but dgilmore has enough to do already afaics -- maybe somebody wants to leant a helping hand to dgilmore?)
00:53              * | thl does even more stupid typos today than he does usually already :-/
00:54 <         thl> | shall we close the meeting for today?
00:54 <     stahnma> | ok, thanks everyone
00:54 <         thl> | yeah, thx everyone!
00:54 <       nirik> | thanks thl
00:55            --- | thl has changed the topic to: http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel -- Meetings often get logged -- see schedule in the wiki for next meeting
00:55 <         thl> | nirik, I'm just doing this a bit like I did the meetings when I was FESCo chair
00:55 <         thl> | is that okay for everybody?
00:55 <       quaid> | +1 from me, works great
00:56 <       nirik> | yep. Works fine for me... we might want to ping the listg again and make sure this is a ok time... but seems to work for several of us at least.
00:56 <    jwb_gone> | there's a meeting going on?
00:56 <       nirik> | there was...
00:56 <    jwb_gone> | for?
00:57 <         thl> | epel
00:57 <       nirik> | EPEL...
00:57 <    jwb_gone> | oh, sorry.  wasn't paying attention
00:57 <    jwb_gone> | :)
00:57 <       nirik> | http://www.fedoraproject.org/wiki/EPEL/
00:58 <    dgilmore> | http://download.fedora.redhat.com/pub/epel/
00:58 <    dgilmore> | everything is there
01:01 <       nirik> | cool!
01:01 <       quaid> | dgilmore++
01:01              * | quaid says, "In your face, nay-sayers!"
01:01 <      Jeff_S> | dgilmore: cool :)