| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process | ||
| * jwb is here | ||
| bpepple | FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren | |
|---|---|---|
| jwb | on time even! | |
| * tibbs here. | ||
| rdieter | here | |
| * warren here | ||
| spot is here | ||
| abadger1999 here | ||
| nirik is here. | ||
| f13 | present | |
| * jeremy si here | ||
| f13 | si senior | |
| * notting is here | ||
| bpepple | hi, everyone. we've got quite a bit to go over this week so we should probably get started. | |
| --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- License Version - notting, jeremy | ||
| * dgilmore is here | ||
| bpepple | notting, jeremy: want to start off this discussion? | |
| notting | sure | |
| tibbs | FPC had talked about this some time ago and rejected it. | |
| warren | license version? | |
| f13 | we rejected having it in the license field IIRC | |
| tibbs | Yes. | |
| f13 | that doesn't mean we wouldn't be open to managing it in some other file in the SCM | |
| tibbs | Yes. | |
| jwb | good, because having it in the License field sucks | |
| warren | if software is GPLv2 only you don't want that to be known in the License field? why? | |
| jeremy | tibbs: at the same time, the situation around need/wanting to know it is different now | |
| nirik | I wonder, what would be reading/parsing this? We should try and have a solution that makes whatever needs the data easy to get it. | |
| notting | basically, just knowing the license isn't enough. different license versions have different compatibility. while we can't do completely automatic determination of legality from the license tags alone, we want to be able to do a quick best effort | |
| jwb | warren, because packages contain code under multiple licenses | |
| warren | ah | |
| jwb | and what notting said | |
| spot | maybe i'm wrong, but this seems like something that would plug in well to the packagedb | |
| jeremy | spot: except that it changes over time | |
| notting | spot: not when packages change licenses over time | |
| jwb | why is that a problem? | |
| spot | how is the packagedb worse than a static file in CVS for that? | |
| why wouldn't the maintainer be able to update the packagedb for license changes? | ||
| jwb | yeah... | |
| notting | spot: then it's wrong for older releases? | |
| jeremy | jwb: because it's important to be able to know about differences in licensing between F7 and rawhide for example | |
| nirik | so you can see package vwhatever had license GPLv2, since changed to GPLv3, so it can not link with GPLv2 code? | |
| warren | if the software was GPLV2 only | |
| abadger1999 | jeremy: That would be possible. | |
| warren | not GPLV2 "or later" | |
| spot | jeremy: and the packagedb doesn't have releases? | |
| jwb | jeremy, notting: why can't we do it per release? | |
| jeremy | spot: honestly, I don't think a static file in CVS is good. I really think the right place is to make the information in the license tag more verbose (and thus correct) | |
| dgilmore | spot: if it can tag a license/s to a build then the packagedb would be perfect | |
| warren | jeremy, +1 | |
| abadger1999 | The packagedb has an entry for every package::Fedora release. | |
| rdieter | jeremy: +1 | |
| spot | i don't think the static file in CVS is good, but i don't think abusing License: is better | |
| notting | how is changing the license to make it correct abuse? | |
| jeremy | spot: how is it abusing? we're putting what the license is. the fact of the matter is that "GPL" _isn't_ expressive enough | |
| jwb | jeremy, so are you going to make it possible to specify multiple licenses | |
| nirik | do we need data on older package versions, and if so for what? | |
| abadger1999 | jeremy: I agree there. | |
| spot | how do we handle multiple licenses? | |
| notting | spot: GPL2+/LGPL2.1+ | |
| jwb | jeremy, or something like "License: multiple licenses are in here. GPL, BSD, MIT" | |
| tibbs | The same way we handle them now? | |
| f13 | comma seperated list? | |
| notting | or something similar | |
| abadger1999 | spot: How do we handle them now? :-) | |
| spot | abadger1999: we don't really. | |
| notting | pick a delimiter and stick with it | |
| spot | we have lots of packages with invalid License field data | |
| "Distributable" | ||
| jwb | hm | |
| how about this.. | ||
| tibbs | I suppose folks are beginning to understand why I abandoned my effort to clean all of this up. | |
| spot | because its easier than "17 different licenses in one rpm" | |
| warren | "GPLv2 only" is different in compatibility from "GPLv2 or later" | |
| nirik | also, we will need to have a convention for things like 'GPLv2 only' vs 'GPLv2 and newer' in whatever solution. Even tho they are both 'GPLv2' | |
| jeremy | spot: if it's 17 different licenses, then listing them (as much as it sucks) is the right thing to do | |
| spot | the ideal scenario would be some sort of source tree + license mapping | |
| jwb | we could make every package include a copy of all of the licenses it's under | |
| abadger1999 | So if we don't want anything better than now except to specify the version of GPL I think that's fine to do in the License field. If we want something that is actually a better guess then we're in trouble. | |
| spot | jeremy: i'm not sure how much data we can shove in the license field | |
| * jeremy looks | ||
| warren | "GPLv2+"? | |
| jwb | get off the GPL for a sec | |
| * spot has a tentative list of license descriptors that we can standardize on | ||
| spot | thats not a real problem | |
| f13 | I don't think we have a parser for it yet either, so we're not tied by any specific syntax either yet. | |
| * spot wonders if apt-rpm/smart parses License data | ||
| f13 | IIRC they all parse it as just text. By a parser I meant something that would know to look for multiple entries and log them as such | |
| spot | oh. no. | |
| nirik | so what is the problem we are trying to solve here? | |
| rdieter | nirik: GPL3 is incompatible with GPL2, we need to be able to track that. | |
| f13 | nirik: we want to capture what licenses a package actually uses and be able to track those over time, looking for changes. | |
| dgilmore | nirik: incompatabilies that violate licenses | |
| spot | nirik: we need a finer grained mechanism to track licensing in packages | |
| jwb | nirik, we need to track license changes now (particularly the gpl3 stuff) to make sure we aren't breakin the law | |
| nirik | ok, so as a first cut would be good to just identify gplv3 packages? | |
| f13 | gah, now I have a Judas Priest song in my head. | |
| nirik: more specifically (l)gplv2 only packages. | ||
| spot | there are some places where RPM could improve here | |
| jwb | f13, nice my plan worked | |
| spot | say: License(file): foo | |
| notting | argh, bbiasec | |
| spot | in addition to License: bar | |
| jwb | spot, yes! | |
| notting | spot: so you have to explode the rpm to do any query? doubleplusungood. | |
| argh, bbiasec | ||
| spot | no no no | |
| drago01 | License0: foo ... License1: bar .. ect. | |
| spot | this would literally be License(myhardcodedtexthere): foo | |
| jeremy | spot: you're saying you want to mark on a per-file basis with a random string? | |
| spot | if we need to | |
| not for all files | ||
| jeremy | spot: trying to make memory usage worse? :-) | |
| spot | having multiple, but separate license fields (with label identifiers) | |
| jeremy | as a practical matter, the "work" as a whole has to be under a license -- which is what the packaging reflects. and you should be able to do per-subpackage license tags too | |
| jwb | why don't we just have the package include a copy of all licenses it's under again? | |
| spot | that makes a LOT more sense than License: GPL|MPL|BSD|X11|KitchenSink | |
| jeremy | jwb: that's already in the guidelines. but that's nearly impossible to then query | |
| spot | jeremy: and yet, that is not the case. | |
| jwb | jeremy, no, it's not | |
| jeremy, it's a must only if upstream includes it | ||
| spot | (you can do per-subpackage tags, yes) | |
| f13 | jwb: it's still nearly impossible to query | |
| jwb | jeremy, and you can query it just fine if you shove it to a specific location with rpm -qpl | grep location | |
| jeremy | jwb: no, because you have to explode out and read the files | |
| * spot points out that several key infrastructure packages have licensing issues like what I describe. | ||
| dgilmore | spot: what about the cases where different files in the one package have different licenses | |
| jeremy | jwb: everybody includes COPYING. COPYING doesn't imply that you're GPL or whatever | |
| jwb | jeremy, so name them correctly... | |
| jeremy, which is what you'd have to do for License: anyway | ||
| * spot also points out that this should technically be resolved by the FPC | ||
| jwb | spot, yeah those packages are why this makes my head hurt | |
| spot | as this is a packaging issue | |
| f13 | maybe I'm dense here, but why is there such a strong opposition to just picking a standard seperator for multiple licenses and moving forward with that? | |
| notting | if fesco wants to delegate, fine with me. as long as something gets done. | |
| rdieter | f13: +1 | |
| spot | notting: fesco is welcome to tell the FPC what to do here | |
| jwb | f13, i'm not opposed per se... but we'd need a bit more than that | |
| f13 | jwb: why? | |
| bpepple | f13: +1, here also. | |
| nirik | I think fixing everything to use a new scheme before f8t1 is pretty lofty... but I think we can identify gplv3/gplv2 only stuff by them possibly. | |
| abadger1999 | f13: License: GPLv2+ && (LGPLv2+ || MPLv1) | |
| spot | "add guidelines requiring finer granularity for package licensing" | |
| jwb | f13, what abadger1999 just said | |
| dgilmore | lets move on and work out some details later we can ask the FPC to come up with how to do it. lets agree we need it done | |
| f13 | jwb: and what's so wrong with that? | |
| so long as there is a defined syntax? | ||
| abadger1999 | nirik: +1 | |
| jwb | f13, we need to agree on the syntax, the logical operators, and the license names | |
| bpepple | dgilmore: +1, we're not going to resolve this today. | |
| dgilmore | what we need done is a finer grained way to define licenses | |
| lets ask the FPC to work out how | ||
| jwb | f13, not a huge deal, but it could get interested | |
| er, interesting | ||
| abadger1999 | FPC ran into trouble when we started on the license name path. | |
| spot | abadger1999: i'll do it | |
| http://fedoraproject.org/wiki/Licensing is a good start | ||
| jwb | the weird packages will be fun | |
| "GPL v2 + exceptions" | ||
| notting | as a corollary, we probably want to make it absolutely clear and obvious when packages change license | |
| rdieter | notting: +1, definitely | |
| bpepple | notting: agreed. | |
| jwb | notting, yes. | |
| notting | and set some policy about pushing new versions that change licenses | |
| drago01 | notting: changelog entry isn't enough? | |
| dgilmore | notting: indeed we probably dont want license's changing within releases | |
| spot | notting: then you need a database of licenses | |
| warren | Is there an easy way to graph dependencies between packages to see what might be affected by a license change? | |
| spot | and something updating that database and watching for changes | |
| abadger1999 | notting: Do we want the transition point to be queryable? | |
| warren | (Graph build dependencies) | |
| jwb | spot, you mean like a packagedb? | |
| * jwb ducks | ||
| spot | jwb: *gasp* | |
| no, thats crazy!?!? | ||
| f13 | warren: thetango might actually help with that. | |
| notting | abadger1999: maybe, i dunno. more than a changelog | |
| opinions on a "any package that provides a library should not be updated within a release if that update changes the license"? | ||
| abadger1999 | k. Because that sounds impossible to query from the spec file/cvsrepository. | |
| Could be done in a separate file or package DB. | ||
| warren | notting, unless the license becomes more permissive | |
| notting, GPL -> BSD | ||
| dgilmore | notting: +1 to not changing | |
| abadger1999 | Well... Actually... kojiDB/packageDB merge at that point. | |
| spot | notting: i really would prefer not to document all the exception cases | |
| nirik | well, what do you do about security updates? | |
| notting | nirik: you're boned. | |
| bpepple | ok, we should probably move on since we've got plenty of other items on the schedule. Are we going to pass this on to the FPC or do we want to work on this in FESCo? | |
| nirik | +1 to pass off to FPC. ;) | |
| notting | realistically, we even want to be careful about upgrading licenses in rawhide | |
| abadger1999 | Since you're asking what package version did this change in rather than what release did this change in. | |
| warren | hot potato | |
| spot | notting: i think i'd prefer "must notify planet if license changes" | |
| then we can tell people yes or no | ||
| notting | spot: and fesco has the authority to tell people "no, you cannot update. sorry" | |
| spot | notting: sure | |
| * nirik thinks changing licenses is pretty rare. | ||
| abadger1999 | notting, spot: I'm not sure about that.... | |
| notting | nirik: for the past 10 years? yes. for the next year? probably not. :/ | |
| nirik | true. | |
| jwb | nirik, the fun is just beginning | |
| spot | abadger1999: we should be able to document the common cases | |
| abadger1999 | "You must have a plan to deal with apps that can't upgrade to the new version" would be okay. | |
| jwb | i have a feeling it will get even more confusing shortly | |
| spot | and let those either be generally approved or disallowed | |
| tibbs | Looks like we need to get back to those compat- guidelines as well. | |
| * spot sighs | ||
| warren | We really have to move on | |
| bpepple | warren: +1 | |
| moving on..... | ||
| --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Schedule for future branching of CVS - f13 | ||
| notting | ok if i send a mail to -devel-announce saying 'you must announce loudly if your license changes'? | |
| bpepple | notting: +1, sounds fine w/ me. | |
| warren | notting, why not require that they personally check the license of dependent packages for compatibility? | |
| abadger1999 | notting: That's reasonable +1 | |
| tibbs | notting: +1 people should do this anyway. | |
| spot | +1 | |
| jwb | warren, it would be "best guess" mostly | |
| f13 | notting: +1 | |
| warren | notting, how loudly? I believe it would be inappropriate for fedora-devel-announce for example (too much minutiae) | |
| jwb | notting, +1 | |
| bpepple | f13: has the rel-eng team had a chance to discuss when they want to handle branching in the future? | |
| f13 | bpepple: no, this somewhat blindsided me. | |
| bpepple | f13: yeah, I added it to the schedule since it was one of those items we pushed back until after F7. | |
| f13 | bpepple: it really comes down to when packagedb is ready, if it can be used to handle user requested branches or not. | |
| bpepple | f13: ok, I just wanted to touch base with you on this. thanks. | |
| moving on unless anyone objects. | ||
| --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Feature Proposal Approval - http://fedoraproject.org/wiki/Features/Dashboard - notting, poelcat | ||
| bpepple | notting, poelcat: want to lead this? | |
| poelcat | sure | |
| features in top category need FESCo vote | ||
| to move to Approved section of feature list page | ||
| would you like me to present one after the other or ? | ||
| bpepple | poelcat: that sounds good. | |
| poelcat | http://fedoraproject.org/wiki/Releases/Features/NodokaTheme | |
| jwb | wtf happened to Echo? | |
| notting | echo is the icons, this uses that | |
| jeremy | jwb: nodoka is gtk + metacity theme to go with echo (based on reading) | |
| drago01 | jwb: echo =icon theme | |
| jwb | oh, ok. sorry | |
| bpepple | +1, tentatively with Art team ACK. | |
| jeremy | agree with bpepple | |
| spot | +1 with Art Team ACK | |
| notting | +1 w/art ack | |
| nirik | +1 ditto | |
| warren | +1 | |
| jwb | +1 | |
| rdieter | +1 | |
| tibbs | So Fedora has to have its own theme? | |
| I'm sort of confused about why that's necessary. | ||
| jwb | tibbs, have you seen the upstream gnome theme? | |
| it sucks | ||
| bpepple | poelcat: ok, that's eight '+1', so we approve it. With the caveat that the Art team also approves it. | |
| tibbs | So work with upstream to fix it, then? | |
| jwb | tibbs, besides, it's a feature | |
| * notting notes that nodoka isn't really different enough to make that big of a deal | ||
| poelcat | bpepple: got it | |
| nirik | next? | |
| poelcat | http://fedoraproject.org/wiki/Releases/FeatureKDE4 | |
| bpepple | +1 | |
| tibbs | +1 | |
| nirik | +1 | |
| abadger1999 | +1 | |
| rdieter | +1 (biased) | |
| notting | +1. woo, test1-of-flaming-death | |
| spot | +1 | |
| jwb | are we concerned at all with the schedules? | |
| rdieter | notting: :) | |
| * bpepple would hope that rdieter wouldn't vote '-1'. ;) | ||
| jeremy | +1, soundslikefun! | |
| tibbs | The KDE team has repeatedly indicated that the schedule should not be a major issue. | |
| f13 | jwb: we are, but they have until TEst2 to break down. | |
| dgilmore | +1 | |
| f13 | +1 from me. | |
| jeremy | jwb: there's contingency in there for the schedule. and the KDE sig is confident that upstream is going to be to a good place in time. I'm going to trust them :) | |
| jwb | that's 10 votes | |
| move on | ||
| * poelcat will update Releases/8/FeatureList at conclusion of meeting | ||
| poelcat | http://fedoraproject.org/wiki/Releases/FeaturePresto | |
| Kevin_Kofler | We (KDE folks)'re hard at work getting things done in any case. :-) | |
| tibbs | Do we have sufficient infrastructure team buyin for Presto? | |
| dgilmore | tibbs: that im not sure of We are not hindering them | |
| jwb | i want this in test1 in the official repos | |
| that's 5 days from now... | ||
| jeremy | tibbs: there's not really any infrastructure-specific need. build system side, yes | |
| jwb: I don' t think the buildsys pieces are going to be there in the next five days | ||
| f13 | tibbs: we have buildsystem buy in | |
| tibbs | Umm, someone has to store and mirror the content. | |
| * c4chris just pops my head in to say hi! Sitting in another meeting and can't stay: sorry. TTYall later. | ||
| tibbs | That sounds like infrastructure to me. | |
| dgilmore | f13: we do? news to me | |
| f13 | dgilmore: well, koji upstream | |
| spot | +1 to this, assuming all relevant parties ack (infrastructure, whoever) | |
| poelcat | seems like a "dependency" that should be added to the page? | |
| jwb | jeremy, that concerns me | |
| jeremy | tibbs: the bits just land in the trees like anything else | |
| f13 | jwb: not ready by test1 isn't reason to drop a feature. Not ready by test2.. is. | |
| jwb | f13, ah, yes | |
| rdieter | +1 | |
| warren | Are we considering putting diff rpm's in the standard mirror structure? | |
| jeremy | jwb: test2 is the feature freeze. I would have loved to have had by test1, but just couldn't get all the people lined up in time | |
| dgilmore | f13: ok | |
| f13 | +1 | |
| bpepple | +1, agrees w/ spot. | |
| nirik | +1 here | |
| abadger1999 | +1 | |
| warren | Perhaps we could have diff rpm's as a separate mirror module, so mirrmanager can track it separately | |
| jeremy | warren: yes. has to be there | |
| f13 | warren: should be easily --excluded but we don't want yet another rsync module. | |
| jwb | jeremy, do you have a timeframe for when our repos will carry this? | |
| jeremy | warren: that would require substantial changes to the way the plugin side works -- and you'd have to pass to mirror manager whether you had a plugin enabled or not which is core yum changes | |
| warren | ah | |
| * poelcat thinks we should not move to "approved" until ack from relevant parties | ||
| notting | +1 as a feature idea. integration worries me, but... | |
| jeremy | jwb: if we're not doing it by test2, we bail for F8. and we _should_ be there by then | |
| jwb | that wasn't exactly my question, but ok | |
| warren | jeremy, if infrastructure makes the diff rpms, would it use a similar "worthiness" threshold to keep or discard some diff rpms if they don't substantially reduce the download size? | |
| jeremy | warren: yes. otherwise it's just silly :-) | |
| warren | ok cool | |
| +1 | ||
| jwb | poelcat, i agree with what you just said.. | |
| bpepple | poelcat: I agree, we should make sure we get 'ack' from all relevant parties since that seems to be a point of contention here. | |
| * poelcat will handle ACK collection and bring forward again next week | ||
| poelcat | or do over mailing list | |
| bpepple | poelcat: thanks. | |
| warren | How much time will it add to the package pushing process to do this? | |
| f13 | warren: hopefully not much as the buildsystem would pre-generate the diffs | |
| deltas that is. | ||
| warren: it would just be some extra bits of data to gather up while mashing. | ||
| bpepple | poelcat: we should probably move on to the next feature. | |
| poelcat | Next feature is: http://fedoraproject.org/wiki/Releases/FeatureRsyslog; On Deck Circle: http://fedoraproject.org/wiki/Releases/FeatureNoMoreXFS | |
| jwb | the rsyslog one is annoying | |
| it's already done | ||
| notting | +1 | |
| spot | +1 | |
| notting | jwb: that's the problem. our process is behind. | |
| bpepple | +1 | |
| tibbs | +1 | |
| rdieter | +1 | |
| jeremy | +1 | |
| abadger1999 | +1 | |
| jwb | notting, yeah. was a comment on lack of following the process, not the feature | |
| dgilmore | +1 | |
| jwb | anyway, +1 | |
| warren | +1 | |
| nirik | +1 on noxfs | |
| poelcat | next feature: http://fedoraproject.org/wiki/Releases/FeatureNoMoreXFS; on deck: http://fedoraproject.org/wiki/Releases/FeatureXULRunner | |
| spot | diediediediedieXFS | |
| jwb | +1 | |
| notting | +1 | |
| bpepple | +1 to noxfs. | |
| spot | +100 | |
| jeremy | also pretty much in place already... +1 | |
| f13 | +1 | |
| warren | yes! +1 | |
| tibbs | +1 | |
| Finally. | ||
| abadger1999 | +1 | |
| nirik | +1 xulrunner... should we be trying to make sure OLPC and fedora use the same setup? Might be nice for sharing... | |
| rdieter | +1 | |
| tibbs | But core fonts still work OK with XFS gone, don't they:? | |
| * drago01 doubt that it will be ready in time (firefox3) | ||
| notting | tibbs: yes | |
| jeremy | tibbs: yes | |
| notting | jeremy: lots of font packages need fixed :/ | |
| drago01 | or does it work with firefox 2.x too? | |
| f13 | nirik: Fedora ff maintainer is heavily involved with the xulrunner that OLPC is using. | |
| jeremy | can we stick to only discussing one feature at a time? | |
| dgilmore | +1 | |
| bpepple | jeremy: +1 | |
| f13 | jeremy: how timely. Somebody just asked about delta-rpms on mirror-list-d | |
| * warren wonders, do we have a font package naming standard? | ||
| nirik | so where are we? rsyslog passed, noxfs passed, xulrunner? | |
| warren | notting, will the "fixed" font packages continue to work on pre-no-XFS? | |
| bpepple | we finished noxfs, and xulrunner is next. | |
| poelcat | next feature: http://fedoraproject.org/wiki/Releases/FeatureXULRunner; on deck: http://fedoraproject.org/wiki/Releases/FeatureBluetooth | |
| bpepple | +1. | |
| jwb | +1 | |
| dgilmore | +1 | |
| f13 | +1 | |
| notting | +1 | |
| abadger1999 | +1 | |
| warren | +1 | |
| * poelcat is adding "on deck" so people can read ahead (hopefully speeding up process) | ||
| jeremy | xulrunner +1 | |
| drago01 | does it work with firefox 2.x? or does this mean shipping a beta in f8? | |
| notting | warren: no | |
| spot | +1, although I agree with OLPC sync | |
| notting | warren: well, not exactly | |
| * bpepple actually had time to read the feature list before the meeting. | ||
| rdieter | +1 | |
| tibbs | That's a ton of packages to fix. | |
| warren | drago01, IIRC, other distros have already begun to ship xulrunner | |
| drago01 | warren: ok, than its ok | |
| jeremy | spot: the feature actually says starting with the packages that are currently in the OLPC branch | |
| f13 | tibbs: far smaller number than some of the other things we've changed. | |
| nirik | +1 on xulrunner. | |
| spot | jeremy: good | |
| tibbs | But the packages are more complicated. | |
| This isn't just a bunch of easy-to-fix perl modules. | ||
| f13 | tibbs: I'm not talking about easy to fix stuff either. | |
| * nirik is confused by 'next' and 'on deck'... to me 'on deck' means the current one, and next is after that.. but might be I just need more coffee. | ||
| jwb | i have to go. +1 to bluetooth from me | |
| f13 | and they really shouldn't be that hard to fix, or else xulrunner didn't live up to expectations. | |
| * jwb & | ||
| poelcat | last feature for today: http://fedoraproject.org/wiki/Releases/FeatureBluetooth | |
| f13 | +1 | |
| notting | +1 | |
| bpepple | +1 | |
| abadger1999 | +1 | |
| jeremy | tibbs: if we're against doing things because they require effort/work, then we might never try to do anything | |
| rdieter | nirik: not a baseball fan? :) | |
| +1 | ||
| warren | +1 | |
| tibbs | jeremy: Where did you get that I was against this? | |
| f13 | poelcat: are you going to push these "grandfathered" in features to produce rollback plans and enduser impact statements? | |
| tibbs | The bluetooth feature seems awfully gnome-specific to me. | |
| nirik | +1 on bluetooth. I wish sco-flowcontrol patch was in, and I would submit my headset packages. | |
| poelcat | f13: that was one question I had for fesco | |
| f13 | tibbs: and? | |
| tibbs | And, it shouldn't be. | |
| poelcat | f13: how tough do you guys want me to be? :) | |
| nirik | rdieter: not really. | |
| dgilmore | tibbs: thats my main concern with bluetooth is that its too gnome specific | |
| wwoods | that's not really a reason *not* to add bluetooth support | |
| jeremy | my bigger problem with the bluetooth one as it stands is that I think that it's actually more than one feature | |
| tibbs | It's a reason to say "why didn't you talk to KDE people". | |
| dgilmore | its not a reason not to do it | |
| warren | bluetooth will be on-going improvement, and it isn't a big deal if part of it misses the release. | |
| abadger1999 | poelcat: Some of these seem mostly done... I wouldn't push them to have a rollback plan. | |
| rdieter | tibbs: I'll ping the kdebluetooth maintainer to see if they can weigh-in on the feature too. | |
| dgilmore | but it makes for two very different experiences. and im sure KDE will catch up | |
| Kevin_Kofler | There's no way we Fedora KDE folks can implement all this stuff in KDE ourselves anyway! | |
| abadger1999 | Ones that aren't complete should have one. | |
| Kevin_Kofler | All this is upstream stuff. | |
| f13 | and a lot of it is upstream /gnome/ stuff. | |
| wwoods | sure, there should be a note about talking to KDE folks about matching support, but it doesn't *lessen* the user experience for KDE | |
| f13 | look, we can't nack every feature if it doesn't duplicate the work across every desktop environment we have. | |
| bpepple | f13: +1 | |
| tibbs | We haven't nacked any features at this point. | |
| poelcat | abadger1999: that was my thought too, but I wanted to make sure most people were cool w/ that | |
| Kevin_Kofler | A lot of a "Fedora" feature being upstream GNOME stuff isn't a first. :-( | |
| bpepple | poelcat: seems reasonable to me. | |
| f13 | Kevin_Kofler: we're taking a page from Ubuntu here | |
| Kevin_Kofler: because if we don't talk about this and that feature going /into/ Fedora, Ubuntu certainly will, and take all the credit for it. | ||
| tibbs | It's getting annoying being blasted for asking basic questions that aren't answered by these feature documents. | |
| notting | ? we're working in upstream, not outside of it | |
| jeremy | Kevin_Kofler: one of the goals with the feature process, though, is so that we actually tell about the crap we're doing upstream and say "hey, look at what we did". because otherwise, someone else pulls it in and gets all the kudos | |
| f13 | Kevin_Kofler: these aren't always the features that /fedora/ is doing, it's also features that are landing /in/ Fedora. | |
| dgilmore | f13: im not sujesting naking it but just would like to have a message go to rdieter and the KDE SIG to say gnome is gonna get this can you find some people to help kde get something the same | |
| f13 | Kevin_Kofler: certainly you're not claming that /fedora/ is doing all the kde4 work right...? | |
| rdieter | hee | |
| dgilmore | rdieter: so think you can round up some folks to help with kde bits :) | |
| notting | back to the feature, i see 7 +1, and no -1? | |
| Kevin_Kofler | But we're not submitting 30 FeatureXYZ for every single new feature in KDE 4. ;-) | |
| Hint: There are many! | ||
| jeremy | +1 | |
| dgilmore | +1 | |
| notting | ou wait, 8 +1 | |
| f13 | +1 | |
| oh wait, I already +1'd it | ||
| poelcat | how do folks feel about the feature process so far? is there anything I can that would be more helpful? | |
| dgilmore | so bluetooth is acked | |
| notting | poelcat: can we move some of this to the mailing list for new ones that get approval requested? | |
| or do people want to do this in the meeting every week? | ||
| wwoods | FeatureApport is listed as "not complete" but there's no feedback on what it's missing | |
| abadger1999 | notting: +1 to ml. | |
| bpepple | notting: yeah, that might be a good idea since we are doing this sort of late in the game. | |
| abadger1999 | This is supposed to be largely rubber stamp. | |
| drago01 | wwoods: and tickless is done | |
| wwoods | so what's the plan for giving feature proposers (e.g. me) feedback on what their feature proposal lacks? | |
| drago01: yeah, true | ||
| poelcat | wwoods: I could add something to the bottom of the page | |
| wwoods: i think you copied the old version and some of the sections were empty | ||
| in the new version | ||
| wwoods | huh. didn't know there was a new version. | |
| poelcat | http://fedoraproject.org/wiki/Features/Policy has been out for a few weeks | |
| abadger1999 | poelcat: That would be appreciated. I was reading some of the other entries in "not quite ready" and didn't know what they lacked. | |
| poelcat | abadger1999: okay; will do | |
| notting | poelcat: possible even e-mail the feature owners, if there is one listed ;) | |
| poelcat | wwoods: http://fedoraproject.org/wiki/Features/EmptyTemplate | |
| wwoods | the feature template is 9 days old | |
| i'll add some more sections | ||
| poelcat | wwoods: sorry s/few weeks/9 days :) | |
| bpepple | poelcat: anything else? or should we start to wrap up the meeting? | |
| poelcat | that is all from me | |
| bpepple | poelcat: thanks. | |
| --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
| kwizart | About Firewire (juju) - From Fedora Core 6 Test Update: kernel-2.6.22.1-15.fc6 on Fedora-kernel-list mailing list, Chuck Ebbert just confirmed that "Another kernel is building now with the old stack instead of the new one. It also has the libata combined mode option restored." - So this should be the default for FC-6 until EOL ?! | |
| notting | yes. do not break userspace in updates if at all possible | |
| bpepple | notting: +1 | |
| nirik | FYI, I am heading out for a vacation tomorrow until the following saturday... I might have some net, not sure yet. If anyone needs to poke any of my packages or the like, feel free. I won't be able to do cvsadmin stuff probibly. ;) | |
| warren | kwizart, old stack? | |
| oh | ||
| tibbs | The old firewire stack, I guess. | |
| abadger1999 | nirik: Ah... You'll miss the massive breakage when I introduce the package db to cvsadmins :-) | |
| bpepple | nirik: have you added yourself to the vacation page on the wiki? | |
| tibbs | kwizart: I'm not sure if I understand what you're asking. | |
| kwizart | the new is the juju stack with hit FC-6... That was the problem, see https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00843.html | |
| nirik | abadger1999: bummer. Oh well, I might have net... if I do, I'll be happy to assist | |
| bpepple: yep. | ||
| G | tibbs: i think kwizart wants us to have a 2.6.22 kernel for FC6 | |
| tibbs | And we will, but without the new firewire stack. | |
| So what's the question? | ||
| kwizart | G, if possible, yes - but not with juju | |
| tibbs | Whatever "juju" is. | |
| kwizart | as notting suggest (+1) there will be no more question... | |
| abadger1999 | nirik: Don't worry about it. Just expect everything to need further tweaking when you get back. | |
| nirik | abadger1999: when is the packagedb landing scheduled for? | |
| abadger1999 | I finished up the koji sync script. Only a pkgdb CLI client for cvsadmins to add and update remains. | |
| Half done with that. | ||
| bpepple | abadger1999: cool. | |
| ok, is there anything else? Or should we call it quits for today? | ||
| Kevin_Kofler | tibbs: "juju" is the new Firewire stack in recent kernels. | |
| f13 | bpepple: well, I've got one thing. | |
| bpepple | f13: shoot. | |
| f13 | bpepple: I sent an announcement out about the freeze coming up, and rel-eng had decided previously that before the freeze we'd start cracking down on the broken deps/upgradepaths/etc.. problems in rawhide. | |
| f13 | so we're going to start fixing things ourselves and updating people's packages. | |
| just giving FESCo a (re)heads-up | ||
| notting | f13: ooh, bastard mode. | |
| G | *gasp* | |
| bpepple | f13: sounds fine with me. | |
| f13 | notting: pretty much, yeah | |
| G | f13: and a very good job releng does as well btw, out of interest, the freeze will be for test1 right? | |
| tibbs | A lot of the upgrade paths can be fixed just by pushing updates through bodhi. | |
| nirik | sounds good... although you might also ping maintainers directly again... | |
| tibbs | People still aren't understanding that they need to do that. | |
| ixs | f13: the problems you will be working on are the ones in the normal dependency report which is mailed out tot the maintainers list, right? | |
| f13 | ixs: yes, and any others we find. | |
| drago01 | f13: seems like (almost) all of thge | |
| m just need a rebuild | ||
| f13 | tibbs: I'm mostly talking about the paths from say 7 -> devel | |
| or 6 -> devel | ||
| 6 -> 7 I'm not dealing with right now. | ||
| bpepple | ok, anything else? | |
| * bpepple will end the meeting in 60 | ||
| bpepple will end the meeting in 30 | ||
| bpepple will end the meeting in 15 | ||
| bpepple | -- MARK -- Meeting End | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!