| --- 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. | ||
| * sharkcz here | ||
| j-rod here | ||
| nirik is here... going to grab a cup of coffee, back in a sec. | ||
| jds2001 | just pinged notting and dgilmore if they're around. | |
| * notting is here | ||
| jds2001 | i 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 | |
| zodbot | jds2001: #34 (Package Renaming Guidelines) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/34 | |
| * f13 lurks | ||
| jds2001 | was this discussed yesterday or no? | |
| * jds2001 hasnt had time to read the logs | ||
| sharkcz | jds2001: no | |
| nirik | nope. | |
| oh, who is doing the summary/minutes? | ||
| jds2001 | alright, no time like the present :) | |
| good question, it would be you, but that'd be sort of shafting you :/ | ||
| bpepple | nirik: I believe it's dgilmore's turn to write the summary. | |
| nirik | I can just do them again... I don't care. | |
| jds2001 | it is dgilmore's turn...hopefully he shows up :) | |
| nirik | ok. | |
| jds2001 | nim-nim: you around? | |
| * dgilmore is here | ||
| jds2001 | dgilmore: your turn to write the summary. | |
| nirik | dgilmore: you want me to do minutes? or you want to? | |
| dgilmore | if its my turn i can do it | |
| bpepple | regarding the package renaming guidelines, my thought is they should have a package review in bugzilla. | |
| dgilmore | bpepple: i agree | |
| dgilmore | the review should be simple to complete | |
| jds2001 | me too...shouldnt be much. | |
| dgilmore | the main issue is making sure obsoletes/provides are done correctly | |
| f13 | hrm, I don't understand this ticket | |
| f13 | why is it not clear that a rename is a new package, thus treat it like a new package. | |
| nirik | basically we have no rule on renames currently. | |
| dgilmore | f13: because someone doesnt think that is the case | |
| bpepple | f13: my thoughts exactly. | |
| nirik | https://fedoraproject.org/wiki/PackagingDrafts/RenamingPackages | |
| dgilmore | nirik: we do but we dont clearly state it is a new package and needs to be treated as such | |
| f13 | it looks like a new package, smells like a new package, gets operated on like a new package, why isn't it a new package? | |
| nirik | dgilmore: can you point me to where such a rule is written down? | |
| j-rod | hm... if you rename "crap" to "rose", it still smells like "crap"... | |
| jds2001 | f13: my thoughts exactly. | |
| drago01 | f13: because it already was reviewed in the past (well thats how people think about it), but this should make the review easy anyway | |
| j-rod | however, a new package review should be reasonably easy to get through if it was already reviewed | |
| nirik | yeah, but it does mean adding it into the sea of pending reviews. | |
| f13 | right, 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. | |
| dgilmore | http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages | |
| nirik: ^^ mentions new package | ||
| * nirik waits for firefox to restart. Just upgraded it. ;( | ||
| drago01 | f13: well you don't have to rename the package to change other things | |
| dgilmore | nirik: 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. | |
| f13 | drago01: sure. | |
| nirik | dgilmore: 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. | ||
| drago01 | f13: 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 | |
| jds2001 | bpepple: i dont think FPC has voted on that draft yet. | |
| nirik | jds2001: they said it was not something for FPC, and asked me to bring it to fesco | |
| bpepple | jds2001: so, why is it on the agenda? | |
| * bpepple sees nirik answered his question. | ||
| sharkcz | jds2001: IMO it is already few weeks old | |
| * nirik wants fesco to decide. | ||
| nirik | it's sounding like folks want any rename to require a regular package review? | |
| notting_ | nirik: i'd prefer not | |
| sharkcz | and it was related to renaming of font packages | |
| nirik | I was hoping we could just have some check on the obsoletes/provides. | |
| drago01 | f13: so what we need is not "what to do on rename" but "when does a package require a rereview" | |
| dgilmore | nirik: it needs a review. at the least make sure provides/obsoletes are done correctly | |
| jds2001 | and imo that needs to be in bugzilla, not on the mailing list. | |
| j-rod | also 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-rod | true | |
| j-rod | I 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. | ||
| f13 | makes things confusing as a reviewer. | |
| nirik | j-rod: yeah, it should be noted/linked to under http://fedoraproject.org/wiki/PackageMaintainers/Policy | |
| j-rod | I'm sort of split on this one. Re-review seems like unnecessary overhead for a competent packager. | |
| jds2001 | f13: 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-rod | one would assume a re-review bug ought to point back to the original review bug too | |
| f13 | jds2001: 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. | ||
| nirik | throw 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) | |
| jds2001 | they 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 | ||
| nirik | I 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. | ||
| jds2001 | but a review of an already existing package should be trivial. | |
| nirik | sure, 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. | |
| bpepple | alright, so where are we on this? We've got plenty of other items on the agenda today. | |
| f13 | maybe 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-rod | wait. current policy is to do a full review on a rename? since when? | |
| dgilmore | j-rod: forever | |
| * j-rod did a rename a while back, and just did it, no review... | ||
| j-rod | oops | |
| * dgilmore slaps j-rod | ||
| f13 | j-rod: there is no current policy explicitly for "renames" | |
| nirik | right, its not a written down policy anywhere I could find. | |
| notting | heck, someone could check in a rename at any time to an existing module, and just not change the cvs name >:) | |
| f13 | j-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-rod | so now... how did I manage to get through all of that w/o a review? | |
| oh, meh | ||
| nirik | I 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-rod | we seem to have conflicting info here... | |
| nirik | j-rod: what package? | |
| j-rod | cpufrequtils | |
| j-rod | we 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 | ||
| jds2001 | how did you fix it? | |
| dgilmore | j-rod: did you get a new cvs module? | |
| notting | j-rod: 'fixed it'? i.e., 'mv cpufreq-utils cpufrequtils' on the cvs server? | |
| nirik | j-rod: yeah, I did that new name... as I didn't have any idea that a rereview was required. | |
| dgilmore | or just rename in the existing module? | |
| j-rod | new cvs module and everything | |
| what nirik said. :) | ||
| j-rod | I do recall reading over *something* wrt renames in the wiki though | |
| * jwb is here now | ||
| j-rod | and thought we followed it to the letter, so I dunno where 'current policy is you must have a new package review done' came from. :) | |
| nirik | j-rod: making that policy clear is what we should do now. | |
| j-rod | agreed | |
| jds2001 | anyhow, what should the new policy be? | |
| plenty of other stuff to talk about. | ||
| bpepple | yeah, we've spent over a 30 minutes on this. I'm scared how long this meeting is going to take. ;) | |
| nirik | I 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' ? | |
| sharkcz | the proposed guideline is about review in the mailing list | |
| bpepple | -1 to mailing list review. | |
| jds2001 | problem i have there is there's no really easily searchable record of it. | |
| j-rod | I'm still not sure what the best policy is. I thought what I went through was sufficient. | |
| notting | nirik: ok. -1 to both? | |
| jds2001 | -1 to mailing list review. | |
| sharkcz | -1 | |
| nirik | notting: alternate proposal? ;) | |
| f13 | why not just table it for now | |
| and allow for other proposals to be worked on | ||
| j-rod | -1 to both current options | |
| table it | ||
| nirik | f13: there are several pending... I guess I can just ask them to re-review for now. | |
| j-rod | nirik: based on our own experiences from cpufrequtils, I think we could come up with something. :) | |
| jds2001 | sounds good | |
| nirik | also there are a pile of fonts still needing new names. | |
| f13 | It's clear that fesco would like to see some review of the changes, but is undecided on how much, and how. | |
| j-rod | I think what we did was sufficient, except for perhaps the tracking bit jds2001 mentioned | |
| nirik | j-rod: note that you didn't have obsoletes right on that change. ;) | |
| f13 | j-rod: we should know by now that relying on "common sense" doesn't work in Fedora. | |
| j-rod | nirik: yeah, I think I vaguely recall screwing that up... heh | |
| notting | nirik: i don't think a full re-review is necessary. it's certainly suffiicient if someone does that, of course | |
| nirik | ok, 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? | |
| bpepple | nirik: sounds good to me. | |
| j-rod | my 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 | |
| jds2001 | sounds good here. | |
| * j-rod shuts up now | ||
| nirik | j-rod: I was hoping to avoid that as well... | |
| j-rod | yeah, true, adds additional responsibility to the cvs admin folks | |
| nirik | when 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. | |
| jds2001 | anyhow, lets discuss this offline and move on :) | |
| nirik | any more votes on the 'current policy until we get a better idea is re-review' ? | |
| j-rod | worksforme | |
| jds2001 | oh, +1 to that. | |
| sharkcz | +1 for nirik | |
| jds2001 | need two more :) | |
| notting | +1 in the interest of moving on | |
| bpepple | reaffirms his earlier +1. | |
| jds2001 | alrighty, current policy of re-review stands. | |
| jds2001 | .fesco 47 | |
| zodbot | jds2001: #47 (Documented QA Team Scope) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/47 | |
| bpepple | jds2001: could we move onto features, since the are probably feature owners that have been waiting around? | |
| * nirik looks around and sees no wwoods | ||
| jds2001 | sure | |
| jds2001 | .fesco 38 | |
| zodbot | jds2001: #38 (DebugInfoFS - https://fedoraproject.org/wiki/Features/DebuginfoFS) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/38 | |
| notting | i saw wwoods walk into a meeting room earlier. dunno if he made it out | |
| bpepple | ironically, this is wwoods feature. ;) | |
| jds2001 | alright, moving on :) | |
| jds2001 | .fesco 48 | |
| zodbot | jds2001: #48 (Control Groups - https://fedoraproject.org/wiki/Features/ControlGroups) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/48 | |
| notting | hm? i thought we could vote on debuginfofs, if questions have been answered | |
| notting | (the one on the talk page is) | |
| jds2001 | notting: i thought we needed wwoods | |
| sorry | ||
| jds2001 | question 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. | ||
| sharkcz | ad another question whether using a "filesystem" is the right approach | |
| s/ad/there was/ | ||
| notting | in the sense that it doesn't add a random network protocol library to gdb, i'd say it's a decent approach | |
| mbonnet | jds2001: koji doesn't keep every version of every package either (there is garbage collection) | |
| jds2001 | mbonnet: 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? | ||
| mbonnet | jds2001: 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-PE | question, fedora light version is avaible? | |
| f13 | hpachas-PE: try #fedora | |
| bpepple | +1 debuginfo feature. | |
| j-rod | +1 | |
| sharkcz | +1 | |
| notting | +1 | |
| nirik | +1 | |
| jds2001 | +1 | |
| jds2001 | i see six +1's, so we've approved debuginfofs | |
| * dwmw2 arrives | ||
| jds2001 | .fesco 48 | |
| zodbot | jds2001: #48 (Control Groups - https://fedoraproject.org/wiki/Features/ControlGroups) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/48 | |
| dwmw2 | I still wish we could get away without having it mounted | |
| j-rod | controlgroups... 0% is not so promising... | |
| jds2001 | nope | |
| a little under a month to go. | ||
| f13 | is that really FESCo concern though? | |
| f13 | if it doesn't make it, it can be bounced. | |
| notting | i have questions about some of the implementation details, but not "we should never ship this" type questions | |
| bpepple | f13: not really, we just punt it to F12. | |
| f13 | right. So long as there is a decent contengency plan, I don't think FESCo should really worry about % done | |
| bpepple | f13: agreed. | |
| j-rod | I still don't quite get exactly what the feature is here. | |
| hpachas-PE | f13, thanx | |
| * nirik is trying to also figure that out. What does this get us? | ||
| j-rod | is the feature simpy 'add libcgroups' ? | |
| notting | no, the library is there already | |
| j-rod | oh, 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-rod | then we were trying to figure out what the feature actually is | |
| f13 | notting seems to have some clue... | |
| bpepple | jds2001: Like f13 said, I don't think we should worry about the progress, since we can just punt it to F12. | |
| notting | j-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 | ||
| sharkcz | we should invite nils or ivana ... | |
| j-rod | can 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? | |
| nirik | j-rod: +1 | |
| notting | +1 | |
| bpepple | j-rod: yeah, that sounds like a good idea. +1 | |
| sharkcz | +1 | |
| j-rod | +1 to myself (can I do that? :) | |
| sharkcz | notting: aren't "your groups" related to upstart? | |
| jds2001 | +1 | |
| notting | sharkcz: ? | |
| jds2001 | moving right along.... | |
| jds2001 | .fesco 49 | |
| zodbot | jds2001: #49 (Empathy - https://fedoraproject.org/wiki/Features/Empathy) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/49 | |
| sharkcz | notting: you was talking about "groups of daemons we start" - is it upstart? | |
| notting | sharkcz: no, it's setting a control group in /etc/sysconfig/<your service here> | |
| sharkcz | notting: ok | |
| nirik | ok, empathy wasn't ready for f10, is it ready now? | |
| notting | +1 to empathy 2: electric boogaloo | |
| nirik | I guess +1 here, and if it doesn't get done/isn't ready it can be punted again. | |
| jds2001 | +1 here, same caveats | |
| notting | well, except for the 'reevaluate empathy around alpha time'. a little late for that. | |
| f13 | is there a proper scope and test plan that will help FESCo decide if it's "good enough" by beta? | |
| jds2001 | lots o' QA love needed here. | |
| so it mentions trying various protocols | ||
| f13 | that 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 | |
| jds2001 | I'd actually like to see "compare the two for feature-parity" | |
| mclasen | f13: honestly, I don't think it is really fescos job to decide if empathy is good enough... | |
| jds2001 | whose job is it? | |
| j-rod | Desktop SIG, possibly | |
| f13 | mclasen: somebody has to decide if it's good enough at feature freeze time. | |
| mclasen | right | |
| f13 | mclasen: by default that falls to FESCo, but I'm sure they wouldn't mind letting somebody else make that determination | |
| mclasen | I tried to get some discussion about it going on fedora-desktop-list last week | |
| f13 | and its not like FESCo would make such a call in a vacuum. | |
| mclasen | not too successfully | |
| * dgilmore slaps j-rod +1 | ||
| bpepple | mclasen: I added some points to the discussion page, but I don't think anyone else has taken the time. :( | |
| j-rod | dgilmore: well, they'd say its good enough, but would still have to present their case to fesco for feature approval | |
| notting | i'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...) | |
| dgilmore | opps sorry j-rod | |
| j-rod | (np, I was clear as mud :) | |
| mclasen | bpepple: yes, thanks | |
| dgilmore | mclasen: FESCo is responsible for accepting/punting features. we take feedback from outside fesco to make our decsision | |
| mclasen | bpepple: we need to get 2.25.90 into rawhide, too. I wondered if you want to builid that... | |
| dgilmore | mclasen: 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 :) | |
| bpepple | mclasen: yeah, I can do that later this afternoon. | |
| notting | so, i think there's 6 +1 | |
| bpepple | notting: correct. | |
| j-rod | NEXT | |
| jds2001 | sorry | |
| jds2001 | .fesco 50 | |
| zodbot | jds2001: #50 (GFS2 stable - https://fedoraproject.org/wiki/Features/GFS2Stable) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/50 | |
| swhiteho | I'm lurking if you want to ask me something | |
| notting | seems reasonable - +1. although it sort of makes a value statement about what was there before :) | |
| dgilmore | +! | |
| sharkcz | +1 | |
| bpepple | +1 | |
| nirik | should this include a option on install to use that fs? | |
| jds2001 | +1 | |
| dgilmore | pretty much everything is there and we tout fedora's awesomeness in running clusters | |
| jds2001 | nirik: it only makes a little bit of sense to do so. | |
| swhiteho | nirik: maybe, but that can some later if required | |
| dgilmore | nirik: not sure if you would ever use gfs2 for / | |
| swhiteho | s/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 | |
| swhiteho | its not currently encouraged though | |
| nirik: yes, possibly. it needs to be cleaned up a bit, but we can work on that | ||
| jds2001 | anyhow, i see 6 +1's | |
| nirik | swhiteho: 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. ;) | |
| swhiteho | good. I can go and have my tea :-) thanks all | |
| nirik | yeah, +1 anyhow fwiw | |
| jds2001 | alright, NEXT | |
| jds2001 | .fesco 51 | |
| sharkcz | swhiteho: thanks for being here | |
| zodbot | jds2001: #51 (K12Linux - https://fedoraproject.org/wiki/Features/GFS2Stable) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/51 | |
| jds2001 | oops | |
| swhiteho | nirik: 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 | ||
| jds2001 | that link is obviously wrong :) | |
| nirik | swhiteho: ok, but that looks too verbose to me... anyhow, talk to the docs folks. ;) | |
| jds2001 | https://fedoraproject.org/wiki/Features/K12Linux | |
| swhiteho | nirik: will do | |
| nirik | ok, so this was mostly done in f10, but not soon enough to tout? | |
| bpepple | nirik: I believe that was the case. | |
| j-rod | so is this a remix or a spin or ? | |
| jds2001 | warren: you around? | |
| nirik | j-rod: neither. You install the server on a fedora box, then setup thin clients using it. | |
| warren | jds2001: no | |
| jds2001: what's up? | ||
| f13 | this seems like a spin to me | |
| j-rod | nirik: but there's an iso... | |
| jds2001 | the k12linux feature we're discussing now. | |
| is it a spin? | ||
| j-rod | so it can be added to an existing fedora box, but it looks like its also a spin | |
| warren | I 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 | ||
| nirik | I guess it's both. | |
| warren | jds2001: it is both a spin and not a spin. You can install K12Linux on any standard Fedora. | |
| nirik | warren: whats on the iso/spin? | |
| jds2001 | yeah, i guess so. | |
| j-rod | warren: 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 | |
| warren | nirik: 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. | |
| poelcat | warren: i didn't say you "had to"... I asked if you wanted to :) | |
| f13 | warren: are you wanting Fedora to produce a live iso and post it to spins.fp.o ? | |
| warren | f13: Not really. | |
| * nirik points warren at the spins sig/process for that. | ||
| f13 | ok, then I'll happily ignore this | |
| warren | this violates the spin guidelines in several ways. | |
| dgilmore | warren: if you produce an iso. it really should be done the right way | |
| nirik | I think the spin is totally seperate... I was only voting on the feature. | |
| jds2001 | warren: in what ways? | |
| warren | I 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. | ||
| warren | jds2001: Jeroen (sp?) seemed to be very confused by it, I didn't have time to follow up | |
| jds2001 | np | |
| nirik | warren: is anyone taking over for you working on this? or you will just do maint as you can? | |
| warren | nirik: I help in maint, an upstream developer is taking over packaging | |
| nirik | cool. | |
| j-rod | +1 for something in the release notes about Fedora being a great platform for k12linux | |
| warren | what is the deadline to write that blurb? | |
| bpepple | +1 | |
| j-rod | slightly hazy on what's actually *in* Fedora though | |
| warren | j-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-rod | warren: ok, gotcha, I see ltsp-client, ltsp-server in the repos, etc. | |
| so yeah, cool | ||
| and the iso will exist outside the spins domain | ||
| warren | the ISO is only of interest of people wanting to deploy large networks of it, it is a very niche product | |
| j-rod | just has to adhere to the trademark guidelines | |
| where's the iso being hosted? | ||
| warren | j-rod: alt.fedoraproject.org is where mmcgrath said to put it. | |
| j-rod | oh. hrm. | |
| warren | j-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-rod | in that case, it sort of seems like it should be reviewed by *someone* if its going to sit on fedora servers | |
| warren | It is built from 100% fedora packages | |
| dgilmore | warren: as long as you comply with trademark guidelines it can go whereever it goes | |
| warren | right | |
| dgilmore | warren: you need to make sure you sue the generic release etc packages | |
| warren | Is there any actual problem here? otherwise move on. | |
| dgilmore | s/sue/use/ | |
| warren | dgilmore: err, why? | |
| j-rod | but don't spins have to go through a certain process to get officially hosted? | |
| warren | dgilmore: it is 100% Fedora | |
| dgilmore | warren: because thats what the trademark guidelines say | |
| AFAIK anyways | ||
| i could be wrong | ||
| jds2001 | unless you have board approval for the trademark. | |
| warren | dgilmore: 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. | |
| dgilmore | warren: no its if its not an offical spin AFAIK | |
| jds2001 | dgilmore: no, the actual spin needs board approval to use the mark. | |
| dgilmore | jds2001: thats what i thought | |
| jds2001 | you can call it a fedora remix if you like. | |
| warren | remixes contain 100% fedora components? | |
| jds2001 | they can or not. | |
| warren | If I'm understanding correctly, I don't have to change anything, just get the board to approve it? | |
| jds2001 | if that made sense :) | |
| dgilmore | anyways thats another discussion | |
| warren: likely | ||
| warren | I really don't have time to respin and do all the QA tests again. | |
| j-rod | https://fedoraproject.org/wiki/Legal:Trademark_guidelines | |
| warren | anyway, please move on. | |
| * warren reads | ||
| jds2001 | moving right along.... | |
| jds2001 | .fesco 52 | |
| zodbot | jds2001: #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-rod | warren: "Unmodified Fedora software" section looks applicable | |
| jds2001 | +1 here | |
| j-rod | (i.e., just get board approval) | |
| warren | j-rod: the intent was to make K12Linux another Fedora sub-brand | |
| j-rod | +1 to netbeans | |
| warren | j-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-rod | warren: ah, didn't know that. should be trivial to get approval then :) | |
| jds2001 | i see 7 +1's for netbeans, so we've approved the netbeans feature | |
| jds2001 | .fesco 53 | |
| zodbot | jds2001: #53 (New text UI - https://fedoraproject.org/wiki/Features/NewTextUI) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/53 | |
| nirik | text mode has always lacked some things that were available in gui mode... like encrypted disk setup | |
| j-rod | writing everything 2x sucks | |
| jds2001 | yep. and will continue to do so :) | |
| sharkcz | and parts of LVM setup | |
| jds2001 | but yeah, we should detect missing parts of a ks file that we can't prompt for anymore early on. | |
| bpepple | +1 to TextUI feature. | |
| jds2001 | rather than barfing when we get there. | |
| * notting is +1 to the NewSpeak NewTextUI | ||
| j-rod | whoa, 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) | |
| jds2001 | i see five +1's, so we've approved the new text UI. | |
| notting | poelcat: i think we punted cgroups | |
| j-rod | (and can install whatever you want via kickstart) | |
| +1 as well | ||
| jds2001 | .fesco 54 | |
| zodbot | jds2001: #54 (noarch subpackages - https://fedoraproject.org/wiki/Features/NoarchSubpackages) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/54 | |
| * ffesti is there for questions | ||
| nirik | this should land before mass rebuild hopefully? or at the same time? | |
| jds2001 | so i know we're upgrading koji in a bit. forget the exact date | |
| dgilmore | koji support for this will land in just over 2 weeks | |
| 21st feb | ||
| j-rod | +1, been wanting this for ages | |
| bpepple | do we know when the gcc/arch rebuild is happening? | |
| sharkcz | +1 | |
| jds2001 | this requires action from package maintainers, though, right? | |
| notting | is this done by 'built it twice', or is it done automatically? | |
| jds2001 | like to specify the subpackage as noarch | |
| nirik | +1 here | |
| ffesti | Maintainer need to add BuildArch: noarch to the sub packages | |
| dgilmore | jds2001: packahe maintainers will need to modify specs for this | |
| ffesti | and check whether turning the noarch is really ok | |
| nirik | I 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. | |
| ffesti | s/the/them/ | |
| nirik | (once it has landed) | |
| ffesti | this is on the todo list | |
| jds2001 | +1 here. | |
| notting | +1 | |
| bpepple | +1 to NoArchSubpackages. | |
| nirik | ffesti: ah yes. Sorry, read to fast. ;) | |
| ffesti | I just want Fesco's backing before bugging hundreds of package maintainers | |
| jds2001 | bugging them is cool with me :) | |
| ffesti | There will also be requests for changes in Packaging and Review guidlines as soon as I have the texts ready | |
| bpepple | looks like there are six '+1' for this feature. | |
| jds2001 | yep, moving right along. | |
| dgilmore | +1 | |
| jds2001 | .fesco 55 | |
| zodbot | jds2001: #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 | |
| nirik | yeah. +1 here, agree with notting. | |
| jds2001 | yeah, but what's right for you might not be right for me. | |
| j-rod | +1, what notting said | |
| jds2001 | but yeah, reading sucks | |
| pknirsch | ^^ | |
| sharkcz | +1 | |
| jds2001 | i 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 | ||
| jds2001 | anyone 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. ;) | ||
| mitr | StrongerHashes ? | |
| jds2001 | mitr: ahh, right. | |
| jds2001 | mitr: so we were wondering about the feasabiltiy of newer rpm in F9 iirc | |
| j-rod | jds2001: FPC review as well | |
| jds2001 | ouch! | |
| * jds2001 fail. | ||
| mitr | First, I was wrong: preupgrade from F9 to rawhide actually works (because preupgrade does not use rpm) | |
| j-rod | although we've already gone 2hr and $dayjob beckons... | |
| mitr | So, the supported installation path is OK. | |
| mitr | As 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 | ||
| dgilmore | mitr: 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] | |
| mitr | dgilmore: Then I don't know how to make (yum update) work | |
| dgilmore | mitr: have both hases in the rpm | |
| nirik | or defer until f12? | |
| jds2001 | in my mind, it's not a supported upgrade path. Though it is one a lot of people are forced to use. | |
| nirik | well, I guess that doesn't help. nevermind. | |
| mitr | dgilmore: that will almost double the update memory requirement | |
| dgilmore | so that yum update with the old rpm works. and then updates use the newer hashing | |
| jds2001 | nirik: why doesnt it help? | |
| mitr | dgilmore: Also, rpm-4.6.0 with the single hash format was already released. | |
| nirik | jds2001: hum. perhaps it does. We need a rpm that can handle new format, as well as old format. | |
| jds2001 | nirik: right, and 4.6 is in F10. So yum upgrade from oldest supported -> newest works. | |
| dgilmore | mitr: upgrades from F-9 to F-11 need to be supported. | |
| notting | mitr: what does dropping 4.6.0 into f9 break? | |
| dgilmore | mitr: without hacks | |
| mitr | dgilmore: All officially supported installation paths are supported. | |
| dgilmore | mitr: yum updates are officially supported last i looked | |
| its what ive used for years before we supported it | ||
| nirik | well, not sure if they are official or not, but it's not nice to break them IMHO. | |
| mitr | notting: I'm not sure - but IIRC there are incompatibilities at least in the rpmbuild behavior (fuzz, etc.) | |
| notting | that's configurable , though | |
| dgilmore | mitr: fuzz can be configured | |
| mitr | Well, Panu vetoed it. | |
| dgilmore | mitr: we need some way for it to work. or we revert stronger hashes | |
| mitr | dgilmore: 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 | ||
| jds2001 | well that wouldnt be good | |
| no time to update it if it busts the world. | ||
| dgilmore | mitr: not recommended doesnt mean not supported | |
| mitr | dgilmore: 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 | |
| dgilmore | mitr: 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 | ||
| mitr | dgilmore: Well, I didn't expect the (yum update) requirement. | |
| nirik | can 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. | ||
| dgilmore | mitr: i dont believe that for one second | |
| notting | he's not around now, but we probably should | |
| * dgilmore says we need to deffer until Panu is here | ||
| jds2001 | yeah | |
| 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_ | ||
| bpepple | jds2001: definitely. | |
| sharkcz | and FPC | |
| * jds2001 ends the meeting in 5 | ||
| jds2001 | right. | |
| they just had one thing. | ||
| twitter2 | asd | |
| jds2001 | -- MEETING END -- | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!