Meeting Summary for yesterdays meeting

http://fedoraproject.org/wiki/EPEL/Meetings/20070304 = Meeting 20070304 = [[TableOfContents]] == 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 /!\ 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 :) }}}