17:01:13 <jds2001> #startmeeting
17:01:17 <nirik> jds2001: just do a #startmeeting, then #chair bpepple dgilmore dwmw2 jwb notting nirik sharkcz jds2001 j-rod
17:01:25 <nirik> then a #meetingtopic FESCo meeting
17:01:33 <jds2001> #chair bpepple dgilmore dwmw2 jwb notting nirik sharkcz jds2001 j-rod
17:01:38 <nirik> then use #topic for each item
17:01:48 <nirik> cool.
17:01:58 <jds2001> #meetingtopic FESCo meeting 2009-06-12
17:02:13 * dgilmore is here
17:02:48 <jds2001> alright, just a reminder I'm dropping off the planet next week.
17:02:58 * jds2001 will be in the middle of a lake :)
17:03:19 <nirik> hopefully in a boat. ;)
17:03:26 <jds2001> nirik: indeed :)
17:04:00 <jds2001> so anyone volunteer to chair the meeting and send out the agenda?
17:04:25 * nirik can do it.
17:04:43 <jds2001> awesome.
17:05:15 <jds2001> #action nirik will chair next week's meeting
17:05:41 * nirik notes commands are now at http://wiki.debian.org/MeetBot (it's now named 'meetbot')
17:05:42 <jds2001> also, a reminder that elections are open. Go vote :)
17:06:11 <jds2001> And lastly on the admin front, the retrospective meeting....
17:06:24 <nirik> #info Please go vote in FESCo, Board and f12 naming elections.
17:06:25 <jds2001> who wants to attend? I'll be there, we need one more.
17:06:44 <nirik> jds2001: when is it?
17:06:58 <notting> next tuesday, at 2PM EDT
17:06:59 <jds2001> Tuesday at 10AM EDT
17:07:09 <notting> erm, 10AM. i can't read.
17:08:19 * nirik can't make that I don't think. Have some stuff tuesday morning. ;(
17:08:31 <notting> i can go, but if someone else is chomping at the bit...
17:08:46 * dwmw2 on jury duty this week and next, so not very available
17:08:53 <j-rod> I'd be willing to do it
17:09:36 <jds2001> k, shall we say j-rod is gonna do it?
17:09:56 <bpepple> sounds good.
17:10:04 <jds2001> #action j-rod will attend the F11 release retrospective meeting
17:10:26 <jds2001> onto the tickets
17:10:37 <jds2001> #topic EOL date for F-9
17:10:37 <j-rod> now if that could automagically feed an event to a caldav server and sync to my iphone...
17:10:46 <jds2001> .fesco 160
17:10:50 <zodbot> jds2001: #160 (Announce EOL date for F-9) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/160
17:10:54 * j-rod enters it manually for the time being
17:11:31 <nirik> 10th is fine with me.
17:11:31 * bpepple has no problem with the proposed F-9 EOL date.
17:11:38 <notting> seems reasonable
17:11:41 <j-rod> worksforme
17:11:46 <jds2001> jwb notes that due to the July 4 holiday, that last week will be full of updates. If there are push issues, we might not get em all.
17:11:53 <dgilmore> f13: does the 10th work for you for EPL of F-9?
17:11:56 <sharkcz> works also for me
17:12:14 * dgilmore notes that its ok with him
17:12:26 <jds2001> fine here too.
17:12:32 <dwmw2> ok
17:13:11 <jds2001> #agreed EOL date for F-9 will be 2009-07-10
17:13:31 <jds2001> #topic Milestone adjustment proposal
17:13:35 <jds2001> .fesco 162
17:13:38 <zodbot> jds2001: #162 (Milestone Adjustment Proposal) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/162
17:14:04 <nirik> has there been any feedback on lists or wiki?
17:14:15 * nirik just sees one 'sounds fine to me' comment on the discussion page
17:14:25 <notting> yeah, haven't seen much
17:14:54 <jds2001> +1 here, just naming changes to make it more sane.
17:15:04 <notting> this is the most self-contained and implementable proposal from the FAD this week
17:15:38 * jds2001 wishes he could have been there. Too many conflict
17:15:40 <jds2001> s
17:15:41 <j-rod> +1, works for me
17:15:44 <sharkcz> +1
17:15:48 <notting> i strongly suggest fesco members read all the proposals in https://fedoraproject.org/wiki/Category:Proposals and comment
17:15:49 <nirik> seems fine to me.
17:15:51 <notting> +1 to this one
17:16:06 <dwmw2> +1
17:16:07 <bpepple> +1 here also.
17:16:28 <jds2001> #agreed proposal at https://fedoraproject.org/wiki/Milestone_Adjustment_Proposal is accepted.
17:16:36 <dgilmore> +1 seems fine things change so much between alpha and beta
17:17:02 <jds2001> #topic F-9 branch for olpc-kbdshim
17:17:09 <jds2001> .fesco 163
17:17:13 <zodbot> jds2001: #163 (Allow F-9 branch for olpc-kbdshim) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/163
17:17:26 <nirik> they want this for existing olpc users.
17:17:36 <nirik> who use the f-9 fedora packages.
17:17:38 <jds2001> yep
17:17:54 * nirik wonders what they will do when f9 is eol?
17:18:05 <jds2001> good question.
17:18:05 <dgilmore> -1 from memory it wont beavailable to OLPC G1G1 users as the yum repos point at olpc specifci ones
17:18:06 <nirik> is that branch continuing to be supported some other way?
17:18:24 <nirik> dgilmore: didn't they point to koji?
17:18:50 * nirik notes that olpc uses their own weird update thing, not yum by default.
17:18:52 <dgilmore> nirik: for awhile yes
17:19:19 <nirik> perhaps we could ask what users this would help with in the ticket? as it's unclear?
17:19:23 <dgilmore> nirik: but last i knew it was moved to olpc ran infrastructre that was updated by a script mirroring koji
17:19:24 <nirik> or is the submitted on irc?
17:19:46 <jds2001> .fasinfo cwickert
17:19:48 <zodbot> jds2001: User: cwickert, Name: Christoph Wickert, email: fedora@christoph-wickert.de, Creation: 2005-09-18, IRC Nick: cwickert@irc.freenode.net, Timezone: Europe/Berlin, Locale: de, Extension: 5100271, GPG key ID: 1999A427, Status: active
17:19:50 <zodbot> jds2001: Approved Groups: cla_done fedorabugs packager ambassadors cla_fedora gitnodoka gitspin-kickstarts provenpackager
17:19:52 <zodbot> jds2001: Unapproved Groups: None
17:20:11 <notting> he *was* on irc...perhaps he left for the evening
17:20:15 <nirik> well, he was reviewing the package... the request was from the submitter really.
17:20:25 * dgilmore is verifying where XO's point at for updates
17:20:35 * nirik waits for bugzilla to try and load
17:20:42 * dgilmore olso notes yum was not historically recommended by olpc
17:21:08 <jds2001> what was? the gui activity installer thingy?
17:21:33 <nirik> 'olpc-update' I think...
17:21:38 <nirik> which basically rsynced a new image.
17:21:42 <jds2001> oh, right.
17:21:51 <jds2001> how quickly I forget :)
17:21:54 <nirik> .fasinfo pgf
17:21:55 <zodbot> nirik: User: pgf, Name: Paul Fox, email: pgf@laptop.org, Creation: 2009-06-05, IRC Nick: pgf, Timezone: US/Eastern, Locale: en, Extension: 5131621, GPG key ID: , Status: active
17:21:58 <zodbot> nirik: Approved Groups: cla_done fedorabugs packager cla_fedora
17:22:00 <zodbot> nirik: Unapproved Groups: None
17:22:50 * nirik summons pgf
17:23:28 <nirik> hey there. We are looking at that F-9 branch request...
17:23:39 <pgf> i figured. :-)
17:23:40 <nirik> .fesco 163
17:23:45 <zodbot> nirik: #163 (Allow F-9 branch for olpc-kbdshim) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/163
17:23:57 <nirik> can you tell us which olpc users would be able to use that f-9 package?
17:24:27 <pgf> all of them. well, those running fedora with access to a yum repo.
17:24:53 <nirik> how many upgrade via yum? and does that point to f-9 fedora repos? koji repos? your own repo?
17:24:54 <jds2001> the G1G1 images dont have yum pointed at F-9, right?
17:25:13 <dgilmore> jds2001: they actually do with a massive exclude line
17:25:25 <dgilmore> but yum update fails misserably
17:25:56 <pgf> perhaps my request was misguided. from the yum output on my XO, i thought it would Just Work. perhaps not?
17:26:11 <nirik> pgf: yeah, thats what we are wondering... if it matters at all in the end. ;(
17:27:27 <pgf> is there a way to tell easily? i mean, i can do things like install "dialog" via yum, and i know OLPC didn't build that specially.
17:27:48 <nirik> pgf: not sure. ;( Should we table this and try and find out?
17:28:12 <dgilmore> pgf: how will users know to install the package
17:29:41 <pgf> dgilmore: well, that's a good question. i guess i was primarily thinking of those that are "in the loop", on either the olpc lists or the olpcnews forum. and it might make it easier for deployments, which often do custom releases, to use it if they did find out about it.
17:30:58 <pgf> this isn't a critical thing at all. i just figured that because there was no F10 for the XO, that maybe an exception made sense (assuming it works).
17:31:35 <dgilmore> pgf: ok. i guess i wont really hurt
17:32:16 <nirik> I don't object if it will help anything... but it's unclear to me if it will or not.
17:32:36 <jds2001> well dgilmore said they are pointed at f-9
17:32:56 <jds2001> so yum install olpc-kbdshim should work.
17:33:34 <jds2001> even if yum update barfs
17:35:00 <j-rod> doesn't seem like it can possibly hurt anything
17:35:01 <j-rod> just do it
17:35:26 <notting> pgf: is this an exception, or the beginning of a list of exceptions?
17:35:40 <j-rod> ah, good question...
17:36:00 <j-rod> yeah, if there's going to be a stream of them, would have to reconsider...
17:36:15 <pgf> i think this is an exception.
17:36:33 <nirik> pgf: what happens when f9 is end of life? you guys have some way to keep maintaining those installs? or that should be EOL and move to the newer releases?
17:36:54 <notting> pgf: ok. +1 then
17:37:14 <pgf> we don't have tight control over what the deployments do of course. but we're working on F11.
17:37:31 <pgf> we just don't have the resources to track every release.
17:37:37 <nirik> yeah.
17:37:40 <j-rod> +1 here, with the caveat that the branch won't be updateable anymore in a month... but at least there will be a package available for those users.
17:37:56 <nirik> so, yeah, +1 from me too given that
17:37:58 <jds2001> +1 here
17:38:00 <sharkcz> +1 here too, the reasons make sense
17:38:12 <bpepple> +1
17:38:21 <dwmw2> +1
17:38:51 <jds2001> #agreed olpc-kbdshim may have a branch for F-9, with the understanding it won't be updateable in a month.
17:38:55 <jds2001> thx pgf :)
17:39:06 <pgf> thanks! glad i was around...
17:39:35 <nirik> pgf: go ahead and set fedora-cvs again there and I will do it on my next cvs pass.
17:39:53 <jds2001> #topic EPEL steering committee review
17:39:53 <pgf> nirik: okay.
17:40:01 <jds2001> .fesco 164
17:40:06 <zodbot> jds2001: #164 (EPEL Steering committee review) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/164
17:40:22 <notting> do we have reps from epel steering committee here today?
17:40:25 <smooge> I am here
17:40:31 * nirik is here.
17:40:33 <smooge> I didn't know about this til this moment
17:40:40 * nirik puts on multiple hats.
17:40:54 <smooge> ok I agree with the above.
17:41:10 <nirik> I agree things have been stagnating in EPEL land. How can we revive them?
17:41:17 <smooge> I have gone a crappy job since Novemebt
17:41:22 <jds2001> smooge: it's pretty much a verbatim copy of what was on epel-devel.
17:41:28 <nirik> FYI, I think EPEL is much more a SIG than a Project (to use our terms)
17:41:39 <dgilmore> smooge: i added it late today
17:41:42 <jds2001> smooge: it's not just you. :)
17:41:47 <smooge> I am catching up with that.. I am trying to get out of a job this week so have skipped 99% of my email
17:42:18 * nirik is happy to step aside, try and do meetings again, or whatever.
17:42:44 <smooge> The issues are: 1) People who are interested in it are on 8-12 hour difference schedules.
17:42:49 <nirik> we need more people interested, more community. I think a lot of people are just waiting for koji/bodhi. Perhaps we can try and get people involved there to speed up that transition?
17:42:53 <smooge> getting everyone together is a problem.
17:43:54 <dgilmore> nirik: im going to hack together a way to do pushes from koji and try and switch epel to koji next weekend
17:44:04 <smooge> 2) we have an odd infrastructure that should be fixed Real Soon Now* but the RSN has been so long people drifted off.
17:44:06 <nirik> I've tried to get regular meetings going several times. ;(
17:44:07 <dgilmore> but bodhi still needs doing
17:44:54 <jds2001> dgilmore: koji can distribute signed packages, no?
17:45:03 <nirik> many of the orig folks wandered off as well (perhaps things were going well enough they just thought it was low priority?) perhaps they got busy and didn't have time anymore, not sure.
17:45:14 <dgilmore> jds2001: mash can make repos of signed packages
17:45:21 <nirik> dgilmore: that would be great. Let me know if I can do anything to help.
17:45:56 <dgilmore> jds2001: ill need to make some mash configs run sign_unsigned.py and have a way to move packages around
17:46:20 <nirik> dgilmore: will there be a epel-releng1 box to mash on?
17:46:28 <nirik> will epel_signers be able to push using this?
17:46:29 <dgilmore> im going to propose that builds only land in buildroots when things go to stable
17:46:36 <dgilmore> nirik: there will be
17:46:50 <nirik> ok.
17:47:05 <dgilmore> so there will be need to request tagging into buildroot override tags
17:47:33 <nirik> right. If we do that I would propose a trac instance to track those requests.
17:47:45 <notting> such as rel-eng@?
17:47:54 <nirik> anyhow, what can fesco do to push epel back into more active mode?
17:48:16 <jds2001> well I can make a trac instance :)
17:48:17 <nirik> notting: yeah. Does rel-eng want to take on the tasks they do for fedora for epel too?
17:48:36 <smooge> for the non-technical talk.. I think EPEL needs a good rethink and relook with the people current in it. It needs to also be ready for EL-6 and needs better take from our 'downstream' so that we aren't colliding as much
17:48:50 <dgilmore> i think fesco needs to get regualr updates as to whats going on
17:48:57 <dgilmore> even if that is nothing new
17:49:17 <notting> nirik: perhaps with an epel volunteer stepping up to join? :)
17:49:30 <nirik> dgilmore: ok, why in epel and not other sigs? or are you supposing epel is a project ?
17:49:40 <notting> (just saying that rel-eng at least already has policies & procedures for this)
17:49:49 <dgilmore> nirik: secondary arches need to do it also
17:49:51 <nirik> notting: well, I don't mind tagging packages, doing signs and pushes at all.
17:50:09 * nirik is fine with regular repedative tasks... cvsadmin has taught me that well. ;)
17:50:51 <nirik> dgilmore: so, it sounds like I should try and get regular meetings going again then? although I have no idea if it will work any better this time than the last 2.
17:51:24 <dgilmore> nirik: i think that would be a help
17:51:27 <notting> dgilmore: yeah, a monthly epel report would be nice
17:51:38 <smooge> nirik, I should be better off starting next week on being at meetings and doing reports
17:51:39 <dgilmore> nirik: most of the mail on the mailing list is the push emails
17:51:57 <smooge> and would be able to help you get things done
17:51:58 <nirik> dgilmore: yeah, but I think many people are just happy with it the way it is...
17:51:59 <dgilmore> general talking on the mailing list seems to be down a bit also
17:52:17 <nirik> there is only one really important item I know of that should get addressed.
17:52:20 <dgilmore> nirik: that may well be the case. if so it is what it is
17:52:30 <nirik> openjdk
17:52:48 <dgilmore> it cant be there for i386/x86_64
17:52:53 <jds2001> yeah
17:52:55 <dgilmore> the plugin could be
17:53:03 <dgilmore> it can be there for ppc
17:53:06 <nirik> dgilmore: agreed. However it still is.
17:53:21 <nirik> it should be removed for now I guess.
17:53:29 <dgilmore> nirik: likely yeah
17:53:34 <jds2001> s/for now/forever :)
17:53:43 <nirik> well, the plugin can be there.
17:53:52 <smooge> jds2001, or until downstream drops it
17:53:53 <dgilmore> jds2001: RHEL 5.3 nly has it on i386 and x86_64
17:53:59 <dgilmore> ppc can remain
17:54:02 * nirik sighs at rhel failure on this one. :(
17:54:03 <dgilmore> as can the plugin
17:54:07 <jds2001> right.
17:54:19 <dgilmore> since the plugin is not shipped on rhel
17:54:24 <notting> dgilmore: ppc has no jit. ergo openjdk isn't really useful there
17:54:36 <nirik> perhaps someone in fesco could poke the rhel people to push a rhel update. They have ignored/refused to so far.
17:54:37 <smooge> the issue as I see it is we need a better 'netmask' with RHEL so we can get stuff out sooner
17:54:45 <dgilmore> notting: it still has shark/sero its not as useful but still is
17:54:52 <notting> dgilmore: not in rhel, it doesn't
17:54:55 <nirik> smooge: we need some interface there yes.
17:55:12 * nirik has no idea how to find such an interface.
17:55:48 <jds2001> i thought that was the sort of thing that spot was to facilitate???
17:55:49 <smooge> nirik, me either. I will bring it up if I see any RHEL people soon
17:56:03 <smooge> jds2001, spot is a very very busy person
17:56:28 <jds2001> indeed he is.
17:56:35 <smooge> and I think we haven't pinged him on it lately etc
17:56:38 <notting> ... who is on vacation
17:56:57 <jds2001> spot gets vacation? shocker! :D
17:57:06 <nirik> I think we asked stickster a long time back about finding someone, but no one ever stepped up for it.
17:57:29 <dwmw2> it's not really a vacation. That's just what they call it when he escapes from his cage
17:57:30 <nirik> in this case I guess we just need to find a bad openjdk security bug to get them to update.
17:58:19 <nirik> anyhow, I can try and revive meetings, we can add a trac instance to store tickets? (or should we reuse rel-eng's trac)
17:58:38 * nirik notes the announce and packages-announce mailing lists are ready for bodhi.
17:58:45 <jds2001> i would keep it separate.....
17:58:54 <smooge> nirik there has to be a few.. Sun released 2 or 3 patches ot thier closed version since that branch
17:59:17 <smooge> nirik I think we should get our own trac
17:59:25 <notting> f13: you ok with EPEL stuff in rel-eng's trac instance?
17:59:38 <smooge> I don't want to break f13's workflow
17:59:42 <smooge> oh type slow
17:59:57 * jds2001 makes epel-releng
18:00:00 <f13> I don't mind
18:00:08 <nirik> jds2001: hang on please.
18:00:14 * jds2001 hangs on :)
18:00:19 <f13> as long as we get people to help with doing the tickets
18:00:37 <nirik> f13: if you can add a EPEL component and make me 'kevin' the default assignie? and/or anyone else who steps up
18:00:55 <f13> I could also make an epel list the default assignee
18:01:09 <f13> which would allow the ticket notifications to go to a list and somebody from EPEL could pick it up and run with it
18:01:11 <smooge> f13 oooooh
18:01:17 <f13> (which is how we do it now)
18:01:27 <dgilmore> f13: probably easiest
18:01:30 <nirik> f13: sounds fine to me. That would be epel-devel then.
18:01:46 * nirik is listadmin for that list, so let me know what address to allow to post.
18:01:48 <f13> ok. Can you file a ticket for me to do the admin work? (so as I don't forget it)
18:02:00 <nirik> f13: sure.
18:02:08 * smooge needs to get nirik to give him the password again so he can help cut down the spam work nirik does daily
18:02:30 <nirik> f13: should epel use a different machine for mashes, etc? or would that be something that could exist on existing releng machines?
18:02:43 <dgilmore> nirik: it needs ist own
18:02:45 <f13> that's a good question
18:02:50 <dgilmore> different keys etc
18:02:57 <f13> it probably needs it's own, but we'll still be contending for the same filestore resources
18:03:17 <f13> we actually need to get our staging box up and running to see how bad multiple concurrent composes really hurts things
18:03:26 <nirik> ok, just curious.
18:04:02 <smooge> f13, is that a task for fedora-admin? I am just checking to see who is supposed to help you with that?
18:04:22 <f13> I think the guest is created, releng just has to go poke at it
18:04:26 <f13> josh was doing most the leg work there
18:04:46 <smooge> f13, ok.
18:05:06 <smooge> ok so to summarize EPEL stuff
18:05:16 <smooge> 1) monthly reports are needed
18:05:33 <smooge> 2) trac will be Rel-eng to cover build items
18:06:00 <smooge> 3) need to find a RH contact to deal with crossed over packages
18:06:19 <smooge> 4) weekly meetings need to be done and figured out how to do
18:06:33 <smooge> 5) FESCO will help as needed to get this going again
18:06:47 <smooge> ? overstated missed stuff?
18:07:12 * smooge realizes the 4 cups of coffee and doughnuts has kicked in
18:07:15 * nirik isn't sure what fesco can do off hand, but welcomes any help.
18:07:40 <nirik> .releng 1926
18:07:43 <zodbot> nirik: Ticket #1926 (task created): setup epel to handle rel-eng type stuff || Ticket #1925 (task created): please tag opal-3.6.2-2.fc11 into F11 build override || Ticket #1923 (task closed): Remove package : childsplay_plugins || Ticket #1924 (task created): Buildroot override || Ticket #1923 (task created): Remove package : childsplay_plugins || Ticket #1918 (defect closed): bodhi failed to move (9 more messages)
18:07:51 <nirik> huh. weird.
18:08:16 <jds2001> that shouldnt happen.
18:08:22 <jds2001> oh well
18:08:25 <notting> #agreed 1) monthly EPEL reports are needed
18:08:34 <notting> #agreed 2) trac will be Rel-eng to cover build items
18:08:43 <notting> #agreed 3) need to find a RH contact to deal with crossed over packages
18:09:00 <notting> #agreed 4) weekly meetings need to be done and figured out how to do
18:09:07 <notting> #agreed 5) FESCO will help as needed to get this going again
18:09:24 <jds2001> sounds good to me.
18:09:56 <jds2001> #topic spring ships internal copies of 7Zip and other things
18:10:05 <jds2001> .fesco 165
18:10:09 <zodbot> jds2001: #165 (spring ships internal copy of 7zip and others) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/165
18:10:12 <dgilmore> i created a bug for this
18:10:38 <dgilmore> bug 505636
18:10:39 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=505636 high, low, ---, gauret, NEW, spring contains copies of external libraries
18:10:59 <jds2001> so what should we do?
18:11:10 <nirik> nothing else they request an exception?
18:11:11 <dgilmore> i happened to poke at it today because it was trying to compile as i686 on sparc
18:11:13 <jds2001> just reiterate that external libraries are not allowed in packages?
18:11:38 <dgilmore> jds2001: probably did nt need a fesco ticket. unless he refuses to fix it
18:12:01 <jds2001> no worries. Keep us posted.
18:12:33 <jds2001> #topic fedora-release versioning proposal
18:12:39 <jds2001> .fesco 161
18:12:44 <zodbot> jds2001: #161 (Proposal for fedora-release version-release naming for rawhide) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/161
18:12:56 <nirik> I would like rel-eng input on this one.
18:12:59 * jds2001 wonders what problem we're trying to fix here.
18:13:02 <dgilmore> i honestly dont like it because i feel its confusing
18:13:14 <nirik> I think it makes sense, but is mostly cosmetic
18:13:29 <dgilmore> i think 10.92 is clearer than 11 but that rpm says its 11-0.1
18:13:52 <notting> hm... i don't like it because it would mean new tarballs would all be fedora-release-11.tar.gz
18:14:09 <nirik> true.
18:14:10 <f13> I was just reading this
18:14:17 <f13> notting: wee already have that problem
18:14:18 <nirik> the upstream really is 10.92 or whatever
18:14:21 <dgilmore> its very common for prerelease things to be the old release + .90 .91 etc
18:14:22 <brunowolff> It's not just clarity, but also that the version part changes during the development cycle.
18:14:33 <dgilmore> its much less common to operate as proposed
18:14:37 <f13> notting: the tarball is really effed. as soon as we do 10.92-2 we've re-spun the same tarball anme
18:14:38 <f13> name
18:14:41 <dgilmore> mysql being an exception
18:14:45 <f13> so here is my thought
18:14:49 <nirik> dgilmore: many packages do. the kernel does
18:15:02 <f13> given the FAD proposals, the rawhide fedora-release would be the same and never really changing, i'td just be rawhide.
18:15:21 <dgilmore> nirik: thats a packaging issue not a upstream one though
18:15:25 <nirik> so what version is it then?
18:15:33 <f13> when we branch for a release, then we could do a fedora-release-12-0.1 and fedora-release-12-0.2 until we get to RC and make it fedora-release-12-1
18:15:50 <nirik> fedora-release-20090612gitXXXXXX
18:16:30 <dgilmore> f13: do you understand the problem this is trying to solve?
18:16:32 <nirik> when does a fedora-release-13-0.1 appear?
18:16:37 <dgilmore> f13: if so can you explain it to us
18:16:40 <dwmw2> dgilmore: I don't
18:16:51 <dgilmore> dwmw2: i dont either
18:16:54 <dwmw2> what I _would_ like to solve is the problem of switching to/from rawhide
18:16:58 <f13> nirik: when we branch for F13
18:17:09 <dwmw2> I just had to go edit /etc/yum.repos.d/rpmfusion-free-rawhide.repo to disable it
18:17:11 <f13> dgilmore: mostly I think it's to do with using $releasever variables
18:17:16 <dwmw2> and re-enable the normal rpmfusion-free repo
18:17:23 <dwmw2> having _that_ happen automatically would be nice
18:17:29 <dwmw2> depending on the fedora-release package that's installed
18:17:50 <jds2001> dwmw2: rpmfusion-release could update too, no?
18:17:51 * nirik wonders if this is a fesco item. Shouldn't it be solved by the maintainer of the fedora-release package? :)
18:17:55 <dgilmore> dwmw2: rpmfusion could symlink 11.90 to devel
18:18:18 <dwmw2> dgilmore: fedora-release was set up so that we don't follow rawhide; we stay on 11
18:18:24 * nirik wishes rawhide was a different (sub)package entirely. Then all the people who enable it by mistake wouldn't
18:18:29 <dgilmore> dwmw2: right
18:18:42 <dwmw2> oic, yes -- then they wouldn't have to have the separate rpmfusion-free-rawhide repo config at all.
18:18:48 <dgilmore> dwmw2: i guess i dont understand whyat your getting at
18:19:10 <f13> nirik: was kind of my thought, I didn't notice it was a FESCo proposal until 2 minutes ago
18:19:33 <nirik> so, I see advantages, but I think it's going to have to be carefully thought out.
18:19:43 <jds2001> f13: you wanna table it for later then?
18:20:04 <f13> yeah, I need some time to think about it, particularly in light of the FAD proposals
18:20:10 <dwmw2> dgilmore: it sucks that I have to disable the rpmfusion-free repo and enable rpmfusion-free-rawhide manually, when I switch to rawhide. And then edit them both again when rawhide becomes f11
18:20:50 <jds2001> #agreed fedora-release versioning proposal is tabled until rel-eng can think about it more.
18:21:11 <jds2001> that's all I had, but I do have one more item.
18:21:32 <brunowolff> If the rawhide repos were stored in releases/nn then you wouldn't have to have the rawhide repo files at all.
18:21:33 <jds2001> #topic LVM and provenpackager
18:21:35 * nirik checks jds2001 for synax
18:21:44 <nirik> syntax even
18:21:56 <dgilmore> dwmw2: right with a symlink rpmfusion could avoid that for users
18:22:17 <jds2001> so I've pinged this ticket several times, and gotten no response.
18:22:39 <f13> honestly I don't really think it's FESCo's duty to make the management of secondary repos easier. That's more of the secondary repo's problem.
18:22:40 <jds2001> .fesco 124
18:22:45 <zodbot> jds2001: #124 (Re: Packages with closed ACL's - LVM related items) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/124
18:23:08 <dgilmore> f13: i agree. and i don't think its a hrd thing for them to fix
18:23:13 <dwmw2> f13: no, but it's sane to think about the issue when we're changing things.
18:23:34 <jds2001> so I was going to ping it again, but I wanted some teeth behind it this time.
18:24:09 <dwmw2> nah, just open the damn package
18:24:17 <nirik> how about ask for a response, if nothing by next meeting, packages will be opened.
18:24:20 <jds2001> so I was wondering the posistion on "if you don't respond in 2 weeks, these packages will be opened. The rest of the distro has been for awhile"
18:24:29 <jds2001> nirik: you
18:24:35 <jds2001> are thinking what I was.
18:24:43 * nirik is fine with 2 weeks too.
18:24:45 <dgilmore> jds2001: i think we just open the acls
18:24:54 <jds2001> I just wanted to make sure everyone was cool with that before I unilaterally said/did something.
18:25:24 * bpepple is fine with 2 week chance to respond.
18:25:26 * sharkcz agrees the position
18:25:37 <j-rod> worksforme
18:25:38 * notting is fine with the position. 2 weeks seems a bit long, but ok
18:25:45 <dwmw2> I'd settle for 2 weeks warning. Now would be better.
18:26:08 <dgilmore> i think we just do it now
18:26:13 <jds2001> coo
18:26:20 <dgilmore> i think they have had enough warning already
18:26:46 <jds2001> #agreed jds2001 will ping ticket 124 again, and if no repsonse in 2 weeks, open ACL's.
18:26:55 <jds2001> anything else?
18:27:07 <jds2001> #topic open floor
18:27:07 <j-rod> arch support
18:27:09 <nirik> I have one item
18:27:29 <dgilmore> j-rod: ?
18:27:30 <j-rod> we went i586 for f11, and talked about going i686 in f12
18:27:33 <dgilmore> then nirik
18:27:48 <dgilmore> j-rod: it is what we did agree on when we went i586
18:27:49 <jds2001> #topic arch support for F12
18:28:06 <notting> do we need a feature page? i can write one up for next week
18:28:10 <nirik> does this include the 'x86_64 kernel on 32bit installs/userspace' ?
18:28:18 <j-rod> so if we agreed to go i686 for f12, we should make that change sooner than later
18:28:29 <nirik> yeah, I would think a feature page and asking for comment would be good before making any decisions.
18:28:32 <dgilmore> j-rod: sooner
18:28:54 <nirik> does this end up hurting olpc?
18:29:21 <jds2001> dont think so
18:29:21 <j-rod> aren't they more or less branching from F11?
18:29:37 <nirik> currently yeah.
18:29:41 <jds2001> for now, yeah, but they are going to have more versions :D
18:29:49 <nirik> (one would hope)
18:29:59 <j-rod> and the I *think* the new 1.5 hardware supports full i686
18:30:06 <jds2001> but i thought we went through this
18:30:15 <jds2001> i686 stuff currently runs on the XO, no?
18:30:18 <jds2001> glibc?
18:30:30 <nirik> jds2001: it's i686 without CMOV or something weird.
18:30:41 <notting> j-rod: appears to. sse2, even.
18:30:55 <j-rod> yeah, the 1.5 hardware is a Via C7-M proc
18:31:13 <notting> so, cmov, sse2/sse3, nx etc.
18:31:46 <nirik> so, what do we loose dropping i586? just those lonely pentium users?
18:31:56 <dgilmore> the geode is i686 compataible it meets all the specs
18:32:03 <dgilmore> but it presents itself as a i586
18:32:07 <notting> nirik: pretty much
18:32:11 <nirik> and needs mass rebuild again in f12.
18:32:13 <dgilmore> and some via users
18:32:22 <dgilmore> nirik: doesnt need a mass rebuild
18:32:27 <nirik> (which we might need anyhow if lzma rpm support is needed)
18:32:29 <nirik> oh?
18:32:42 <dgilmore> things would be ok with some i586 bits
18:32:57 <dgilmore> but we could decode that we want i686 for everything
18:34:21 <notting> also, if we do i686, we may do i686+
18:35:12 <j-rod> and i586 and the lesser i686 can be resurrected as a secondary arch
18:35:23 <notting> there are benefits to going to sse2+ -only (which would drop support for pentium pro/2/3, and 32-bit athlon)
18:36:26 <dgilmore> notting: right if we do it now we can give time for people interested to do i586 p2 p3 p pro athlon as a secondary arch
18:37:02 <jds2001> any sort of change that drops platform support would need to be fed to the marketing machine, such that they can prepare the userbase.
18:37:38 <dgilmore> jds2001: it needs to be done now if its going to be done
18:37:49 <jds2001> yep
18:38:02 <notting> ok, i'll do the feature page, start the list flamewar^Wdiscussion, and we can discuss next week
18:38:05 <j-rod> we've already planted the seed, but yeah, we need to do this ASAP...
18:38:08 <j-rod> cool
18:38:29 <j-rod> is it too early for me to register my +1 for next week?
18:38:30 * nirik agrees with notting.
18:38:44 <jds2001> #action notting will make a feature page, start a list discussion, and we can discuss next week.
18:38:46 <dgilmore> from http://fedoraproject.org/wiki/FWN/Issue162
18:38:49 <dgilmore> Last week (FWN#161[1]) we reported on a proposal to cease building Fedora 11 for the i586 CPU instruction set. FESCo had delayed its decision in order to discuss the matter further. The issue was addressed[2] on 2009-02-05 with the outcome that a proposal by Dennis Gilmore to continue supporting i586 for the duration of Fedora 11 but to transition to i686 for Fedora 12 was supported.
18:39:20 <j-rod> jds2001: would be good to include *what about* in that line, I think... if you read just the action-item, its a bit.. vague. :)
18:39:39 <jds2001> oh, i thought that it grouped it under the topic
18:39:42 <jds2001> am i wrong?
18:39:56 <j-rod> I thought there was a bullet list of action items somewhere in the summary
18:40:09 <j-rod> you might be right hto
18:40:10 <j-rod> tho
18:40:11 <jds2001> #action notting will make a feature page, start a list discussion, and we can discuss next week about arch support for F12.
18:40:18 <jds2001> either way, we
18:40:24 <jds2001> 're covered now :D
18:40:46 <jds2001> nirik: you had something else?
18:40:49 <nirik> oh yeah.
18:41:07 <dgilmore> jds2001: we already voted to do it
18:41:22 <nirik> dgilmore: you said you had some corrections to mmcgrath's threat assessment? could you make those/talk with him about them and we can release it?
18:41:25 <dgilmore> i think it needs a featurepage to documents
18:41:38 <dgilmore> nirik: ok
18:41:49 <jds2001> well, yeah - we need to talk about the feature page :)
18:42:05 <jds2001> even if it's just nine +1's :)
18:42:54 <dgilmore> http://bpepple.fedorapeople.org/fesco/FESCo-2009-02-05.html * dgilmore again proposes that we do .i586 for F-11 i686 for F-12 and transition, giving time for those wanting i586 to get it happening
18:44:07 * nirik is fine with just doing it since we approved it... but a feature page is still a very good idea.
18:44:15 <nirik> along with a heads up about it.
18:44:33 <dgilmore> nirik: we need it documented and advertised
18:44:36 <j-rod> well, we did say "we'll go to i686", but I don't think we definitively decided what "i686" meant exactly
18:44:39 <jds2001> #action dgilmore will make corrections to the threat assessment provided by mmcgrath and we will publish the assessment.
18:44:42 <notting> yeah, i think what was voted was "<dgilmore> for F-12 we will be i686. what variant of i686 yet to be decided"
18:44:51 <j-rod> i.e., is it just i686 or is it i686+ as notting described
18:45:11 <dgilmore> notting: right. what level of i686 needs to be determined.
18:45:26 <jds2001> so let's determine that next week :)
18:45:39 <j-rod> bingo
18:45:46 <jds2001> anything else?
18:46:35 * jds2001 ends the meeting in 30
18:46:45 <nirik> f13: can you report on that java branch exception thing we added a while back? do they have all their packages in now? how's it going?
18:47:04 <f13> I... dont' know.
18:47:19 <f13> I created private branches for a large number of packages, but I don't know how far along they are
18:47:34 <f13> let me look at the tag real quick
18:47:59 * nirik doesn't want that to just sit idle... needs to get done and closed out. :)
18:48:40 <jds2001> i only see 10 packages in that tag
18:48:53 <f13> koji being slow, bear with me
18:48:59 <jds2001> f13: about what is a "large" number?
18:49:09 <f13> I branched more than 10 packages IIRC
18:49:46 * nirik did cvs for them, but it's lost in the sea of other ones, so not sure where it stands.
18:50:58 <jds2001> so let's ask the java folks how things are going
18:51:13 <jds2001> #action ask java folks how the maven rebuilds are progressing
18:51:37 <jds2001> anything else?
18:51:43 <f13> yeah so it looks like they have only done 10 builds into that collection.
18:51:56 <f13> sorry I was going about it the wrong way to get that info, jds2001 had it earlier
18:52:32 * jds2001 ends the meeting in 30
18:53:06 <jds2001> #endmeeting