| --- jds2001 has changed the topic to: FESCo meeting -- init | ||
| jds2001 | FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod | |
|---|---|---|
| * bpepple is here. | ||
| * notting is here | ||
| sharkcz is here | ||
| jwb is here | ||
| jwb | dgilmore-oz is in OZ. probably sleeping | |
| jds2001 | yeah | |
| j-rod wasnt going to be here either | ||
| * nirik is here. | ||
| jds2001 | so lets get started, we only have two items this week. We'll save the PPC discussion for next week. | |
| --- jds2001 has changed the topic to: FESCo meeting - agenda at https://fedorahosted.org/fesco/report/9 - Tickets | ||
| jds2001 | .fesco 143 | |
| zodbot | jds2001: #143 (F12 schedule) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/143 | |
| * nirik follows the links | ||
| notting | the releng group, at the monday meeting, approved a modified version of http://poelstra.fedorapeople.org/schedules/f-12/f-12-summary-tasks.html | |
| jds2001 | notting: we're eliminating alpha this time around? | |
| notting | that's the proposal | |
| jwb | jds2001, if time allows, ppc discussion might be ok | |
| notting | i do not have a task-jugglier-ified version of what was approved | |
| jds2001 | well what changes were made to this? | |
| the ones mentioned in the ticket? | ||
| notting | yes | |
| f13 | sorry I'm here now | |
| jds2001 | np | |
| * nirik has no objections if this is what rel-eng wants to go with. It seems like it's kinda trial and error as to what works best. | ||
| f13 | The proposal is to remove the alpha chunk. | |
| jds2001 | so we eliminated alpha? | |
| yeah, not a problem here either. | ||
| f13 | We'd leave room for QA to schedule more test days, and releng will help with getting things into a useful state for the test days | |
| * bpepple has no objections to removing the alpha. | ||
| jwb | it's pretty pointless | |
| sharkcz | no objections also here | |
| jds2001 | +1 | |
| bpepple | +1 to rel-eng schedule proposal. | |
| nirik | +1 | |
| sharkcz | +1 | |
| jwb | +1 | |
| notting | +1 | |
| jds2001 | j-rod was +1 on the mailing list. | |
| jds2001 | and F12 will be a nice birthday present for him :D | |
| nirik | I still wish we could release on halloween some year. ;) oh well. | |
| f13 | if it ever falls on a Tuesday... | |
| bpepple | nirik: yeah, I like the Halloween themed releases also. | |
| notting | http://notting.fedorapeople.org/f-12-summary-tasks.html is a modifed version of the taskjuggler export with the changes added. 'duration' dates are incorrect. | |
| jds2001 | anyhow, I see 7 +1's, so we've approved releng's F12 schedule. | |
| jds2001 | .fesco 64 | |
| zodbot | jds2001: #64 (liblvm - https://fedoraproject.org/wiki/Features/liblvm) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/64 | |
| jds2001 | deepthot21: you around? | |
| deepthot21 | yes - I'm here | |
| I did a little updating of the project pages | ||
| nirik | deepthot21: I had some questions on the discussion page there: https://fedoraproject.org/wiki/Talk:Features/liblvm | |
| deepthot21 | we are still moving towards F12 as the first release of liblvm | |
| ok - let me look | ||
| deepthot21 | ok, regarding anaconda | |
| deepthot21 | the intent is for anaconda to use liblvm, so yes, there will be changes required, and I am working with some of the anaconda team in this regard | |
| this is part of the anaconda storage rewrite | ||
| jds2001 | and that's change beyond what they've already done for the storage rewrite? | |
| deepthot21 | yes, we were not ready with what they needed | |
| it will be up to the anaconda team to decide | ||
| deepthot21 | when we get them something they can use | |
| notting | jds2001: (maybe excessively simplified) the storage rewrite consisted of rewriting it so that the lvm, md, and other backends could be swapped out. this would involve swapping out the one that calls "lvm ..." to call liblvm | |
| jds2001 | notting: ahhh | |
| nirik | deepthot21: is anything else planned to use it soon aside from anaconda? | |
| deepthot21 | not that I am aware of, though there has been requests for liblvm from a few different sources (lists, partners, etc) | |
| if we build it, they will come | ||
| s/if/when | ||
| bpepple | deepthot21: ;) | |
| notting | ease the user's pain? | |
| nirik | yeah, it sure seems like a good idea. ;) | |
| deepthot21 | regarding the other question, advertising of the feature to fedora users | |
| I am not sure of the precedent | ||
| * nirik looks over the feature definition page. https://fedoraproject.org/wiki/Features/Policy/Definitions | ||
| deepthot21 | does fedora typically advertise libraries? | |
| bpepple | deepthot21: not normally. | |
| deepthot21 | if they are new and could lead to new application development for a core subsystem? | |
| nirik | deepthot21: so the advertisement is more for developers of projects... so we get people noticing it and porting their project to use it? | |
| poelcat | #3 seems to apply though | |
| bpepple | poelcat: yeah, I'm inclined to agree that this is something worth advertising. | |
| jds2001 | especially since it's brand new and we have it first. | |
| * sharkcz agrees | ||
| bpepple | anyone have any other questions for deepthot21? | |
| nirik | so this work is being merged with lvm2 upstream ? | |
| deepthot21 | nirik: yes | |
| nirik | cool. | |
| bpepple | +1 to liblvm feature. | |
| jds2001 | +1 | |
| sharkcz | +1 | |
| pjones | definitely something worth advertising. | |
| notting | +1 | |
| nirik | +1 I suppose | |
| jds2001 | thank you for tkaing the time to answer our quesitons deepthot21. | |
| sorry this kept getting deferred forever :( | ||
| deepthot21 | np! | |
| jds2001 | but I see five +1's, so we've approved the liblvm feature. | |
| deepthot21 | cool, thanks | |
| jds2001 | and barring any burning desire to discuss PPC (which wasn't on the agenda), that's all I have for today. | |
| abadger1999 | I've got two and a half issues. | |
| nirik | how about 116? | |
| abadger1999 | .fesco 116 | |
| zodbot | abadger1999: #116 (figure out what to do about deactivated maintainers) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/116 | |
| * nirik nods. | ||
| notting | no fpc report? | |
| jds2001 | abadger1999: the message was sent out. | |
| abadger1999 | notting: Not this week. | |
| jds2001 | i didnt see one. | |
| jds2001 | abadger1999: at this point, I think we've given *much* more time than we said we would. | |
| nirik | abadger1999: can you update the ticket with the current list when you get a chance? and are we waiting another week? or orphaning now? | |
| jds2001 | some of that is my failing. | |
| f13 | if there is an open floor I have a topic to discuss | |
| jds2001 | f13: there is. | |
| lets' finish abadger1999's topic which shouldnt take long. | ||
| f13 | nod | |
| jds2001 | so what do folks think? | |
| --- jds2001 has changed the topic to: FESCo meeting -- Open Floor | ||
| abadger1999 | So are we on the orphaning now step? | |
| jds2001 | yeah | |
| nirik | I am ok with going to orphaning. | |
| jwb | yes | |
| * bpepple has no objections. | ||
| abadger1999 | Okay. I'll go ahead with that. | |
| nirik | to be clear: we are just removing all inactive maintainer accounts from pkgdb, not removing them from groups or anything (in case they reactivate and come back later)? | |
| abadger1999 | nirik: I can add a list of the packages/owners that were orphaned when I do that. | |
| nirik: Correct. | ||
| * nirik nods. | ||
| abadger1999 | This is just a pkgdb step. If they come back later, they won't have ownership in any package. | |
| abadger1999 | but they currently will have packager group, etc. | |
| nirik | right. | |
| jds2001 | that's fine with me, they'll just have to apply for co-maintainership or whatever. | |
| convince current owner to orphan, etc. | ||
| abadger1999 | Cool. Let f13 have the floor and then there's one other fesco ticket I'll bring up. | |
| f13 | alright. | |
| the Java folks approached me today about something they're planning for F12 | ||
| a major upgrade to Maven, which is their base buildsystem for a very large percent of their packages. | ||
| The migration process will be lengthy, and it will bring in 10 or so new packages | ||
| f13 | what they need from us is a few things, most easily done. | |
| 1) a tag in koji to work within without disrupting rawhide, so dist-f12-maven. We've done this before, no big deal. | ||
| 2) They want to have a branch in CVS to work in, as to not disrupt the devel -> dist-f12 builds that may happen while the migration is being worked on. | ||
| jwb | they can create that themselves | |
| f13 | I do believe they can use a real CVS branch (and not a named directory) to accomplish this, to the point where even "make build" would dtrt from within the branch. | |
| jwb | f13, yes. the f9 kernel is currently doing that | |
| f13 | I'm going to test a few things but I expect that will also be easy for them | |
| f13 | the last item is the the hard one, and the one that needs FESCo attention | |
| f13 | the new packages are in a rough kind of shape, and they need to start attempting conversions before they can get the packages to a state where they'd want to review them for Fedora inclusion | |
| f13 | so they're asking for approval to import into CVS and build into dist-f12-maven these new packages, and delay the review until after they've fixed all the issues discovered while developing them | |
| they would have to be reviewed before allowed to build/tag in dist-f12 proper | ||
| and we could even cvs branch those, having no content in the unbranched devel/ directory of these new pakages. | ||
| packages. | ||
| jwb | conceptually, that is no different than them doing scratch builds | |
| f13 | Basically they want to be able to use koji to facilitate the fine tuning of these packages before review, and use cvs to track the changes. | |
| nirik | except they need build deps probibly. | |
| notting | 'rough' would be in the eye of the beholder. what's so rough that they couldn't be reviewed? | |
| f13 | notting: I asked that and offered to just do the 10 reviews myself, but fnasser said that the packages shouldn't be approved in their current state | |
| jwb | wow | |
| f13 | and they don't want to focus on teh packaging until they have the other stuff right | |
| * nirik can see this causing confusion... people seeing commits and builds of things that don't meet guidelines... | ||
| abadger1999 | so they're asking for a java-team-only ability to have a pre-review cvs repo (which has been debated before in generic form)? | |
| notting | how bad could they be? | |
| f13: i don't suppose he mentioned anything about turning off gcj aot compilation? | ||
| jwb | notting, is that what ppc requires? | |
| * jwb doesn't know what 'aot' is | ||
| f13 | notting: no he didn't mention that. | |
| jds2001 | abadger1999: will that sorta exists now in terms of people1. just git. | |
| notting | jwb: depends on how sharkified ppc is | |
| abadger1999 | ahead of time compilation | |
| f13 | notting: I honestly don't know how bad they are, I just got poked about this today. | |
| abadger1999: yeah, it's a one-time shot for these 10 packages. I know that we're not in a good position to do this distro wide | ||
| jds2001 | but obviously stuff in fpeople isnt used in builds or anything | |
| abadger1999 | jds2001: fedorapeople has different expectations from cvs.fedoraproject.org though. | |
| jds2001 | abadger1999: true | |
| f13 | the big deal here is that they need these packages in the buildroots | |
| abadger1999 | f13: I'm just wondering about the issues that people raised in the generic case... like legal review before it goes into cvs. | |
| f13 | and that's harder to do wide scale unless you have a "random crapbag" buildroot that has all sorts of in development junk in it. | |
| jds2001 | the issues is today it's the java team. | |
| tomorrow it's the ruby team, and hte next day the python folks come up. | ||
| f13 | it's easier resource wise to do this for one specific buildroot | |
| abadger1999 | Which with java jars including other upstreams is always fun. | |
| f13 | abadger1999: we can ask that a partial review is started for each of them | |
| at least for things like legal | ||
| abadger1999 | f13: That could be reasonable from my standpoint. | |
| notting | yeah, the legal bits, the build from source/no binaries bits, etc. all need handled before it can be imported & built | |
| f13 | jds2001: quite honestly, I wouldn't have a problem with doing targeted things for python/ruby/etc. if it's really needed | |
| nirik | f13: so this is 10 or so new packages? couldn't they concentrate on them and get them reviewed before moving forward with the rest of the rebuilds? | |
| f13 | jds2001: we have the resources to do it on small scale, we should be trying to help. | |
| <fnasser_> jkeating, You should not be approving any of them in their initial state ;-) | ||
| jkeating, We have some volunteers to do the cleaning up after the bootstrap is complete, things can be rebuild etc. Doing it at an earlier stage will just make this (which is already a PITA) more miserable | ||
| oops | ||
| jds2001 | f13: if you're comfortable with it, I am. | |
| f13 | that first line to jds2001 was from fnasser. | |
| or not, n/m. | ||
| f13 | notting: a partial review I think is more than reasonable. | |
| bpepple | f13: If it passes a partial review for legal bit, no binaries, etc. I'm fine with it. | |
| * sharkcz nods | ||
| bpepple | We should track them though, so they do get a final review before F12, though. | |
| * nirik guesses so. we should be clear what packages these are... perhaps a tracker bug with the started review approved for initial cut, and then can be continued when ready from there. | ||
| f13 | ok, Proposal: Java Maven team is granted the ability to pre-import in-development packages for the sake of using them in buildroots to complete maven update. Packages will pass partial review for legal/no-binaries before being imported, and pass full review before being allowed into dist-f12. | |
| jds2001 | +1 to f13's proposal | |
| sharkcz | +1 | |
| f13 | review bugs will be filed for all, and tracked. This may actually be an F12 feature which will help tracking. | |
| abadger1999 | Can we have a full list of what's needed for partial review after running it by the packaging committee? | |
| f13 | sure | |
| bpepple | +1 to f13 proposal. | |
| notting | +1 | |
| * abadger1999 puts it on the agenda for Tuesday. | ||
| nirik | +1 | |
| jds2001 | i see five +1's, so we've approved f13's propsal. | |
| f13 | rock, thanks guys. I'll talk with fnasser about it and let him know to perhaps attend the package committee meeting | |
| jwb | +1 | |
| 6 now | ||
| jds2001, i was wondering if we could get a quick strawman on ppc | ||
| jds2001 | i'd like to wrap up this meeting in the next 15 min if possible, | |
| jwb | i just want initial reactions to the topics | |
| jds2001 | I have a $DAYJOB meeting i'd like to attend, but I told them I might not be able to. | |
| jwb | er, topc | |
| nirik | abadger1999: you had another item? | |
| abadger1999 | .fesco 116 | |
| zodbot | abadger1999: #116 (figure out what to do about deactivated maintainers) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/116 | |
| jds2001 | didnt we already decide that? | |
| jwb | abadger1999, didn't we just talk about that? | |
| * nirik has a sense of deja-vu | ||
| abadger1999 | oops. | |
| abadger1999 | .fesco 108 | |
| zodbot | abadger1999: #108 (Would be good if there was an acl for "let all packagers edit this package" in pkgdb) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/108 | |
| jds2001 | oh, that one..... | |
| abadger1999 | mmcgrath sent the threat assessment so this is back on the plate for discussion. | |
| notting | abadger1999: are we using fs acls? | |
| w/o that, i don't see how it's feasible to implement | ||
| abadger1999 | Not at the moment. | |
| Just standard unix permissions. | ||
| jds2001 | notting wanted to correct the assessment that mmcgrath sent iirc. | |
| abadger1999 | And the cvs acl thing. | |
| notting | don't think so | |
| nirik | jds2001: you mean dgilmore-oz | |
| jds2001 | ahh | |
| i had a bit-flip in my brain i guess :) | ||
| nirik | I think this is worth considering/discussing as part of a revamp of the permssions system... | |
| I'm reluctant to just try and add this to the existing system. | ||
| f13 | hey we could pin this on "the next SCM" to try and drive more interest that way | |
| jwb | permissions system? | |
| f13, was thinking the same | ||
| nirik | well, packagedb/acls/etc. | |
| also, I think if ricky's fix for the cvs commit issue is good, that makes it more attractive to me to open permissions more. | ||
| abadger1999 | f13: or kill it... one or the other ;-) | |
| notting | f13: the next scm is git. the debate is what we put in it :) | |
| jwb | sigh | |
| nirik | I really don't care what the next scm is. As long as it's faster than cvs and all the normal standard maintainer things are easy to do. | |
| jwb | i think this is more than a 15min discussion | |
| * nirik nods. | ||
| abadger1999 | So... what I'm wondering firstly is whether this is desirable if it can be done in a safe manner. | |
| * jds2001 is happy to try and multitask. | ||
| abadger1999 | If so we can debate doing it via SCM, fs acls, etc. But if it's not desirable then that's unnecessary work. | |
| jwb | abadger1999, if it's opt-in, possibly | |
| jds2001 | but my attentiveness here may go down the tubes quickly :) | |
| nirik | I think if the cvs commit thing is fixed I would be willing to explore this. | |
| jwb | nirik, refresh my memory? | |
| notting | abadger1999: if a packager really really really wants to do that, i don't think it's *bad*. not sure it accomplishes much either | |
| jwb | the ctrl-c problem? | |
| abadger1999 | jwb: Separate, explicit checkbox, so opt-in would be there. | |
| nirik | jwb: yes. | |
| jwb | nirik, ah. k | |
| nirik | jwb: so, commit mail never sent. | |
| abadger1999 | notting: I think the primary use case was desktop team packages. | |
| jwb | nirik, i'm starting to be less and less concerned about that | |
| abadger1999 | They have hundreds of packages and not everyone on their team is in provenpackager | |
| nirik | jwb: how so? because builds will email? | |
| jwb | nirik, mostly, yes. don't get me wrong, it's still a concern | |
| * j-rod just got back in... meeting still going? | ||
| jwb | j-rod, yep | |
| jds2001 | yeah | |
| nirik | sure, but once it's built it could go into the buildroot pretty quickly... and to rawhide also pretty quickly. | |
| jwb | nirik, having the cvs email sent out doesn't really decrease that windo | |
| w | ||
| jds2001 | well once it's committed it's normally built immediately, no? | |
| * jds2001 normally does things that way. | ||
| jwb | nirik, because it still depends on someone actually reading it and then doing something before they submit the build | |
| nirik | yeah, I suppose. I guess a rouge commit would be noticed in a new checkin from the maintainer. | |
| jwb | all i'm saying is that email notification is not a substitute for maintainer diligence | |
| nirik | true. | |
| * nirik also doesn't think this is a short topic | ||
| jwb | abadger1999, good enough for now? | |
| or is there something specific you wanted today? | ||
| abadger1999 | Nope, just wanted it to get back on the radar/people to think about it. | |
| jwb | yeah, good idea. thanks | |
| * j-rod finishes reading over the scrollback... | ||
| jwb | so are people opposed to a brief, no-discussion ppc strawman? | |
| bpepple | jwb: I fine with talking about it. | |
| jwb | i'm trying to gauge how long we're going to talk about it next week :) | |
| notting | no discussion? :) | |
| jwb | well, discussion if we want | |
| notting | my opinion is that development has already begun on f12. ergo, -1 to ppc-as-seconday-for-f12, +1 to ppc-as-secondary-for-f13 | |
| jwb | ok, go with nottings format | |
| * nirik nods and agrees with notting. Thats what I was going to say. | ||
| nirik | this would allow time for ppc folks to line up resources, start getting things setup, etc. | |
| jwb | bpepple, sharkcz, jds2001, ? | |
| * jds2001 agrees with notting | ||
| sharkcz | +1 to notting's proposal | |
| * j-rod agrees w/notting and nirik | ||
| bpepple | I'm fine with notting's proposal. | |
| j-rod | although, damn, I missed the entire discussion where anyone said anything about making ppc secondary | |
| jwb | ok, seems pretty unanimous | |
| * j-rod has had head buried in crypto code the better part of the past few weeks... | ||
| jwb | j-rod, happened at the board meeting | |
| jwb | j-rod, they gave the actual decision to FESCo | |
| mmcgrath | notting: FYI on fs acls, we do have them enabled and in use on the cvs box, but not really as part of the normal cvs workflow for anything. | |
| j-rod | aha | |
| jwb | jds2001, thanks. i think the discussion will likely be brief next week. just hammering out some more fine-grained details | |
| notting | are we taking this as a Real Vote(tm) with more details later? or will we do the official vote next week? | |
| jwb | maybe anyway | |
| notting, there are noted missing people today that probably have input... | ||
| namely, dwmw2 | ||
| possibly dgilmore | ||
| * jds2001 would do the official vote next week. | ||
| bpepple | yeah, jeremy and some other folks probably would want to weigh-in. | |
| jwb | jds2001, agreed | |
| * dwmw2 is missing | ||
| dwmw2 stops that | ||
| jwb | dwmw2, we were doing a strawman on ppc | |
| dwmw2 | sorry, missed the call | |
| jwb | so far it's: | |
| -1 to ppc-as-seconday-for-f12, +1 to ppc-as-secondary-for-f13 | ||
| dwmw2 | my concern here is that one the one hand we seem to have rel-eng folks (quite reasonably, I suppose) saying that they don't want to do the work for supporting ppc. | |
| and on the other hand we seem to have all the secondary arch stuff waiting on rel-eng/koji work. | ||
| so it's "sod off, and no we're not going to help you make it work" | ||
| mbonnet | dwmw2: we do? | |
| f13 | dwmw2: different people. | |
| dwmw2 | but if we can get the koji stuff _working_, I'm content with secondary-for-f12 even. | |
| jds2001 | $DAYJOB call over already. | |
| dwmw2 | f13: that's only apparent from the inside :) | |
| mbonnet | dwmw2: what part of the koji stuff is not working? | |
| spot | mbonnet: i have it written up, sent it to johnf, can send to you | |
| dwmw2 | mbonnet: others can answer that better than I. Something about notification of package builds? | |
| jwb | mbonnet, i believe the notification of primary build completion to secondary hubs, and the notification of secondary build completion to primary hub | |
| spot has the details, yes | ||
| dwmw2 | would be nice to have a quick rundown from someone more clueful about what the current barriers are to secondary arches actually releasing. | |
| mbonnet | jwb: none of that stuff is *necessary* for secondary arches | |
| dwmw2 | and maybe even a timescale for having them fixed. | |
| jwb | mbonnet, the board agrees with you | |
| mbonnet | all of those are "nice-to-haves" that would actually be better handled outside of koji | |
| dwmw2 | what's the secondary arch in best shape right now? sparc? | |
| jwb | believe so | |
| nirik | so another question: if ppc goes to secondary in f13 say... does that mean we keep all the current infrastructure until f14+1month so we can keep doing builds for existing releases? | |
| dwmw2 | why don't we have an actual release of F-10 for sparc, or beta of F-11? | |
| jwb | nirik, i have a question to the board about using existing infrastructure for a secondary effort | |
| notting | nirik: yeah, we can't shut off updates for existing releases | |
| dwmw2 | nirik: I think so, yes -- hopefully we can use the same builders to do both at once? | |
| jwb | nirik, that becomes a lesser question if the board and RH approves it | |
| jds2001 | dwmw2: i asked specifically about the builders/compose boxen | |
| jwb | nirik, but it's a good question | |
| jds2001 | they're in our bladecenter right now, so im fine with leaving them there so long as there's some plan to get their own hardware at some point. | |
| nirik | I guess secondaries will need their own bodhi too? | |
| dwmw2 | jds2001: it's partly a technical issue -- can the same box do 'primary' builds for F11 updates at the same time as 'secondary' builds for F13? | |
| jwb | dwmw2, i believe so | |
| jds2001 | dwmw2: not sure if one box cna talk to two hubs, no | |
| mbonnet: ^^ ? | ||
| dwmw2 | It would be good to have a clear summary of what needs doing to get a secondary arch to release. | |
| mbonnet | jds2001: no, that's not possible | |
| notting | dwmw2: 'do builds ; spin isos and trees'. simplified, but more or less correct | |
| jwb | mbonnet, not even if it's the same hub? | |
| nirik | dwmw2: and/or more communication in general... monthly/bi monthly reports to fesco from teams as to whats going on? | |
| jwb | mbonnet, meaning for f11, ppc is primary on the main hub, but for f12(or 13) it's secondary | |
| mbonnet | jwb: one box usually contains one kojid which talks to one kojihub | |
| dwmw2 | notting: if it's that simple, how come we don't have a sparc release? | |
| notting | dwmw2: the unstated 'fix the bugs that are platform specific' that might be messier? i dunno. | |
| jwb | mbonnet, yes. i'm asking if a distinction on 'primaryness' can be made | |
| f13 | dwmw2: because 2 people work on sparc? | |
| mbonnet | jwb: if it's talking to the main hub, then it's not secondary | |
| pjones | dwmw2: total hours spent on it is very, very small. | |
| f13: and they don't do so all that much. | ||
| dwmw2 | so they _could_ have released? | |
| f13 | right. | |
| one of which is the same person who's working on the koji code | ||
| dwmw2 | I'm perfectly happy if the ppc build ends up depending on people who care | |
| as long as there isn't infrastructure bottleneck that the people who really care _can't_ deal with | ||
| jwb | mbonnet, hm. ok | |
| pjones | dwmw2: that's pretty much the rub, yeah -- not enough people care enough to devote the man-hours required into getting a release out the door. | |
| jwb | jds2001, so a transition of some builders might be needed. not a huge deal | |
| dwmw2 | pjones: if that's all, that's fine. | |
| I think we should get ppc up and running as a secondary architecture ASAP. That can be done in parallel, while it's still a primary architecture | ||
| jwb | dwmw2, we being who | |
| dwmw2 | and then we can see if we're in good shape to switch off the primary. | |
| jwb: those who care about ppc :) | ||
| jwb | sure. agreed. now we just need those people to step up | |
| the motivation needs to be there | ||
| so | ||
| after our discussion :) | ||
| does anyone want to change their strawman opinion? | ||
| * nirik does not | ||
| jwb | nothing said has changed my opinion (which i conveniently didn't state) | |
| dwmw2 | we're planning to decide this properly next week, right? | |
| jwb | dwmw2, yes | |
| bpepple | dwmw2: yup. | |
| f13 | or the week after... | |
| dwmw2 | can we ask for a report from the existing secondary architectures, summarising the reasons they haven't released yet? | |
| jwb | f13, no, next week | |
| f13 | dwmw2: you can do whatever you want (: | |
| jwb | dwmw2, likely, yes. arm just sent a report this week | |
| mdomsch | while I'm not on FESCo, I have a mirror-related selfish reason to want to move ppc to secondary | |
| jwb | mdomsch, which is what? | |
| jds2001 | mdomsch: :) | |
| mdomsch | right now ppc takes roughly 30% of the disk space for a given release | |
| jds2001 | master mirror space | |
| mdomsch | and is carried by 130 of 187 mirrors | |
| but is used by <2% of our user base | ||
| jwb | mirrors can choose what they mirror, correct? | |
| dwmw2 | and the best mirrors would be carrying secondary architectures anyway, surely? | |
| mdomsch | jwb, sure, each mirror can exclude from their side, but the masters can't exclude from their side | |
| yes, we have ~10 mirrors carrying secondary architectures | ||
| dwmw2 | don't the masters carry the secondary architectures, then? | |
| mdomsch | http://mirrors.fedoraproject.org/publiclist/Fedora/development/sparc/ | |
| shows 7 | ||
| 6 of which are gigabit or faster | ||
| jwb | mdomsch, so you want to move the space off the masters | |
| mdomsch | jwb, yes | |
| jwb | ok | |
| mdomsch | dwmw2, no, the masters don't carry secondary content | |
| dwmw2, that's all served from secondary1 | ||
| dwmw2 | ok | |
| mdomsch | that's all thanks | |
| jwb | mdomsch, so i have a question for you | |
| aside from free disk space, what do you gain? | ||
| mdomsch | jwb, reduction in sync times and bandwidth used to do the sync | |
| jwb | confused | |
| mdomsch | the masters are overloaded, often rejecting syncs | |
| as it is | ||
| jwb | when you say 'masters' do you mean the tier1 mirrors? | |
| mdomsch | if I could reduce their load by 30% by not carrying that content, that would help | |
| no, I mean download[12345].f.r.c | ||
| jwb | ah, ok | |
| thanks | ||
| mdomsch | (as if there are actually that many...) | |
| jwb | right, understand now | |
| mdomsch | and yes, we're going to hit a disk space limit in the not too distant future | |
| as we try to keep under 1TB what's on the masters | ||
| jwb | ok | |
| i don't have anything else | ||
| jds2001 | anyone else? | |
| notting | who's on the hook for the summary? | |
| * bpepple listens to the crickets. | ||
| * jds2001 will get to it tonight or tomorrow. | ||
| jds2001 ends the meeting in 30 | ||
| jds2001 | == MEETING END == | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!