FESCo-2009-02-06

--- 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.
* sharkcz here
j-rod here
nirik is here... going to grab a cup of coffee, back in a sec.
jds2001just pinged notting and dgilmore if they're around.
* notting is here
jds2001i suppose we can get started...folks could wander in late
--- jds2001 has changed the topic to: FESCo meeting - agenda at https://fedorahosted.org/fesco/report/9 - tickets
jds2001.fesco 34
zodbotjds2001: #34 (Package Renaming Guidelines) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/34
* f13 lurks
jds2001was this discussed yesterday or no?
* jds2001 hasnt had time to read the logs
sharkczjds2001: no
niriknope.
oh, who is doing the summary/minutes?
jds2001alright, no time like the present :)
good question, it would be you, but that'd be sort of shafting you :/
bpepplenirik: I believe it's dgilmore's turn to write the summary.
nirikI can just do them again... I don't care.
jds2001it is dgilmore's turn...hopefully he shows up :)
nirikok.
jds2001nim-nim: you around?
* dgilmore is here
jds2001dgilmore: your turn to write the summary.
nirikdgilmore: you want me to do minutes? or you want to?
dgilmoreif its my turn i can do it
bpeppleregarding the package renaming guidelines, my thought is they should have a package review in bugzilla.
dgilmorebpepple: i agree
dgilmorethe review should be simple to complete
jds2001me too...shouldnt be much.
dgilmorethe main issue is making sure obsoletes/provides are done correctly
f13hrm, I don't understand this ticket
f13why is it not clear that a rename is a new package, thus treat it like a new package.
nirikbasically we have no rule on renames currently.
dgilmoref13: because someone doesnt think that is the case
bpepplef13: my thoughts exactly.
nirikhttps://fedoraproject.org/wiki/PackagingDrafts/RenamingPackages
dgilmorenirik: we do  but we dont clearly state it is a new package and needs to be treated as such
f13it looks like a new package, smells like a new package, gets operated on like a new package, why isn't it a new package?
nirikdgilmore: can you point me to where such a rule is written down?
j-rodhm... if you rename "crap" to "rose", it still smells like "crap"...
jds2001f13: my thoughts exactly.
drago01f13: because it already was reviewed in the past (well thats how people think about it), but this should make the review easy anyway
j-rodhowever, a new package review should be reasonably easy to get through if it was already reviewed
nirikyeah, but it does mean adding it into the sea of pending reviews.
f13right, just because you're renaming it, doesn't mean you haven't changed other things.  From the KISS land, just treat it like a new package.  It should be a quick review.
dgilmorehttp://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages
nirik: ^^ mentions new package
* nirik waits for firefox to restart. Just upgraded it. ;(
drago01f13: well you don't have to rename the package to change other things
dgilmorenirik: the only thing that is maybe not as clear as it cold be is saying if you rename something a new review is needed.  its implied,  at least in my reading
bpepple-1 to package renaming draft. renames should have a package review.
f13drago01: sure.
nirikdgilmore: perhaps, but thats very much not clear to me or many people I have talked to.
I think it should be clearly stated in the policy pages.
drago01f13: lets take iotop as an example when I package it it was a single python file .. now it has an upstream tarball, man page etc .. and I just updated it without any rereviw
jds2001bpepple: i dont think FPC has voted on that draft yet.
nirikjds2001: they said it was not something for FPC, and asked me to bring it to fesco
bpepplejds2001: so, why is it on the agenda?
* bpepple sees nirik answered his question.
sharkczjds2001: IMO it is already few weeks old
* nirik wants fesco to decide.
nirikit's sounding like folks want any rename to require a regular package review?
notting_nirik: i'd prefer not
sharkczand it was related to renaming of font packages
nirikI was hoping we could just have some check on the obsoletes/provides.
drago01f13: so what we need is not "what to do on rename" but "when does a package require a rereview"
dgilmorenirik: it needs a review. at the least make sure provides/obsoletes are done correctly
jds2001and imo that needs to be in bugzilla, not on the mailing list.
j-rodalso to make sure comps gets updated, if necessary -- remove the old name, add the new name
notting_j-rod: not that that's tracked in bugzilla outside of saying "please do this"
j-rodtrue
j-rodI think a clear page on how to rename a package might be sufficient
but that pre-supposes the competency of the person reading the page
* f13 is not very keen on the idea of different review types for different package stages.
f13makes things confusing as a reviewer.
nirikj-rod: yeah, it should be noted/linked to under http://fedoraproject.org/wiki/PackageMaintainers/Policy
j-rodI'm sort of split on this one. Re-review seems like unnecessary overhead for a competent packager.
jds2001f13: but it should be noted that it's a rename such that the reviewer knows to look for provides/obsoletes in addition to everything else.
j-rodone would assume a re-review bug ought to point back to the original review bug too
f13jds2001: Provides/Obsoletes exist beyond just renames, they should be a part of the normal review guidelines.
jds2001: often something will get obviated by more than just a rename, a wholesale replacement.
nirikthrow into the mix the mass renames... like many of the font packages. Should they have some other way to do things? or just go thru the normal procedure (whatever we decide that is)
jds2001they still need to be looked at, i see no reason for there to be any special procedure.
what nim-nim was wanting, iiuc, is a rename in CVS, and after that the packagers go do their thing, and just hope they dtrt
nirikI know of at least one case I can think of off the top of my head where someone didn't want to rename something because of the review overhead.
jds2001: yeah, I don't think thats a good idea.
jds2001but a review of an already existing package should be trivial.
niriksure, but its hard to know what those are unless you know the package... you have to toss it into the review sea and wait. Or bug someone you know to review it.
bpepplealright, so where are we on this? We've got plenty of other items on the agenda today.
f13maybe there is room for marking the subject as (RENAME) ?
* nirik isn't sure where folks stand. Shall we vote on the proposal, and/or the 'requires a new review' plan?
j-rodwait. current policy is to do a full review on a rename? since when?
dgilmorej-rod: forever
* j-rod did a rename a while back, and just did it, no review...
j-rodoops
* dgilmore slaps j-rod
f13j-rod: there is no current policy explicitly for "renames"
nirikright, its not a written down policy anywhere I could find.
nottingheck, someone could check in a rename at any time to an existing module, and just not change the cvs name >:)
f13j-rod: there are only guidelines for new packages, and since a rename means a new cvs module, new bugzilla component, new pkgdb entry, new comps entry, etc... it's a new package.
j-rodso now... how did I manage to get through all of that w/o a review?
oh, meh
nirikI was hoping there would be a way to check obsoletes/provides with another pair of eyes, but without the overhead of a full re-review.
j-rodwe seem to have conflicting info here...
nirikj-rod: what package?
j-rodcpufrequtils
j-rodwe were shipping it as cpufreq-utils, upstream is cpufrequtils, so I fixed it
went along on my merry way
maybe I'm forgetting a bz
jds2001how did you fix it?
dgilmorej-rod: did you get a new cvs module?
nottingj-rod: 'fixed it'? i.e., 'mv cpufreq-utils cpufrequtils' on the cvs server?
nirikj-rod: yeah, I did that new name... as I didn't have any idea that a rereview was required.
dgilmoreor just rename in the existing module?
j-rodnew cvs module and everything
what nirik said. :)
j-rodI do recall reading over *something* wrt renames in the wiki though
* jwb is here now
j-rodand thought we followed it to the letter, so I dunno where 'current policy is you must have a new package review done' came from. :)
nirikj-rod: making that policy clear is what we should do now.
j-rodagreed
jds2001anyhow, what should the new policy be?
plenty of other stuff to talk about.
bpeppleyeah, we've spent over a 30 minutes on this.  I'm scared how long this meeting is going to take. ;)
nirikI made a proposal, but it sounds like people don't like it. Perhaps we vote on the proposal, and/or the 'every rename has to have a re-review' ?
sharkczthe proposed guideline is about review in the mailing list
bpepple-1 to mailing list review.
jds2001problem i have there is there's no really easily searchable record of it.
j-rodI'm still not sure what the best policy is. I thought what I went through was sufficient.
nottingnirik: ok. -1 to both?
jds2001-1 to mailing list review.
sharkcz-1
niriknotting: alternate proposal? ;)
f13why not just table it for now
and allow for other proposals to be worked on
j-rod-1 to both current options
table it
nirikf13: there are several pending... I guess I can just ask them to re-review for now.
j-rodnirik: based on our own experiences from cpufrequtils, I think we could come up with something. :)
jds2001sounds good
nirikalso there are a pile of fonts still needing new names.
f13It's clear that fesco would like to see some review of the changes, but is undecided on how much, and how.
j-rodI think what we did was sufficient, except for perhaps the tracking bit jds2001 mentioned
nirikj-rod: note that you didn't have obsoletes right on that change. ;)
f13j-rod: we should know by now that relying on "common sense" doesn't work in Fedora.
j-rodnirik: yeah, I think I vaguely recall screwing that up... heh
nottingnirik: i don't think a full re-review is necessary. it's certainly suffiicient if someone does that, of course
nirikok, so table for now, but could we at least say that the current guideline is 're-review' so I can tell people requesting renames something?
bpepplenirik: sounds good to me.
j-rodmy loose thought is to file a rename bug for tracking purposes, and the person handling the cvs changes could be responsible for making sure Obs/Prov are correct
jds2001sounds good here.
* j-rod shuts up now
nirikj-rod: I was hoping to avoid that as well...
j-rodyeah, true, adds additional responsibility to the cvs admin folks
nirikwhen processing 30 requests, it's hard enough to read thru all the reviews and check things, but if I have to look at obsoletes/provides too that adds even more overhead.
jds2001anyhow, lets discuss this offline and move on :)
nirikany more votes on the 'current policy until we get a better idea is re-review' ?
j-rodworksforme
jds2001oh, +1 to that.
sharkcz+1 for nirik
jds2001need two more :)
notting+1 in the interest of  moving on
bpepplereaffirms his earlier +1.
jds2001alrighty, current policy of re-review stands.
jds2001.fesco 47
zodbotjds2001: #47 (Documented QA Team Scope) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/47
bpepplejds2001: could we move onto features, since the are probably feature owners that have been waiting around?
* nirik looks around and sees no wwoods
jds2001sure
jds2001.fesco 38
zodbotjds2001: #38 (DebugInfoFS - https://fedoraproject.org/wiki/Features/DebuginfoFS) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/38
nottingi saw wwoods walk into a meeting room earlier. dunno if he made it out
bpeppleironically, this is wwoods feature. ;)
jds2001alright, moving on :)
jds2001.fesco 48
zodbotjds2001: #48 (Control Groups - https://fedoraproject.org/wiki/Features/ControlGroups) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/48
nottinghm? i thought we could vote on debuginfofs, if questions have been answered
notting(the one on the talk page is)
jds2001notting: i thought we needed wwoods
sorry
jds2001question i have here
we currently don't keep every version of every package around on the mirrors.
so I assume that this thing will grab right out of koji or something?
* jds2001 is unclear on how it's supposed to work, but the idea is cool.
sharkczad another question whether using a "filesystem" is the right approach
s/ad/there was/
nottingin the sense that it doesn't add a random network protocol library to gdb, i'd say it's a decent approach
mbonnetjds2001: koji doesn't keep every version of every package either (there is garbage collection)
jds2001mbonnet: it keeps stuff in dist-f10-updates though, right? just -candidate gets garbage collected since the stuff is unsigned.
or do i understand the GC wrong?
mbonnetjds2001: yes, anything signed with the release key is kept, which means -updates.  But -updates-testing won't get kept forever.  There's an expiration.
hpachas-PEquestion, fedora light version is avaible?
f13hpachas-PE: try #fedora
bpepple+1 debuginfo feature.
j-rod+1
sharkcz+1
notting+1
nirik+1
jds2001+1
jds2001i see six +1's, so we've approved debuginfofs
* dwmw2 arrives
jds2001.fesco 48
zodbotjds2001: #48 (Control Groups - https://fedoraproject.org/wiki/Features/ControlGroups) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/48
dwmw2I still wish we could get away without having it mounted
j-rodcontrolgroups... 0% is not so promising...
jds2001nope
a little under a month to go.
f13is that really FESCo concern though?
f13if it doesn't make it, it can be bounced.
nottingi have questions about some of the implementation details, but not "we should never ship this" type questions
bpepplef13: not really, we just punt it to F12.
f13right.  So long as there is a decent contengency plan, I don't think FESCo should really worry about % done
bpepplef13: agreed.
j-rodI still don't quite get exactly what the feature is here.
hpachas-PEf13, thanx
* nirik is trying to also figure that out. What does this get us?
j-rodis the feature simpy 'add libcgroups' ?
nottingno, the library is there already
j-rodoh, libcgroup, not libcgroups
yum search fail
so the feature is to make something that's already in work better?
jds2001_gack
my vps just died, sorry
so last i saw we had concerns about controlgroups
being 0%
j-rodthen we were trying to figure out what the feature actually is
f13notting seems to have some clue...
bpepplejds2001: Like f13 said, I don't think we should worry about the progress, since we can just punt it to F12.
nottingj-rod: i *think* so. there are proposed patches to set up groups for daemons we start
* nirik agrees... % should not matter at this point... but will if it's still not testable by freeze
sharkczwe should invite nils or ivana ...
j-rodcan we punt this one to next week, ask the feature owner(s) to be present and/or better explain what the actual feature is here?
nirikj-rod: +1
notting+1
bpepplej-rod: yeah, that sounds like a good idea. +1
sharkcz+1
j-rod+1 to myself (can I do that? :)
sharkcznotting: aren't "your groups" related to upstart?
jds2001+1
nottingsharkcz: ?
jds2001moving right along....
jds2001.fesco 49
zodbotjds2001: #49 (Empathy - https://fedoraproject.org/wiki/Features/Empathy) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/49
sharkcznotting: you was talking about "groups of daemons we start" - is it upstart?
nottingsharkcz: no, it's setting a control group in /etc/sysconfig/<your service here>
sharkcznotting: ok
nirikok, empathy wasn't ready for f10, is it ready now?
notting+1 to empathy 2: electric boogaloo
nirikI guess +1 here, and if it doesn't get done/isn't ready it can be punted again.
jds2001+1 here, same caveats
nottingwell, except for the 'reevaluate empathy around alpha time'. a little late for that.
f13is there a proper scope and test plan that will help FESCo decide if it's "good enough" by beta?
jds2001lots o' QA love needed here.
so it mentions trying various protocols
f13that was one big issue last time, there was no clear criteria for "good enough"
j-rod+1, same as above. needs at least feature-parity w/pidgin
bpepple+1 empathy (on the discussion page I've been putting pro & con arguments to help determine if it should replace pidgin)
sharkcz+1, but the feature page is quite old
jds2001I'd actually like to see "compare the two for feature-parity"
mclasenf13: honestly, I don't think it is really fescos job to decide if empathy is good enough...
jds2001whose job is it?
j-rodDesktop SIG, possibly
f13mclasen: somebody has to decide if it's good enough at feature freeze time.
mclasenright
f13mclasen: by default that falls to FESCo, but I'm sure they wouldn't mind letting somebody else make that determination
mclasenI tried to get some discussion about it going on fedora-desktop-list last week
f13and its not like FESCo would make such a call in a vacuum.
mclasennot too successfully
* dgilmore slaps j-rod +1
bpepplemclasen: I added some points to the discussion page, but I don't think anyone else has taken the time. :(
j-roddgilmore: well, they'd say its good enough, but would still have to present their case to fesco for feature approval
nottingi'm not sure if we've ever defined directly who's responsible for determining whether a feature meets the functional criteria (fesco vs qa vs voting-on-mailing-list vs...)
dgilmoreopps sorry j-rod
j-rod(np, I was clear as mud :)
mclasenbpepple: yes, thanks
dgilmoremclasen: FESCo is responsible for accepting/punting features.  we take feedback from outside fesco to make our decsision
mclasenbpepple: we need to get 2.25.90 into rawhide, too. I wondered if you want to builid that...
dgilmoremclasen: so if the Desktop SIG come and says it rocks does everything pigin did and makes you an omlet for breakfast.  we wouls say great  give me an omlet and lets move on :)
bpepplemclasen: yeah, I can do that later this afternoon.
nottingso, i think there's 6 +1
bpepplenotting: correct.
j-rodNEXT
jds2001sorry
jds2001.fesco 50
zodbotjds2001: #50 (GFS2 stable - https://fedoraproject.org/wiki/Features/GFS2Stable) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/50
swhitehoI'm lurking if you want to ask me something
nottingseems reasonable - +1. although it sort of makes a value statement about what was there before :)
dgilmore+!
sharkcz+1
bpepple+1
nirikshould this include a option on install to use that fs?
jds2001+1
dgilmorepretty much everything is there and we tout fedora's awesomeness in running clusters
jds2001nirik: it only makes a little bit of sense to do so.
swhitehonirik: maybe, but that can some later if required
dgilmorenirik: not sure if you would ever use gfs2 for /
swhitehos/some/come
gfs2 on root does make some sense, and I know of people who are doing it
* nirik notes that the 'release notes' section should probibly just be documentation?
j-rod+1
swhitehoits not currently encouraged though
nirik: yes, possibly. it needs to be cleaned up a bit, but we can work on that
jds2001anyhow, i see 6 +1's
nirikswhiteho: release notes should be the text that goes into the end user release notes... just a english summary of what this is, why it's cool and how to use it. ;)
swhitehogood. I can go and have my tea :-) thanks all
nirikyeah, +1 anyhow fwiw
jds2001alright, NEXT
jds2001.fesco 51
sharkczswhiteho: thanks for being here
zodbotjds2001: #51 (K12Linux - https://fedoraproject.org/wiki/Features/GFS2Stable) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/51
jds2001oops
swhitehonirik: yes, I like to make people aware of all the things I know they'll run into though - its a fine line, so we can fix it as we move forward
sharkcz: np
jds2001that link is obviously wrong :)
nirikswhiteho: ok, but that looks too verbose to me... anyhow, talk to the docs folks. ;)
jds2001https://fedoraproject.org/wiki/Features/K12Linux
swhitehonirik: will do
nirikok, so this was mostly done in f10, but not soon enough to tout?
bpepplenirik: I believe that was the case.
j-rodso is this a remix or a spin or ?
jds2001warren: you around?
nirikj-rod: neither. You install the server on a fedora box, then setup thin clients using it.
warrenjds2001: no
jds2001: what's up?
f13this seems like a spin to me
j-rodnirik: but there's an iso...
jds2001the k12linux feature we're discussing now.
is it a spin?
j-rodso it can be added to an existing fedora box, but it looks like its also a spin
warrenI was asked by poelstra to push it as a feature.  I don't particularly care if it is a feature or not.
all the work is done
nirikI guess it's both.
warrenjds2001: it is both a spin and not a spin.  You can install K12Linux on any standard Fedora.
nirikwarren: whats on the iso/spin?
jds2001yeah, i guess so.
j-rodwarren: are the "new components" (ltsp-*) in the Fedora repos now?
nirik+1 from me, but I want the release notes filled in. ;)
notting+1, seems fine
sharkcz+1
dgilmore+1  with releng signoff on the spin portion
warrennirik: preconfigured server with a chroot that boots on thin clients.  You can boot both the server and an entire network of clients off of a USB stick, which is better than all the other distros.
poelcatwarren: i didn't say you "had to"... I asked if you wanted to :)
f13warren: are you wanting Fedora to produce a live iso and post it to spins.fp.o ?
warrenf13: Not really.
* nirik points warren at the spins sig/process for that.
f13ok, then I'll happily ignore this
warrenthis violates the spin guidelines in several ways.
dgilmorewarren: if you produce an iso.  it really should be done the right way
nirikI think the spin is totally seperate... I was only voting on the feature.
jds2001warren: in what ways?
warrenI also have been reassigned to work on other things now, so I can't put a lot of time into K12Linux anymore to make changes.  It hit feature completion and is now in maintenance mode forever until it is replaced with *secret next gen way better thing*.
* f13 notes that if the iso isn't done as a spin, it doesn't really matter so long as it adheres to the trademark policy.
warrenjds2001: Jeroen (sp?) seemed to be very confused by it, I didn't have time to follow up
jds2001np
nirikwarren: is anyone taking over for you working on this? or you will just do maint as you can?
warrennirik: I help in maint, an upstream developer is taking over packaging
nirikcool.
j-rod+1 for something in the release notes about Fedora being a great platform for k12linux
warrenwhat is the deadline to write that blurb?
bpepple+1
j-rodslightly hazy on what's actually *in* Fedora though
warrenj-rod: it reuses 100% fedora components in unusual ways
if you don't have time to look at it, don't worry
more important things to work on
jds2001+1 here
j-rodwarren: ok, gotcha, I see ltsp-client, ltsp-server in the repos, etc.
so yeah, cool
and the iso will exist outside the spins domain
warrenthe ISO is only of interest of people wanting to deploy large networks of it, it is a very niche product
j-rodjust has to adhere to the trademark guidelines
where's the iso being hosted?
warrenj-rod: alt.fedoraproject.org is where mmcgrath said to put it.
j-rodoh. hrm.
warrenj-rod: the target user can't use bittorrent because their school, business or university network blocks torrent.  We can put it on torrent download as well.
though
j-rodin that case, it sort of seems like it should be reviewed by *someone* if its going to sit on fedora servers
warrenIt is built from 100% fedora packages
dgilmorewarren: as long as you comply with trademark guidelines it can go whereever it goes
warrenright
dgilmorewarren: you need to make sure you sue the generic release etc packages
warrenIs there any actual problem here?  otherwise move on.
dgilmores/sue/use/
warrendgilmore: err, why?
j-rodbut don't spins have to go through a certain process to get officially hosted?
warrendgilmore: it is 100% Fedora
dgilmorewarren: because thats what the trademark guidelines say
AFAIK anyways
i could be wrong
jds2001unless you have board approval for the trademark.
warrendgilmore: isn't it that if you use 100% fedora packages you are in compliance with trademark guidelines?  if not, then you need to use generic.
dgilmorewarren: no its if its not an offical spin AFAIK
jds2001dgilmore: no, the actual spin needs board approval to use the mark.
dgilmorejds2001: thats what i thought
jds2001you can call it a fedora remix if you like.
warrenremixes contain 100% fedora components?
jds2001they can or not.
warrenIf I'm understanding correctly, I don't have to change anything, just get the board to approve it?
jds2001if that made sense :)
dgilmoreanyways thats another discussion
warren: likely
warrenI really don't have time to respin and do all the QA tests again.
j-rodhttps://fedoraproject.org/wiki/Legal:Trademark_guidelines
warrenanyway, please move on.
* warren reads
jds2001moving right along....
jds2001.fesco 52
zodbotjds2001: #52 (Netbeans 6.5 - https://fedoraproject.org/wiki/Features/NetBeans_6.5) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/52
bpepple+1 fairly straight forward.
j-rodwarren: "Unmodified Fedora software" section looks applicable
jds2001+1 here
j-rod(i.e., just get board approval)
warrenj-rod: the intent was to make K12Linux another Fedora sub-brand
j-rod+1 to netbeans
warrenj-rod: we bought all rights and domain names related to it.
nirik+1 to netbeans
dgilmore+1 to netbeans
notting+1. mmm, beans.
sharkcz+1 for  netbeans
j-rodwarren: ah, didn't know that. should be trivial to get approval then :)
jds2001i see 7 +1's for netbeans, so we've approved the netbeans feature
jds2001.fesco 53
zodbotjds2001: #53 (New text UI - https://fedoraproject.org/wiki/Features/NewTextUI) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/53
niriktext mode has always lacked some things that were available in gui mode... like encrypted disk setup
j-rodwriting everything 2x sucks
jds2001yep. and will continue to do so :)
sharkczand parts of LVM setup
jds2001but yeah, we should detect missing parts of a ks file that we can't prompt for anymore early on.
bpepple+1 to TextUI feature.
jds2001rather than barfing when we get there.
* notting is +1 to the NewSpeak NewTextUI
j-rodwhoa, no package selection in text mode... bold... but I like it...
jds2001+1
nirik+1 here.
sharkcz+1
j-rod(assuming what does get installed lets you do everything you need to do to add stuff)
jds2001i see five +1's, so we've approved the new text UI.
nottingpoelcat: i think we punted cgroups
j-rod(and can install whatever you want via kickstart)
+1 as well
jds2001.fesco 54
zodbotjds2001: #54 (noarch subpackages - https://fedoraproject.org/wiki/Features/NoarchSubpackages) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/54
* ffesti is there for questions
nirikthis should land before mass rebuild hopefully? or at the same time?
jds2001so i know we're upgrading koji in a bit.  forget the exact date
dgilmorekoji support for this will land in just over 2 weeks
21st feb
j-rod+1, been wanting this for ages
bpeppledo we know when the gcc/arch rebuild is happening?
sharkcz+1
jds2001this requires action from package maintainers, though, right?
nottingis this done by 'built it twice', or is it done automatically?
jds2001like to specify the subpackage as noarch
nirik+1 here
ffestiMaintainer need to add BuildArch: noarch to the sub packages
dgilmorejds2001: packahe maintainers will need to modify specs for this
ffestiand check whether turning the noarch is really ok
nirikI would like to see that list posted to devel at least/possibly devel announce... asking people to look and see if they can do this on their packages.
ffestis/the/them/
nirik(once it has landed)
ffestithis is on the todo list
jds2001+1 here.
notting+1
bpepple+1 to NoArchSubpackages.
nirikffesti: ah yes. Sorry, read to fast. ;)
ffestiI just want Fesco's backing before bugging hundreds of package maintainers
jds2001bugging them is cool with me :)
ffestiThere will also be requests for changes in Packaging and Review guidlines as soon as I have the texts ready
bpepplelooks like there are six '+1' for this feature.
jds2001yep, moving right along.
dgilmore+1
jds2001.fesco 55
zodbotjds2001: #55 (Power management - https://fedoraproject.org/wiki/Features/PowerManagement) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/55
bpepple+1 looks reasonable to me.
jds2001+1 here
* nirik isn't sure another daemon for tuning is a good idea
notting+1 in general. would prefer more "just do it" right things, less docs
nirikyeah. +1 here, agree with notting.
jds2001yeah, but what's right for you might not be right for me.
j-rod+1, what notting said
jds2001but yeah, reading sucks
pknirsch^^
sharkcz+1
jds2001i see six +1's, so we've approved this feature.
and that's all I had for today
--- jds2001 has changed the topic to: FESCo meeting - open floor
jds2001anyone got anything else?
* nirik notes someone on a local channel here does a kill -STOP on firefox, then kill -CONT when they want to use it. Really reduces the wakeups. ;)
mitrStrongerHashes ?
jds2001mitr: ahh, right.
jds2001mitr: so we were wondering about the feasabiltiy of newer rpm in F9 iirc
j-rodjds2001: FPC review as well
jds2001ouch!
* jds2001 fail.
mitrFirst, I was wrong: preupgrade from F9 to rawhide actually works (because preupgrade does not use rpm)
j-rodalthough we've already gone 2hr and $dayjob beckons...
mitrSo, the supported installation path is OK.
mitrAs for (yum update), Pan doesn't want to backport the support nor to publish a new rpm as an update.
So, there are two options:
1) tell users to upgrade in two stages, f9 -> f10 -> f11
2) Put a f11 rpm rebuilt for f9 in a repo somewhere, tell users who want to (yum upgrade) to manually update to this rpm
dgilmoremitr: neither of those are options
mitr[a few dependencies to things like gdb and net-snmp will break, but those will be fixed by the update to f11]
mitrdgilmore: Then I don't know how to make (yum update) work
dgilmoremitr: have both hases in the rpm
nirikor defer until f12?
jds2001in my mind, it's not a supported upgrade path. Though it is one a lot of people are forced to use.
nirikwell, I guess that doesn't help. nevermind.
mitrdgilmore: that will almost double the update memory requirement
dgilmoreso that yum update with the old rpm works.  and then updates use the newer hashing
jds2001nirik: why doesnt it help?
mitrdgilmore: Also, rpm-4.6.0 with the single hash format was already released.
nirikjds2001: hum. perhaps it does. We need a rpm that can handle new format, as well as old format.
jds2001nirik: right, and 4.6 is in F10.  So yum upgrade from oldest supported -> newest works.
dgilmoremitr: upgrades from F-9 to F-11 need to be supported.
nottingmitr: what does dropping 4.6.0 into f9 break?
dgilmoremitr: without hacks
mitrdgilmore: All officially supported installation paths are supported.
dgilmoremitr: yum updates are officially supported last i looked
its what ive used for years before we supported it
nirikwell, not sure if they are official or not, but it's not nice to break them IMHO.
mitrnotting: I'm not sure - but IIRC there are incompatibilities at least in the rpmbuild behavior (fuzz, etc.)
nottingthat's configurable ,  though
dgilmoremitr: fuzz can be configured
mitrWell, Panu vetoed it.
dgilmoremitr: we need some way for it to work.  or we revert stronger hashes
mitrdgilmore: http://fedoraproject.org/wiki/YumUpgradeFaq says live upgrades are "not recommended".
* j-rod says throw rpm 4.6 at f9 just before f11 is released
jds2001well that wouldnt be good
no time to update it if it busts the world.
dgilmoremitr: not recommended doesnt mean not supported
mitrdgilmore: I can't offer you such a way.  At best I can propose dropping the filedigest change from the feature, continuing with the rest for f11, and changing digests in f12.
j-rod"just before" could be a couple weeks
dgilmoremitr: seriously?  you had to know when you started on this that F-9 to F-11 had to be fully supported
* j-rod wanders away for a bit, starving
mitrdgilmore: Well, I didn't expect the (yum update) requirement.
nirikcan we ask panu direct why f9 update is not possible?
* jds2001 goes to turn the oven on to cook a pizza
nirik also needs to go soon... work piling up.
dgilmoremitr: i dont believe that for one second
nottinghe's not around now, but we probably should
* dgilmore says we need to deffer until Panu is here
jds2001yeah
nirik+1 defer and ping Panu, end meeting. ;)
jds2001+1 to ending meeting.
We need to address the QA charter thing next week.
jds2001 jds2001_
bpepplejds2001: definitely.
sharkczand FPC
* jds2001 ends the meeting in 5
jds2001right.
they just had one thing.
twitter2asd
jds2001-- MEETING END --

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!