EPEL/Meetings/20070225

= Meeting 20070227 =

Attending

 * dgilmore
 * mmcgrath
 * nirik
 * stahnma
 * thl

Summary
It was the first meeting and had more a informal state; just chatting about random stuff regarding EPEL. Not easy to write a summary for this type of discussion, so we didn't try. Please see the full log below for the details.

Full log
00:00 <        thl> | ping dgilmore mmcgrath stahnma nirik quaid mdomsch 00:00           --- | thl has changed the topic to: EPEL meeting 00:00 <    stahnma> | present 00:00             * | nirik is here. 00:00 <   dgilmore> | thl: pong 00:01 <   dgilmore> | firt up i got owners.epel.list populated with everything branched yesterday 00:01 <    stahnma> | is this process using ACLs like extras? 00:01 <   dgilmore> | im working on getting the bugzilla sync process up 00:02 <    dgilmore> | it sets acls and bugzilla 00:02 <      nirik> | excellent work dgilmore 00:02             * | thl is on the phone 00:02 <        thl> | stupid phones... 00:02 <        thl> | sorry 00:02 <   dgilmore> | thl: :)  its ok 00:03 <       nirik> | were we planning on using acls? I thought we were planning for the more open approach? or you mean acls for only those people maintaining packages in epel? 00:03              * | thl got rid of the phone 00:03 <         thl> | hi everybody 00:04 <    dgilmore> | acls im not sure if they are implemnted on epel or not 00:04 <         thl> | dgilmore, I'd like to get rid of the ACLs at least for owners.epel.list 00:04 <         thl> | ans they will make things a lot complicated during the startup phase 00:05 <         thl> | dgilmore, is that possible? 00:05 <     stahnma> | should we have more open policies for packages that will probably be put on enterprise critical systems? 00:05 <    dgilmore> | thl: that can probably be done 00:05 <     stahnma> | I agree that ACLs are painful 00:05 <     stahnma> | but having more lax security on enterprise things seems to make less senses 00:05 <        thl> | dgilmore, I added it to the schedule; can I assignt it to you and set next week as target date? 00:05 <      nirik> | I'm conflicted about acls in general... I'm not sure the benefits outweigh the hassles... all security is a tradeoff. 00:05 <    stahnma> | agreed 00:06 <    stahnma> | just seems odd that EPEL would opt for usability 00:06 <   dgilmore> | thl: i was going to use a modified version of the script i wrote that would let owners.epel.list be populated when a package is branched 00:06 <        thl> | well, we probably have to lie with the ACLs anyway, if Fedora packagers start using it 00:06 <    dgilmore> | thl: sure 00:06 <        thl> | dgilmore, sounds like a good idea :) 00:06 <       nirik> | I think the package database (at least for acls) isn't too far off either, which will help. 00:07 <    mmcgrath> | pong 00:07 <    dgilmore> | maintaining owners.list is a pain in the ass 00:07 <       nirik> | yeah, package database will be much better in that too. 00:07 <         thl> | sorry, my keyboards "v" is still problematic, so now and then some words from me may miss one... 00:07              * | thl hopes also that the packagedb isn't that far away 00:07 <         thl> | welcome mmcgrath 00:08 <    dgilmore> | thl: i hope so too 00:08 <    dgilmore> | of the other things from fudcon 00:08 <    mmcgrath> | thl: toshio has done a lot of work, I think he's very near done.  The problem will be acceptance from others. 00:08 <    dgilmore> | we have master mirror space.  i need to find out where it is 00:08 <    mmcgrath> | s/done/done with version 1/ 00:08 <        thl> | so, how do we run this meeting? free chat, or do we want to go through the points of the schedule? 00:09 <   dgilmore> | i need to create a gpg key yet for signing packages 00:09 <   mmcgrath> | We could probably keep it free chat until that proves it doesn't work. 00:09 <   dgilmore> | i think free chat loosly based on the schedule 00:09             * | nirik is fine with whatever. 00:10 <   dgilmore> | i also still need to script updating the buildroots 00:10 <   dgilmore> | im going to have the bugzilla sync setup by toomoorow 00:10 <        thl> | what about RHEL5 builders? 00:10 <        thl> | do they still run beta1? 00:11 <   dgilmore> | i think for initial setup to get packages out we will use extras push scripts and put the updates system in as soon as possible 00:11 <      nirik> | is there any way to test El-5 currently? centos has no beta that I know of.... 00:11 <        thl> | centos has a private, non-public beta-phase currently 00:11 <   dgilmore> | thl: yes its still beta 00:11 <   dgilmore> | 1 00:11 <   mmcgrath> | http://buildsys.fedoraproject.org/needsign/fedora-5-epel/ ? 00:11 <   dgilmore> | buildroot packages have not been updates since they were setup 00:11 <        thl> | woudn't it be wise to get a new version on the builder? 00:12 <        thl> | maybe someone from red hat could get a hold on a nearly final rhel5 tree for our builders 00:12 <   dgilmore> | yes  i need to work out how to script pulling the binaries via up2date 00:13 <      nirik> | What is the status of lmacken's update system? EPEL could be a good testing ground before we go live and before he sets up the same for the rest of fedora updates. 00:13 <   dgilmore> | nirik:  I really want to just go with it. but its not ready yet 00:13 <        thl> | nirik, I'd prefer if we could use technics that are known to work over being a "testing ground" ;-) 00:13 <    dgilmore> | I do need to spend some time working with luke on it 00:14 <         thl> | would it be hard to adjust the extras push scripts for epel? 00:14 <       nirik> | ok. I wasn't sure if it was almost done, or needed more work. 00:14 <    dgilmore> | nirik: RHEL5 beta is available from ftp.redhat.com 00:14 <       nirik> | the src.rpms? or binaries too? 00:14 <    dgilmore> | thl: i just need to setup a config file 00:14 <         thl> | nirik, binaries, too 00:14 <    dgilmore> | nirik: binaries 00:14 <       nirik> | cool. Will have to check that out... 00:15 <         thl> | dgilmore, then I'd say we should go for the extras push scripts first 00:15 <    dgilmore> | so who for now will we have do the pushing of packages? 00:15 <       nirik> | I think we should just push to updates-testing until we are more clear on what final pushing policies are/ just initally testing? 00:15 <    stahnma> | if I understood the process, and had the proper access, I could help 00:16 <        thl> | nirik, +1 00:16             * | nirik would be willing to help as well... 00:17 <   mmcgrath> | nirik: thats a good idea. 00:17             * | thl counts two people who want to do boring tasks, so he does not volunteer 00:17 <   mmcgrath> | Even if it is just for a week, at least they'll be out there. 00:17 <        thl> | how would the layout on the serer look like? 00:17 <    stahnma> | will we have an S390 branch? 00:18 <        thl> | {testing/,}{4,5}/ ? 00:18 <      nirik> | I was thinking that we could say: everything goes to updates-testing. If it's a security or serious bug, it can go out. If it's an enhancement/upgrade/no know fixed bugs, it sits in updates-testing for a while. 00:18 <        thl> | stahnma, we have no builders for that afaics 00:18 <        thl> | nirik, and what do the builders build against? 00:18 <   mmcgrath> | stahnma: its not out of the question, but its not happening right now. 00:18 <    stahnma> | thl: fair enough. I don't know the demand for 390 either 00:19 <      nirik> | thl: builders should use base + all RHEL updates available. 00:19 <   dgilmore> | i can do it  also 00:19 <      nirik> | IMHO. 00:19 <        thl> | nirik, I meant regarding our proper repo and the testing repo 00:19 <   dgilmore> | we need to have a small number of people to do it 00:19 <    dgilmore> | stahnma: we dont have s390 builders 00:19 <      nirik> | oh, if builders will include testing/needsign? 00:20 <        thl> | nirik, agreed, but we need to be careful with the deps if something from testing gets pushed quicker than other stuff 00:20 <   dgilmore> | right now we will have i386 ppc x86_64 00:20 <      nirik> | dgilmore: agreed, but it would be nice if they were spread out time zone wize. 00:20 <        thl> | the current push scripts also don't handle testing nicely 00:20 <        thl> | it should be better with luke's stuff 00:21 <   mmcgrath> | Has anyone actually seen luke's stuff? 00:21 <   dgilmore> | thl: i think for now we just push the whole repo is testing 00:21             * | mmcgrath hasn't 00:21 <    dgilmore> | mmcgrath: i have 00:21 <        thl> | dgilmore, +1 00:21 <      nirik> | thl: agreed. 00:21 <   mmcgrath> | dgilmore: will it suit our needs? 00:21 <   dgilmore> | mmcgrath: indeed 00:21 <   mmcgrath> | solid :-) 00:21 <       nirik> | dgilmore: +1...lets gets some prelim testing bits out. 00:21 <     stahnma> | +1 for tesing currently 00:21 <         thl> | if you want to have a pusher from another timezone then it's probably means "thl" 00:21 <    dgilmore> | mmcgrath: there are a few details to work out  some of them I need to do 00:21 <         thl> | dgilmore, so count be in as signer, too 00:22 <    dgilmore> | thl: :) ok 00:22 <    dgilmore> | pretty much only one person pushes extras 00:22 <      nirik> | I could possibly also do sign/pushes on a schedule. ie, every morning at some time, etc. 00:22 <        thl> | having three or four signers that can push sounds enough to me 00:23 <       nirik> | yeah, mschwent? 00:23 <        thl> | nirik, I think so 00:23 <       nirik> | after I get my nifty new laptop, I should be able to run a centos image locally for testing too... make sure updates-testing doesn't break anything. I don't think I want to do that on any of my production boxes. ;) 00:24 <        thl> | so, directory layout on the server? 00:24 <         thl> | {testing/,}{4,5}/ ? 00:24 <    dgilmore> | nirik: yea 00:24 <     stahnma> | are there any plans to do anything for EL3? 00:24 <    dgilmore> | stahnma: nope 00:24 <     stahnma> | :( 00:25 <   mmcgrath> | It's only got till 2008 anyway right? 00:25 <   dgilmore> | if there is demand we can 00:25 <    stahnma> | I think 2009 00:25 <        thl> | stahnma, well, if there are enough volunteers, maybe, but I think we have bigger problems right now 00:25 <   dgilmore> | mmcgrath: somewhere there 00:25 <      nirik> | it's gonna be harder since the versions are so much older there. 00:25 <      nirik> | not to say that it wouldn't be usefull though. 00:25 <    stahnma> | yeah, I most businesses I see running Linux are still on RHEL 3 00:25 <    stahnma> | and just starting to move to 4 00:25 <        thl> | nirik, we could use the stuff from z00dax if we really want 00:26 <      nirik> | we still have a bunch of rhel3 client boxes... 00:26 <    stahnma> | actually 4 migrations started about 1 year ago 00:26 <   dgilmore> | thl: i think for now we go with  / /{ ,SRPMS}/ 00:26 <    stahnma> | but until lease ends, there isn't always a good reason to move 00:26 <      nirik> | but the clients with those don't seem very interested in any new software... whats working is fine for them. 00:26 <    stahnma> | ok 00:26 <         thl> | dgilmore, and where to put testing? 00:27 <   dgilmore> | thl:  /testing/ 00:27 <        thl> | / /{ ,SRPMS}/ and /testing/ /{ ,SRPMS}/ 00:27 <        thl> | dgilmore, okay, then we agree :) 00:27 <    dgilmore> | thl: but for now we wont use testing  just put in place  but have the whole repo marked as testing 00:27 <    dgilmore> | yup 00:27 <       nirik> | so will these be available with a up2date setup? or require yum/ 00:27 <       nirik> | ? 00:27 <    dgilmore> | nirik: up2date 00:27 <         thl> | dgilmore, wound't it be better to put eerything in testing for now 00:28 <         thl> | and when it works moe everything over to proper? 00:28 <    dgilmore> | thl: maybe 00:28 <         thl> | that would make it obvious that its still in the testing phase 00:28              * | thl would prefer such a approach 00:28 <       nirik> | I reviewed yum-arch, we might need to branch that to do the old style yum/up2date repos. 00:28 <         thl> | btw, do we really need yum-arch? 00:29              * | thl is not that sure which kind of repo setup up2date from RHEL4 needs 00:29 <      nirik> | 4 might not need it. I know 3 does. 00:29 <        thl> | yeah, but we don't do 3 for now... 00:29 <        thl> | I think 4 was the first one with the new repo format (but I'm not sure) 00:29 <    stahnma> | It should be used to generate repository informations for Fedora Core  < 3 00:29 <    stahnma> | and RedHat Enterprise Linux < 4. 00:30 <    stahnma> | so yeah, 4 is in the new forma 00:30 <        thl> | stahnma, great, thx 00:30 <      nirik> | cool. 00:30 <        thl> | so, what about my mail to fedora-devel and the stuff I did to the wiki? 00:30 <        thl> | do you guys like it? 00:31 <        thl> | did I forget anything important? 00:31 <   dgilmore> | thl: whatever we need to do to create metadata understood by up2date and yum we will do 00:31              * | nirik has been swamped and hasn't had a chance to reply yet... I think it mostly looked good. 00:32 <        thl> | dgilmore, sure, but seems createrepo is enough for that as far as I and stahnma can remember 00:32             * | thl should install RHEL4 into a m somewhere to be sure 00:32 <   dgilmore> | thl: i liked it   i thought the discussion should happen on fedora-maintainers  but thats minor 00:32 <    stahnma> | I got it from repoquery -i yum-arch 00:32 <    stahnma> | so unless the doc is wrong, we're good 00:32 <        thl> | dgilmore, well, that would exclude centos people 00:32 <        thl> | and that's what I wanted to avoid 00:32 <   dgilmore> | thl: didint think of that 00:33 <      nirik> | should we look at requiring co-maintainers for all epel packages? or just having the Release manager team be ok? 00:33 <   mmcgrath> | rumor has it that max had a good talk with the centos guys at fosdem. EPEL will be a good way to further bridge the gap. 00:34 <        thl> | nirik, I'd say we should aim to have two maintainer per pacakge 00:34 <   mmcgrath> | nirik: we haven't really talked about actual implementation with that. 00:34 <        thl> | but I think the Release manager team should bridge the gab for the start 00:34 <        thl> | mmcgrath, sounds promising 00:34 <   mmcgrath> | thl: Is there an easy way to require that other than policy? 00:35 <    stahnma> | a fun perl script on owners.list ? 00:35 <        thl> | nirik, yes, we didn#t talk about the "Release manager team " - it was just a idea of mine 00:35 <   dgilmore> | thl: i agree for now we nee a release team of 4 or 5 who can step up to do anything to any package as needed 00:35 <        thl> | mmcgrath, well, it probably needs to be a policy, but I'd like to avoid special EPEL policies for the start pjhase as much as possible 00:35 <        thl> | to keep things easy 00:35 <      nirik> | we could require that there be co-maintainers before branching the package in the first place... but we would need to go back and change all the already branched ones. 00:36 <        thl> | nirik, I think we have enough problems getting maintainers in the first place 00:36 <   dgilmore> | nirik: not sure on that 00:36 <        thl> | we shouldn#t make it more hard by requiring co-maintainers 00:36 <      nirik> | thl: agreed. 00:36 <    stahnma> | could we just say the release manager by default are co-maintainers? 00:36 <        thl> | stahnma, well, I don#t think we should "say" that 00:36 <        thl> | they simply are 00:36 <    stahnma> | ok 00:37 <         thl> | but they should only jump in if maintainers don#t do their job 00:37 <    stahnma> | +1 00:37 <        thl> | nirik, mmcgrath, do you like the ""Release manager team" idea, too? 00:38 <       nirik> | sure, sounds good to me. 00:38 <    mmcgrath> | Yeah, we need to be careful to make sure it scales well. 00:38 <    mmcgrath> | I'd hate to have a small team get ditched with a few hundred packages. 00:40 <         thl> | mmcgrath, well, I#d prefer if the team gets not to much work at all 00:40 <    dgilmore> | mmcgrath: indeed 00:40 <         thl> | as the maintainers should do their job, and we should make them do it 00:40 <    dgilmore> | i think part of the teams job is to get and keep maintainers 00:40 <       nirik> | I would imagine there will be many fewer packages than former extras/ core has. ;) 00:40 <         thl> | otherwise they will rely on the team 00:41 <       nirik> | agreed. 00:41 <    mmcgrath> | focusing on finding people to do work, and keeping them there is probably better than doing the work themselves. 00:41 <        thl> | mmcgrath, +1 00:41 <    stahnma> | mmcgrath has middle management written all over him 00:41 <   dgilmore> | right now there is 102 EL-4 branches 00:41 <   mmcgrath> | heh 00:41 <   mmcgrath> | dgilmore: buhhahaha, thats hilarious considering its NOT EVEN PUBLIC yet :-) 00:42 <    dgilmore> | mmcgrath: yeah .  i only realised that when i setup the script to make sure everything had an owner 00:42 <     stahnma> | once the build system/process is concrete, we will need a templated way to ask to current maintainers to branch for EPEL, or at least offer them first-refusal 00:42 <       nirik> | Should we force rebuild everything before putting packages in a testing repo? some of those might be pretty old by now... 00:43 <         thl> | stahnma, my plan was to ask the maintainers of many people in a private mail what there plans regarding epel are 00:43 <       nirik> | stahnma: agreed. 00:43 <    dgilmore> | stahnma: they have that now  set cvs-fedora flag to ? of the inital review and request the branch 00:43              * | stahnma would be happy to write said template, if he understood how branching/building and such would work 00:43 <      nirik> | I need 2 packages as requirements for munin which I would like to get in... so I should probibly mail the extras maintainer and ask if they want to branch... 00:43 <        thl> | dgilmore, how do we do branching? 00:43 <   dgilmore> | thl: the same  as extras 00:44 <        thl> | dgilmore, that might be complicates if maintainers with more than fie packages want to get EL branches 00:44 <        thl> | dgilmore, that requires bugs now? 00:44 <   dgilmore> | thl: yes 00:44 <    stahnma> | do we have a timeframe for when EPEL reaches a mature state? LIke main packages with dependencies? 3 months? 6 ? 00:44 <        thl> | dgilmore, so what about all those packages from the fedora.us days? 00:44 <   dgilmore> | unless we setup a CVSEPELSyncNeeded page 00:44 <        thl> | +1 for CVSEPELSyncNeeded 00:44 <   dgilmore> | thl: open a bug requesting it 00:44            --> | entr0py (Bernard Johnson) [n=bjohnson@c-67-172-144-52.hsd1.co.comcast.net]  has joined #fedora-meeting 00:44           --> | entr0py (Bernard Johnson) [n=bjohnson@c-67-172-144-52.hsd1.co.comcast.net]  has joined #fedora-meeting 00:44           --> | entr0py (Bernard Johnson) [n=bjohnson@c-67-172-144-52.hsd1.co.comcast.net]  has joined #fedora-meeting 00:45 <        thl> | dgilmore, will do 00:45 <    dgilmore> | stahnma: nothing set in stone yet. 00:45 <    stahnma> | k 00:45              * | mmcgrath br 00:45 <         thl> | I#d really like to get EPEL running quickly 00:46 <   dgilmore> | thl: me too 00:46 <    stahnma> | me too 00:46 <        thl> | if we wait to long, then z00dax might start building for RHEL5 00:46 <        thl> | that would confuse things 00:46 <        thl> | of course he is free to do 00:46 <    dgilmore> | thl: if i setup the branching scripts so that they populate owners.list  it will make things less painfull 00:46 <        thl> | but he iirc indicated he wouldn't do that if epel lifts of 00:47 <    dgilmore> | thl: we need to get cracking 00:47 <      nirik> | I want to see things running, but I don't think we should move so fast we mess up. ;) 00:47 <   dgilmore> | right now my biggest focus is buildsys and updates system 00:47              * | mmcgrath back 00:48 <       nirik> | yeah, once we have testing bits that will really help I think. 00:48              * | stahnma would like to work with quiad on the docs and communcation plans 00:48 <    dgilmore> | nirik: indeed things need to be done right 00:48 <    dgilmore> | stahnma: you are in a great position to help with that  and to know what is wanted/needed by our audience 00:49 <         thl> | so, can people actually build for EL-5 already? 00:49 <    dgilmore> | thl: yes 00:50 <         thl> | I mean 00:50 <    dgilmore> | thl: but it builds against beta 1 00:50 <     stahnma> | what is the target date for GA RHEL 5? 00:50 <         thl> | is it wise to build against beta1? 00:50 <    dgilmore> | stahnma: next week i believe 00:50 <     stahnma> | I thought I heard march 15 00:50 <   dgilmore> | thl: no i need to get that updated 00:50 <        thl> | I'd prefer if we could quickly update the builders to something "close to RHEL5" 00:50 <    stahnma> | but, I might have made that up in my head 00:50 <   dgilmore> | i thought 28th  but im probably wrong 00:51 <        thl> | dgilmore, it got "delayed" a bit 00:51 <   dgilmore> | thl: ill work on that 00:51 <   mmcgrath> | hmm 00:51 <        thl> | dgilmore, thx, I think that important at this point 00:51 <    stahnma> | dgilmore: I wil ping sales and find out :) 00:51 <       nirik> | I didn't build my packages for el-5 yet, since I had no way to test in mock before building. 00:51 <         thl> | nirik, agreed, that's a bit "problematic" 00:52 <       nirik> | also, if you do 'make mockbuild' in a EL-4 branch, it picks up fc4... ;) 00:53 <   dgilmore> | nirik: really 00:53 <   dgilmore> | hmm 00:53 <   mmcgrath> | uh-oh 00:53 <      nirik> | at least I thought it still does that. let me check. 00:53 <   dgilmore> | nirik: ill look at that now i know about it 00:53 <       nirik> | I just manually ran my mockbuild, and it worked fine. 00:55 <   dgilmore> | nirik: cool 00:55 <   dgilmore> | so does anyone have anything to add? 00:55 <      nirik> | the Makefile.common is still wrong... 00:55 <      nirik> | mock  -r fedora-4-x86_64-core.cfg --resultdir=/home/kevin/fedora-extras/mussh/EL-4/mussh-0_7-1_el4 /home/kevin/fedora-extras/mussh/EL-4/mussh-0.7-1.el4.src.rpm 00:56 <   dgilmore> | nirik: ill look at it and fix it 00:56 <       nirik> | dgilmore: thanks. 00:56 <    stahnma> | will the schedule/tasks be updated? 00:56 <        thl> | stahnma, I'll take care of that 00:56 <   dgilmore> | I'm going to concentrate on the infrastructure needs. and make sure that things needed to support EPEL are in place 00:56 <    stahnma> | I'll try to find quaid 00:57 <    stahnma> | this week and get a few drafts started 00:57             * | thl afk for a moment 00:57 <        thl> | I'll try to write a summarie, to 00:58 <    mmcgrath> | dgilmore: as always let me know if you need anything. 00:58 <   dgilmore> | mmcgrath: will do 00:59 <    dgilmore> | im going to leave alot of the getting other stuff done up to the rest of you guys. If you need me then holler at me 01:00 <   dgilmore> | is everyone ok with that? 01:00 <   mmcgrath> | Yep, and we are at the 1 hour mark :-) 01:00 <    dgilmore> | :) meeting end? 01:01 <   mmcgrath> | Till next week guys? 01:01             * | nirik has to go... thanks everyone. 01:01 <    stahnma> | thanks 01:11 <        thl> | thanks everyone 01:11 <        thl> | sorry, I had to leave early