--- jds2001 has changed the topic to: FESCo meeting -- init
jds2001FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod
* bpepple is here.
* notting is here
sharkcz is here
jwb is here
jwbdgilmore-oz is in OZ.  probably sleeping
j-rod wasnt going to be here either
* nirik is here.
jds2001so 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
zodbotjds2001: #143 (F12 schedule) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/143
* nirik follows the links
nottingthe releng group, at the monday meeting, approved a modified version of http://poelstra.fedorapeople.org/schedules/f-12/f-12-summary-tasks.html
jds2001notting: we're eliminating alpha this time around?
nottingthat's the proposal
jwbjds2001, if time allows, ppc discussion might be ok
nottingi do not have a task-jugglier-ified version of what was approved
jds2001well what changes were made to this?
the ones mentioned in the ticket?
f13sorry I'm here now
* 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.
f13The proposal is to remove the alpha chunk.
jds2001so we eliminated alpha?
yeah, not a problem here either.
f13We'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.
jwbit's pretty pointless
sharkczno objections also here
bpepple+1 to rel-eng schedule proposal.
jds2001j-rod was +1 on the mailing list.
jds2001and F12 will be a nice birthday present for him :D
nirikI still wish we could release on halloween some year. ;) oh well.
f13if it ever falls on a Tuesday...
bpepplenirik: yeah, I like the Halloween themed releases also.
nottinghttp://notting.fedorapeople.org/f-12-summary-tasks.html is a modifed version of the taskjuggler export with the changes added. 'duration' dates are incorrect.
jds2001anyhow, I see 7 +1's, so we've approved releng's F12 schedule.
jds2001.fesco 64
zodbotjds2001: #64 (liblvm - https://fedoraproject.org/wiki/Features/liblvm) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/64
jds2001deepthot21: you around?
deepthot21yes - I'm here
I did a little updating of the project pages
nirikdeepthot21: I had some questions on the discussion page there: https://fedoraproject.org/wiki/Talk:Features/liblvm
deepthot21we are still moving towards F12 as the first release of liblvm
ok - let me look
deepthot21ok, regarding anaconda
deepthot21the 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
jds2001and that's change beyond what they've already done for the storage rewrite?
deepthot21yes, we were not ready with what they needed
it will be up to the anaconda team to decide
deepthot21when we get them something they can use
nottingjds2001: (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
jds2001notting: ahhh
nirikdeepthot21: is anything else planned to use it soon aside from anaconda?
deepthot21not 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
bpeppledeepthot21: ;)
nottingease the user's pain?
nirikyeah, it sure seems like a good idea. ;)
deepthot21regarding 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
deepthot21does fedora typically advertise libraries?
bpeppledeepthot21: not normally.
deepthot21if they are new and could lead to new application development for a core subsystem?
nirikdeepthot21: 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
bpepplepoelcat: yeah, I'm inclined to agree that this is something worth advertising.
jds2001especially since it's brand new and we have it first.
* sharkcz agrees
bpeppleanyone have any other questions for deepthot21?
nirikso this work is being merged with lvm2 upstream ?
deepthot21nirik: yes
bpepple+1 to liblvm feature.
pjonesdefinitely something worth advertising.
nirik+1 I suppose
jds2001thank you for tkaing the time to answer our quesitons deepthot21.
sorry this kept getting deferred forever :(
jds2001but I see five +1's, so we've approved the liblvm feature.
deepthot21cool, thanks
jds2001and barring any burning desire to discuss PPC (which wasn't on the agenda), that's all I have for today.
abadger1999I've got two and a half issues.
nirikhow about 116?
abadger1999.fesco 116
zodbotabadger1999: #116 (figure out what to do about deactivated maintainers) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/116
* nirik nods.
nottingno fpc report?
jds2001abadger1999: the message was sent out.
abadger1999notting: Not this week.
jds2001i didnt see one.
jds2001abadger1999: at this point, I think we've given *much* more time than we said we would.
nirikabadger1999: can you update the ticket with the current list when you get a chance? and are we waiting another week? or orphaning now?
jds2001some of that is my failing.
f13if there is an open floor I have a topic to discuss
jds2001f13: there is.
lets' finish abadger1999's topic which shouldnt take long.
jds2001so what do folks think?
--- jds2001 has changed the topic to: FESCo meeting -- Open Floor
abadger1999So are we on the orphaning now step?
nirikI am ok with going to orphaning.
* bpepple has no objections.
abadger1999Okay.  I'll go ahead with that.
nirikto 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)?
abadger1999nirik: I can add a list of the packages/owners that were orphaned when I do that.
nirik: Correct.
* nirik nods.
abadger1999This is just a pkgdb step.  If they come back later, they won't have ownership in any package.
abadger1999but they currently will have packager group, etc.
jds2001that's fine with me, they'll just have to apply for co-maintainership or whatever.
convince current owner to orphan, etc.
abadger1999Cool. Let f13 have the floor and then there's one other fesco ticket I'll bring up.
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
f13what 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.
jwbthey can create that themselves
f13I 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.
jwbf13, yes.  the f9 kernel is currently doing that
f13I'm going to test a few things but I expect that will also be easy for them
f13the last item is the the hard one, and the one that needs FESCo attention
f13the 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
f13so 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.
jwbconceptually, that is no different than them doing scratch builds
f13Basically 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.
nirikexcept 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?
f13notting: 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
f13and 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...
abadger1999so they're asking for a java-team-only ability to have a pre-review cvs repo (which has been debated before in generic form)?
nottinghow bad could they be?
f13: i don't suppose he mentioned anything about turning off gcj aot compilation?
jwbnotting, is that what ppc requires?
* jwb doesn't know what 'aot' is
f13notting: no he didn't mention that.
jds2001abadger1999: will that sorta exists now in terms of people1.  just git.
nottingjwb: depends on how sharkified ppc is
abadger1999ahead of time compilation
f13notting: 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
jds2001but obviously stuff in fpeople isnt used in builds or anything
abadger1999jds2001: fedorapeople has different expectations from cvs.fedoraproject.org though.
jds2001abadger1999: true
f13the big deal here is that they need these packages in the buildroots
abadger1999f13: I'm just wondering about the issues that people raised in the generic case... like legal review before it goes into cvs.
f13and that's harder to do wide scale unless you have a "random crapbag" buildroot that has all sorts of in development junk in it.
jds2001the issues is today it's the java team.
tomorrow it's the ruby team, and hte next day the python folks come up.
f13it's easier resource wise to do this for one specific buildroot
abadger1999Which with java jars including other upstreams is always fun.
f13abadger1999: we can ask that a partial review is started for  each of them
at least for things like legal
abadger1999f13: That could be reasonable from my standpoint.
nottingyeah, the legal bits, the build from source/no binaries bits, etc. all need handled before it can be imported & built
f13jds2001: quite honestly, I wouldn't have a problem with doing targeted things for python/ruby/etc. if it's really needed
nirikf13: 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?
f13jds2001: 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
jds2001f13: if you're comfortable with it, I am.
f13that first line to jds2001 was from fnasser.
or not, n/m.
f13notting: a partial review I think is more than reasonable.
bpepplef13: If it passes a partial review for legal bit, no binaries, etc.  I'm fine with it.
* sharkcz nods
bpeppleWe 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.
f13ok, 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
f13review bugs will be filed for all, and tracked.  This may actually be an F12 feature which will help tracking.
abadger1999Can we have a full list of what's needed for partial review after running it by the packaging committee?
bpepple+1 to f13 proposal.
* abadger1999 puts it on the agenda for Tuesday.
jds2001i see five +1's, so we've approved f13's propsal.
f13rock, thanks guys.  I'll talk with fnasser about it and let him know to perhaps attend the package committee meeting
6 now
jds2001, i was wondering if we could get a quick strawman on ppc
jds2001i'd like to wrap up this meeting in the next 15 min if possible,
jwbi just want initial reactions to the topics
jds2001I have a $DAYJOB meeting i'd like to attend, but I told them I might not be able to.
jwber, topc
nirikabadger1999: you had another item?
abadger1999.fesco 116
zodbotabadger1999: #116 (figure out what to do about deactivated maintainers) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/116
jds2001didnt we already decide that?
jwbabadger1999, didn't we just talk about that?
* nirik has a sense of deja-vu
abadger1999.fesco 108
zodbotabadger1999: #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
jds2001oh, that one.....
abadger1999mmcgrath sent the threat assessment so this is back on the plate for discussion.
nottingabadger1999: are we using fs acls?
w/o that, i don't see how it's feasible to implement
abadger1999Not at the moment.
Just standard unix permissions.
jds2001notting wanted to correct the assessment that mmcgrath sent iirc.
abadger1999And the cvs acl thing.
nottingdon't think so
nirikjds2001: you mean dgilmore-oz
i had a bit-flip in my brain i guess :)
nirikI 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.
f13hey we could pin this on "the next SCM" to try and drive more interest that way
jwbpermissions system?
f13, was thinking the same
nirikwell, 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.
abadger1999f13: or kill it... one or the other ;-)
nottingf13: the next scm is git. the debate is what we put in it :)
nirikI 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.
jwbi think this is more than a 15min discussion
* nirik nods.
abadger1999So... 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.
abadger1999If so we can debate doing it via SCM, fs acls, etc.  But if it's not desirable then that's unnecessary work.
jwbabadger1999, if it's opt-in, possibly
jds2001but my attentiveness here may go down the tubes quickly :)
nirikI think if the cvs commit thing is fixed I would be willing to explore this.
jwbnirik, refresh my memory?
nottingabadger1999: if a packager really really really wants to do that, i don't think it's *bad*. not sure it accomplishes much either
jwbthe ctrl-c problem?
abadger1999jwb: Separate, explicit checkbox, so opt-in would be there.
nirikjwb: yes.
jwbnirik, ah.  k
nirikjwb: so, commit mail never sent.
abadger1999notting: I think the primary use case was desktop team packages.
jwbnirik, i'm starting to be less and less concerned about that
abadger1999They have hundreds of packages and not everyone on their team is in provenpackager
nirikjwb: how so? because builds will email?
jwbnirik, mostly, yes.  don't get me wrong, it's still a concern
* j-rod just got back in... meeting still going?
jwbj-rod, yep
niriksure, but once it's built it could go into the buildroot pretty quickly... and to rawhide also pretty quickly.
jwbnirik, having the cvs email sent out doesn't really decrease that windo
jds2001well once it's committed it's normally built immediately, no?
* jds2001 normally does things that way.
jwbnirik, because it still depends on someone actually reading it and then doing something before they submit the build
nirikyeah, I suppose. I guess a rouge commit would be noticed in a new checkin from the maintainer.
jwball i'm saying is that email notification is not a substitute for maintainer diligence
* nirik also doesn't think this is a short topic
jwbabadger1999, good enough for now?
or is there something specific you wanted today?
abadger1999Nope,  just wanted it to get back on the radar/people to think about it.
jwbyeah, good idea.  thanks
* j-rod finishes reading over the scrollback...
jwbso are people opposed to a brief, no-discussion ppc strawman?
bpepplejwb: I fine with talking about it.
jwbi'm trying to gauge how long we're going to talk about it next week :)
nottingno discussion? :)
jwbwell, discussion if we want
nottingmy opinion is that development has already begun on f12. ergo, -1 to ppc-as-seconday-for-f12, +1 to ppc-as-secondary-for-f13
jwbok, go with nottings format
* nirik nods and agrees with notting. Thats what I was going to say.
nirikthis would allow time for ppc folks to line up resources, start getting things setup, etc.
jwbbpepple, sharkcz, jds2001, ?
* jds2001 agrees with notting
sharkcz+1 to notting's proposal
* j-rod agrees w/notting and nirik
bpeppleI'm fine with notting's proposal.
j-rodalthough, damn, I missed the entire discussion where anyone said anything about making ppc secondary
jwbok, seems pretty unanimous
* j-rod has had head buried in crypto code the better part of the past few weeks...
jwbj-rod, happened at the board meeting
jwbj-rod, they gave the actual decision to FESCo
mmcgrathnotting: 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.
jwbjds2001, thanks.  i think the discussion will likely be brief next week.  just hammering out some more fine-grained details
nottingare we taking this as a Real Vote(tm) with more details later? or will we do the official vote next week?
jwbmaybe anyway
notting, there are noted missing people today that probably have input...
namely, dwmw2
possibly dgilmore
* jds2001 would do the official vote next week.
bpeppleyeah, jeremy and some other folks probably would want to weigh-in.
jwbjds2001, agreed
* dwmw2 is missing
dwmw2 stops that
jwbdwmw2, we were doing a strawman on ppc
dwmw2sorry, missed the call
jwbso far it's:
-1 to ppc-as-seconday-for-f12, +1 to ppc-as-secondary-for-f13
dwmw2my 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"
mbonnetdwmw2: we do?
f13dwmw2: different people.
dwmw2but if we can get the koji stuff _working_, I'm content with secondary-for-f12 even.
jds2001$DAYJOB call over already.
dwmw2f13: that's only apparent from the inside :)
mbonnetdwmw2: what part of the koji stuff is not working?
spotmbonnet: i have it written up, sent it to johnf, can send to you
dwmw2mbonnet: others can answer that better than I. Something about notification of package builds?
jwbmbonnet, 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
dwmw2would be nice to have a quick rundown from someone more clueful about what the current barriers are to secondary arches actually releasing.
mbonnetjwb: none of that stuff is *necessary* for secondary arches
dwmw2and maybe even a timescale for having them fixed.
jwbmbonnet, the board agrees with you
mbonnetall of those are "nice-to-haves" that would actually be better handled outside of koji
dwmw2what's the secondary arch in best shape right now? sparc?
jwbbelieve so
nirikso 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?
dwmw2why don't we have an actual release of F-10 for sparc, or beta of F-11?
jwbnirik, i have a question to the board about using existing infrastructure for a secondary effort
nottingnirik: yeah, we can't shut off updates for existing releases
dwmw2nirik: I think so, yes -- hopefully we can use the same builders to do both at once?
jwbnirik, that becomes a lesser question if the board and RH approves it
jds2001dwmw2: i asked specifically about the builders/compose boxen
jwbnirik, but it's a good question
jds2001they'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.
nirikI guess secondaries will need their own bodhi too?
dwmw2jds2001: 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?
jwbdwmw2, i believe so
jds2001dwmw2: not sure if one box cna talk to two hubs, no
mbonnet: ^^ ?
dwmw2It would be good to have a clear summary of what needs doing to get a secondary arch to release.
mbonnetjds2001: no, that's not possible
nottingdwmw2: 'do builds ; spin isos and trees'. simplified, but more or less correct
jwbmbonnet, not even if it's the same hub?
nirikdwmw2: and/or more communication in general... monthly/bi monthly reports to fesco from teams as to whats going on?
jwbmbonnet, meaning for f11, ppc is primary on the main hub, but for f12(or 13) it's secondary
mbonnetjwb: one box usually contains one kojid which talks to one kojihub
dwmw2notting: if it's that simple, how come we don't have a sparc release?
nottingdwmw2: the unstated 'fix the bugs that are platform specific' that might be messier? i dunno.
jwbmbonnet, yes.  i'm asking if a distinction on 'primaryness' can be made
f13dwmw2: because 2 people work on sparc?
mbonnetjwb: if it's talking to the main hub, then it's not secondary
pjonesdwmw2: total hours spent on it is very, very small.
f13: and they don't do so all that much.
dwmw2so they _could_ have released?
one of which is the same person who's working on the koji code
dwmw2I'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
jwbmbonnet, hm.  ok
pjonesdwmw2: 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.
jwbjds2001, so a transition of some builders might be needed.  not a huge deal
dwmw2pjones: 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
jwbdwmw2, we being who
dwmw2and then we can see if we're in good shape to switch off the primary.
jwb: those who care about ppc :)
jwbsure.  agreed.  now we just need those people to step up
the motivation needs to be there
after our discussion :)
does anyone want to change their strawman opinion?
* nirik does not
jwbnothing said has changed my opinion (which i conveniently didn't state)
dwmw2we're planning to decide this properly next week, right?
jwbdwmw2, yes
bpeppledwmw2: yup.
f13or the week after...
dwmw2can we ask for a report from the existing secondary architectures, summarising the reasons they haven't released yet?
jwbf13, no, next week
f13dwmw2: you can do whatever you want (:
jwbdwmw2, likely, yes.  arm just sent a report this week
mdomschwhile I'm not on FESCo, I have a mirror-related selfish reason to want to move ppc to secondary
jwbmdomsch, which is what?
jds2001mdomsch: :)
mdomschright now ppc takes roughly 30% of the disk space for a given release
jds2001master mirror space
mdomschand is carried by 130 of 187 mirrors
but is used by <2% of our user base
jwbmirrors can choose what they mirror, correct?
dwmw2and the best mirrors would be carrying secondary architectures anyway, surely?
mdomschjwb, 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
dwmw2don't the masters carry the secondary architectures, then?
shows 7
6 of which are gigabit or faster
jwbmdomsch, so you want to move the space off the masters
mdomschjwb, yes
mdomschdwmw2, no, the masters don't carry secondary content
dwmw2, that's all served from secondary1
mdomschthat's all thanks
jwbmdomsch, so i have a question for you
aside from free disk space, what do you gain?
mdomschjwb, reduction in sync times and bandwidth used to do the sync
mdomschthe masters are overloaded, often rejecting syncs
as it is
jwbwhen you say 'masters' do you mean the tier1 mirrors?
mdomschif I could reduce their load by 30% by not carrying that content, that would help
no, I mean download[12345].f.r.c
jwbah, ok
mdomsch(as if there are actually that many...)
jwbright, understand now
mdomschand 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
i don't have anything else
jds2001anyone else?
nottingwho'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!