FESCo Meeting 2007-07-19

--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
* jwb is here
bpeppleFESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren
jwbon time even!
* tibbs here.
* warren here
spot is here
abadger1999 here
nirik is here.
* jeremy si here
f13si senior
* notting is here
bpepplehi, 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
bpepplenotting, jeremy: want to start off this discussion?
tibbsFPC had talked about this some time ago and rejected it.
warrenlicense version?
f13we rejected having it in the license field IIRC
f13that doesn't mean we wouldn't be open to managing it in some other file in the SCM
jwbgood, because having it in the License field sucks
warrenif software is GPLv2 only you don't want that to be known in the License field?  why?
jeremytibbs: at the same time, the situation around need/wanting to know it is different now
nirikI wonder, what would be reading/parsing this? We should try and have a solution that makes whatever needs the data easy to get it.
nottingbasically, 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
jwbwarren, because packages contain code under multiple licenses
jwband what notting said
spotmaybe i'm wrong, but this seems like something that would plug in well to the packagedb
jeremyspot: except that it changes over time
nottingspot: not when packages change licenses over time
jwbwhy is that a problem?
spothow 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?
nottingspot: then it's wrong for older releases?
jeremyjwb: because it's important to be able to know about differences in licensing between F7 and rawhide for example
nirikso you can see package vwhatever had license GPLv2, since changed to GPLv3, so it can not link with GPLv2 code?
warrenif the software was GPLV2 only
abadger1999jeremy: That would be possible.
warrennot GPLV2 "or later"
spotjeremy: and the packagedb doesn't have releases?
jwbjeremy, notting: why can't we do it per release?
jeremyspot: 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)
dgilmorespot: if it can tag a license/s to a build then the packagedb would be perfect
warrenjeremy, +1
abadger1999The packagedb has an entry for every package::Fedora release.
rdieterjeremy: +1
spoti don't think the static file in CVS is good, but i don't think abusing License: is better
nottinghow is changing the license to make it correct abuse?
jeremyspot: how is it abusing?  we're putting what the license is.  the fact of the matter is that "GPL" _isn't_ expressive enough
jwbjeremy, so are you going to make it possible to specify multiple licenses
nirikdo we need data on older package versions, and if so for what?
abadger1999jeremy: I agree there.
spothow do we handle multiple licenses?
nottingspot: GPL2+/LGPL2.1+
jwbjeremy, or something like "License: multiple licenses are in here.  GPL, BSD, MIT"
tibbsThe same way we handle them now?
f13comma seperated list?
nottingor something similar
abadger1999spot: How do we handle them now? :-)
spotabadger1999: we don't really.
nottingpick a delimiter and stick with it
spotwe have lots of packages with invalid License field data
how about this..
tibbsI suppose folks are beginning to understand why I abandoned my effort to clean all of this up.
spotbecause its easier than "17 different licenses in one rpm"
warren"GPLv2 only" is different in compatibility from "GPLv2 or later"
nirikalso, 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'
jeremyspot: if it's 17 different licenses, then listing them (as much as it sucks) is the right thing to do
spotthe ideal scenario would be some sort of source tree + license mapping
jwbwe could make every package include a copy of all of the licenses it's under
abadger1999So 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.
spotjeremy: i'm not sure how much data we can shove in the license field
* jeremy looks
jwbget off the GPL for a sec
* spot has a tentative list of license descriptors that we can standardize on
spotthats not a real problem
f13I 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
f13IIRC 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
spotoh. no.
nirikso what is the problem we are trying to solve here?
rdieternirik: GPL3 is incompatible with GPL2, we need to be able to track that.
f13nirik: we want to capture what licenses a package actually uses and be able to track those over time, looking for changes.
dgilmorenirik: incompatabilies that violate licenses
spotnirik: we need a finer grained mechanism to track licensing in packages
jwbnirik, we need to track license changes now (particularly the gpl3 stuff) to make sure we aren't breakin the law
nirikok, so as a first cut would be good to just identify gplv3 packages?
f13gah, now I have a Judas Priest song in my head.
nirik: more specifically (l)gplv2 only packages.
spotthere are some places where RPM could improve here
jwbf13, nice my plan worked
spotsay: License(file): foo
nottingargh, bbiasec
spotin addition to License: bar
jwbspot, yes!
nottingspot: so you have to explode the rpm to do any query? doubleplusungood.
argh, bbiasec
spotno no no
drago01License0: foo ... License1: bar .. ect.
spotthis would literally be License(myhardcodedtexthere): foo
jeremyspot: you're saying you want to mark on a per-file basis with a random string?
spotif we need to
not for all files
jeremyspot: trying to make memory usage worse? :-)
spothaving multiple, but separate license fields (with label identifiers)
jeremyas 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
jwbwhy don't we just have the package include a copy of all licenses it's under again?
spotthat makes a LOT more sense than License: GPL|MPL|BSD|X11|KitchenSink
jeremyjwb: that's already in the guidelines.  but that's nearly impossible to then query
spotjeremy: and yet, that is not the case.
jwbjeremy, no, it's not
jeremy, it's a must only if upstream includes it
spot(you can do per-subpackage tags, yes)
f13jwb: it's still nearly impossible to query
jwbjeremy, and you can query it just fine if you shove it to a specific location with rpm -qpl | grep location
jeremyjwb: 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.
dgilmorespot: what about the cases where different files in the one package have different licenses
jeremyjwb: everybody includes COPYING.  COPYING doesn't imply that you're GPL or whatever
jwbjeremy, 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
jwbspot, yeah those packages are why this makes my head hurt
spotas this is a packaging issue
f13maybe 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?
nottingif fesco wants to delegate, fine with me. as long as something gets done.
rdieterf13: +1
spotnotting: fesco is welcome to tell the FPC what to do here
jwbf13, i'm not opposed per se... but we'd need a bit more than that
f13jwb: why?
bpepplef13: +1, here also.
nirikI 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.
abadger1999f13: License: GPLv2+ && (LGPLv2+ || MPLv1)
spot"add guidelines requiring finer granularity for package licensing"
jwbf13, what abadger1999 just said
dgilmorelets 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
f13jwb: and what's so wrong with that?
so long as there is a defined syntax?
abadger1999nirik: +1
jwbf13, we need to agree on the syntax, the logical operators, and the license names
bpeppledgilmore: +1, we're not going to resolve this today.
dgilmorewhat we need done is a finer grained way to define licenses
lets ask the FPC to work out how
jwbf13, not a huge deal, but it could get interested
er, interesting
abadger1999FPC ran into trouble when we started on the license name path.
spotabadger1999: i'll do it
http://fedoraproject.org/wiki/Licensing is a good start
jwbthe weird packages will be fun
"GPL v2 + exceptions"
nottingas a corollary, we probably want to make it absolutely clear and obvious when packages change license
rdieternotting: +1, definitely
bpepplenotting: agreed.
jwbnotting, yes.
nottingand set some policy about pushing new versions that change licenses
drago01notting: changelog entry isn't enough?
dgilmorenotting: indeed  we probably dont want license's changing within releases
spotnotting: then you need a database of licenses
warrenIs there an easy way to graph dependencies between packages to see what might be affected by a license change?
spotand something updating that database and watching for changes
abadger1999notting: Do we want the transition point to be queryable?
warren(Graph build dependencies)
jwbspot, you mean like a packagedb?
* jwb ducks
spotjwb: *gasp*
no, thats crazy!?!?
f13warren: thetango might actually help with that.
nottingabadger1999: 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"?
abadger1999k. Because that sounds impossible to query from the spec file/cvsrepository.
Could be done in a separate file or package DB.
warrennotting, unless the license becomes more permissive
notting, GPL -> BSD
dgilmorenotting: +1  to not changing
abadger1999Well... Actually... kojiDB/packageDB merge at that point.
spotnotting: i really would prefer not to document all the exception cases
nirikwell, what do you do about security updates?
nottingnirik: you're boned.
bpeppleok, 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. ;)
nottingrealistically, we even want to be careful about upgrading licenses in rawhide
abadger1999Since you're asking what package version did this change in rather than what release did this change in.
warrenhot potato
spotnotting: i think i'd prefer "must notify planet if license changes"
then we can tell people yes or no
nottingspot: and fesco has the authority to tell people "no, you cannot update. sorry"
spotnotting: sure
* nirik thinks changing licenses is pretty rare.
abadger1999notting, spot: I'm not sure about that....
nottingnirik: for the past 10 years? yes. for the next year? probably not. :/
jwbnirik, the fun is just beginning
spotabadger1999: 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.
jwbi have a feeling it will get even more confusing shortly
spotand let those either be generally approved or disallowed
tibbsLooks like we need to get back to those compat- guidelines as well.
* spot sighs
warrenWe really have to move on
bpepplewarren: +1
moving on.....
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Schedule for future branching of CVS - f13
nottingok if i send a mail to -devel-announce saying 'you must announce loudly if your license changes'?
bpepplenotting: +1, sounds fine w/ me.
warrennotting, why not require that they personally check the license of dependent packages for compatibility?
abadger1999notting: That's reasonable +1
tibbsnotting: +1 people should do this anyway.
jwbwarren, it would be "best guess" mostly
f13notting: +1
warrennotting, how loudly?  I believe it would be inappropriate for fedora-devel-announce for example (too much minutiae)
jwbnotting, +1
bpepplef13: has the rel-eng team had a chance to discuss when they want to handle branching in the future?
f13bpepple: no, this somewhat blindsided me.
bpepplef13: yeah, I added it to the schedule since it was one of those items we pushed back until after F7.
f13bpepple: it really comes down to when packagedb is ready, if it can be used to handle user requested branches or not.
bpepplef13: 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
bpepplenotting, poelcat: want to lead this?
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 ?
bpepplepoelcat: that sounds good.
jwbwtf happened to Echo?
nottingecho is the icons, this uses that
jeremyjwb: nodoka is gtk + metacity theme to go with echo (based on reading)
drago01jwb: echo =icon theme
jwboh, ok.  sorry
bpepple+1, tentatively with Art team ACK.
jeremyagree with bpepple
spot+1 with Art Team ACK
notting+1 w/art ack
nirik+1 ditto
tibbsSo Fedora has to have its own theme?
I'm sort of confused about why that's necessary.
jwbtibbs, have you seen the upstream gnome theme?
it sucks
bpepplepoelcat: ok, that's eight '+1', so we approve it.  With the caveat that the Art team also approves it.
tibbsSo work with upstream to fix it, then?
jwbtibbs, besides, it's a feature
* notting notes that nodoka isn't really different enough to make that big of a deal
poelcatbpepple: got it
rdieter+1 (biased)
notting+1. woo, test1-of-flaming-death
jwbare we concerned at all with the schedules?
rdieternotting: :)
* bpepple would hope that rdieter wouldn't vote '-1'. ;)
jeremy+1, soundslikefun!
tibbsThe KDE team has repeatedly indicated that the schedule should not be a major issue.
f13jwb: we are, but they have until TEst2 to break down.
f13+1 from me.
jeremyjwb: 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 :)
jwbthat's 10 votes
move on
* poelcat will update Releases/8/FeatureList at conclusion of meeting
Kevin_KoflerWe (KDE folks)'re hard at work getting things done in any case. :-)
tibbsDo we have sufficient infrastructure team buyin for Presto?
dgilmoretibbs: that im not sure of  We are not hindering them
jwbi want this in test1 in the official repos
that's 5 days from now...
jeremytibbs: 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
f13tibbs: we have buildsystem buy in
tibbsUmm, 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.
tibbsThat sounds like infrastructure to me.
dgilmoref13: we do?  news to me
f13dgilmore: well, koji upstream
spot+1 to this, assuming all relevant parties ack (infrastructure, whoever)
poelcatseems like a "dependency" that should be added to the page?
jwbjeremy, that concerns me
jeremytibbs: the bits just land in the trees like anything else
f13jwb: not ready by test1 isn't reason to drop a feature.  Not ready by test2.. is.
jwbf13, ah, yes
warrenAre we considering putting diff rpm's in the standard mirror structure?
jeremyjwb: 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
dgilmoref13: ok
bpepple+1, agrees w/ spot.
nirik+1 here
warrenPerhaps we could have diff rpm's as a separate mirror module, so mirrmanager can track it separately
jeremywarren: yes.  has to be there
f13warren: should be easily --excluded but we don't want yet another rsync module.
jwbjeremy, do you have a timeframe for when our repos will carry this?
jeremywarren: 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
* poelcat thinks we should not move to "approved" until ack from relevant parties
notting+1 as a feature idea. integration worries me, but...
jeremyjwb: if we're not doing it by test2, we bail for F8.  and we _should_ be there by then
jwbthat wasn't exactly my question, but ok
warrenjeremy, 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?
jeremywarren: yes.  otherwise it's just silly :-)
warrenok cool
jwbpoelcat, i agree with what you just said..
bpepplepoelcat: 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
poelcator do over mailing list
bpepplepoelcat: thanks.
warrenHow much time will it add to the package pushing process to do this?
f13warren: 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.
bpepplepoelcat: we should probably move on to the next feature.
poelcatNext feature is: http://fedoraproject.org/wiki/Releases/FeatureRsyslog; On Deck Circle: http://fedoraproject.org/wiki/Releases/FeatureNoMoreXFS
jwbthe rsyslog one is annoying
it's already done
nottingjwb: that's the problem. our process is behind.
jwbnotting, yeah.  was a comment on lack of following the process, not the feature
jwbanyway, +1
nirik+1 on noxfs
poelcatnext feature: http://fedoraproject.org/wiki/Releases/FeatureNoMoreXFS; on deck: http://fedoraproject.org/wiki/Releases/FeatureXULRunner
bpepple+1 to noxfs.
jeremyalso pretty much in place already... +1
warrenyes! +1
nirik+1 xulrunner... should we be trying to make sure OLPC and fedora use the same setup? Might be nice for sharing...
tibbsBut core fonts still work OK with XFS gone, don't they:?
* drago01 doubt that it will be ready in time (firefox3)
nottingtibbs: yes
jeremytibbs: yes
nottingjeremy: lots of font packages need fixed :/
drago01or does it work with firefox 2.x too?
f13nirik: Fedora ff maintainer is heavily involved with the xulrunner that OLPC is using.
jeremycan we stick to only discussing one feature at a time?
bpepplejeremy: +1
f13jeremy: how timely.  Somebody just asked about delta-rpms on mirror-list-d
* warren wonders, do we have a font package naming standard?
nirikso where are we? rsyslog passed, noxfs passed, xulrunner?
warrennotting, will the "fixed" font packages continue to work on pre-no-XFS?
bpepplewe finished noxfs, and xulrunner is next.
poelcatnext feature: http://fedoraproject.org/wiki/Releases/FeatureXULRunner; on deck: http://fedoraproject.org/wiki/Releases/FeatureBluetooth
* poelcat is adding "on deck" so people can read ahead (hopefully speeding up process)
jeremyxulrunner +1
drago01does it work with firefox 2.x? or does this mean shipping a beta in f8?
nottingwarren: no
spot+1, although I agree with OLPC sync
nottingwarren: well, not exactly
* bpepple actually had time to read the feature list before the meeting.
tibbsThat's a ton of packages to fix.
warrendrago01, IIRC, other distros have already begun to ship xulrunner
drago01warren: ok, than its ok
jeremyspot: the feature actually says starting with the packages that are currently in the OLPC branch
f13tibbs: far smaller number than some of the other things we've changed.
nirik+1 on xulrunner.
spotjeremy: good
tibbsBut the packages are more complicated.
This isn't just a bunch of easy-to-fix perl modules.
f13tibbs: 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.
jwbi have to go.  +1 to bluetooth from me
f13and they really shouldn't be that hard to fix, or else xulrunner didn't live up to expectations.
* jwb &
poelcatlast feature for today: http://fedoraproject.org/wiki/Releases/FeatureBluetooth
jeremytibbs: if we're against doing things because they require effort/work, then we might never try to do anything
rdieternirik: not a baseball fan? :)
tibbsjeremy: Where did you get that I was against this?
f13poelcat: are you going to push these "grandfathered" in features to produce rollback plans and enduser impact statements?
tibbsThe 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.
poelcatf13: that was one question I had for fesco
f13tibbs: and?
tibbsAnd, it shouldn't be.
poelcatf13: how tough do you guys want me to be? :)
nirikrdieter: not really.
dgilmoretibbs: thats my main concern with bluetooth is that its too gnome specific
wwoodsthat's not really a reason *not* to add bluetooth support
jeremymy bigger problem with the bluetooth one as it stands is that I think that it's actually more than one feature
tibbsIt's a reason to say "why didn't you talk to KDE people".
dgilmoreits not a reason not to do it
warrenbluetooth will be on-going improvement, and it isn't a big deal if part of it misses the release.
abadger1999poelcat: Some of these seem mostly done... I wouldn't push them to have a rollback plan.
rdietertibbs: I'll ping the kdebluetooth maintainer to see if they can weigh-in on the feature too.
dgilmorebut it makes for two very different experiences.  and im sure KDE will catch up
Kevin_KoflerThere's no way we Fedora KDE folks can implement all this stuff in KDE ourselves anyway!
abadger1999Ones that aren't complete should have one.
Kevin_KoflerAll this is upstream stuff.
f13and a lot of it is upstream /gnome/ stuff.
wwoodssure, there should be a note about talking to KDE folks about matching support, but it doesn't *lessen* the user experience for KDE
f13look, we can't nack every feature if it doesn't duplicate the work across every desktop environment we have.
bpepplef13: +1
tibbsWe haven't nacked any features at this point.
poelcatabadger1999: that was my thought too, but I wanted to make sure most people were cool w/ that
Kevin_KoflerA lot of a "Fedora" feature being upstream GNOME stuff isn't a first. :-(
bpepplepoelcat: seems reasonable to me.
f13Kevin_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.
tibbsIt'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
jeremyKevin_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
f13Kevin_Kofler: these aren't always the features that /fedora/ is doing, it's also features that are landing /in/ Fedora.
dgilmoref13: 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
f13Kevin_Kofler: certainly you're not claming that /fedora/ is doing all the kde4 work right...?
dgilmorerdieter: so think you can round up some folks to help with kde bits :)
nottingback to the feature, i see 7 +1, and no -1?
Kevin_KoflerBut we're not submitting 30 FeatureXYZ for every single new feature in KDE 4. ;-)
Hint: There are many!
nottingou wait, 8 +1
oh wait, I already +1'd it
poelcathow do folks feel about the feature process so far? is there anything I can that would be more helpful?
dgilmoreso bluetooth is acked
nottingpoelcat: 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?
wwoodsFeatureApport is listed as "not complete" but there's no feedback on what it's missing
abadger1999notting: +1 to ml.
bpepplenotting: yeah, that might be a good idea since we are doing this sort of late in the game.
abadger1999This is supposed to be largely rubber stamp.
drago01wwoods: and tickless is done
wwoodsso what's the plan for giving feature proposers (e.g. me) feedback on what their feature proposal lacks?
drago01: yeah, true
poelcatwwoods: 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
wwoodshuh. didn't know there was a new version.
poelcathttp://fedoraproject.org/wiki/Features/Policy has been out for a few weeks
abadger1999poelcat: That would be appreciated.  I was reading some of the other entries in "not quite ready" and didn't know what they lacked.
poelcatabadger1999: okay; will do
nottingpoelcat: possible even e-mail the feature owners, if there is one listed ;)
poelcatwwoods: http://fedoraproject.org/wiki/Features/EmptyTemplate
wwoodsthe feature template is 9 days old
i'll add some more sections
poelcatwwoods: sorry s/few weeks/9 days :)
bpepplepoelcat: anything else? or should we start to wrap up the meeting?
poelcatthat is all from me
bpepplepoelcat: thanks.
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
kwizartAbout Firewire (juju) - From Fedora Core 6 Test Update: kernel- 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 ?!
nottingyes. do not break userspace in updates if at all possible
bpepplenotting: +1
nirikFYI, 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. ;)
warrenkwizart, old stack?
tibbsThe old firewire stack, I guess.
abadger1999nirik: Ah... You'll miss the massive breakage when I introduce the package db to cvsadmins :-)
bpepplenirik: have you added yourself to the vacation page on the wiki?
tibbskwizart: I'm not sure if I understand what you're asking.
kwizartthe 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
nirikabadger1999: bummer. Oh well, I might have net... if I do, I'll be happy to assist
bpepple: yep.
Gtibbs: i think kwizart wants us to have a 2.6.22 kernel for FC6
tibbsAnd we will, but without the new firewire stack.
So what's the question?
kwizartG, if possible, yes -  but not with juju
tibbsWhatever "juju" is.
kwizartas notting suggest (+1) there will be no more question...
abadger1999nirik: Don't worry about it.  Just expect everything to need further tweaking when you get back.
nirikabadger1999: when is the packagedb landing scheduled for?
abadger1999I finished up the koji sync script.  Only a pkgdb CLI client for cvsadmins to add and update remains.
Half done with that.
bpeppleabadger1999: cool.
ok, is there anything else? Or should we call it quits for today?
Kevin_Koflertibbs: "juju" is the new Firewire stack in recent kernels.
f13bpepple: well, I've got one thing.
bpepplef13: shoot.
f13bpepple: 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.
f13so we're going to start fixing things ourselves and updating people's packages.
just giving FESCo a (re)heads-up
nottingf13: ooh, bastard mode.
bpepplef13: sounds fine with me.
f13notting: pretty much, yeah
Gf13: and a very good job releng does as well btw, out of interest, the freeze will be for test1 right?
tibbsA lot of the upgrade paths can be fixed just by pushing updates through bodhi.
niriksounds good... although you might also ping maintainers directly again...
tibbsPeople still aren't understanding that they need to do that.
ixsf13: the problems you will be working on are the ones in the normal dependency report which is mailed out tot the maintainers list, right?
f13ixs: yes, and any others we find.
drago01f13: seems like (almost) all of thge
m just need a rebuild
f13tibbs: I'm mostly talking about the paths from say 7 -> devel
or 6 -> devel
6 -> 7 I'm not dealing with right now.
bpeppleok, 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!