From Fedora Project Wiki
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 /<version>/{<arch>,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/<version>
00:27 < thl> | /<version>/{<arch>,SRPMS}/ and /testing/<version>/{<arch>,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