| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process | ||
| * f13 is here. | ||
| poelcat here | ||
| bpepple | FESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren | |
|---|---|---|
| Hi everybody; who's around? | ||
| * dgilmore is here | ||
| tibbs|h here | ||
| nirik is here. | ||
| * jwb is here | ||
| jeremy is here | ||
| c4chris is here | ||
| spot is here | ||
| dwmw2 here | ||
| linux_geek | bpepple .. linux_geek here ( new joinee.. if you allow ) | |
| * nim-nim is here if needed | ||
| bpepple | linux_geek: your allowed. we just ask that folks don't go off-topic. | |
| --- bpepple has changed the topic to: FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01850.html | ||
| jwb | linux_geek, anyone is welcome to be here. but only FESCo people can vote :) | |
| linux_geek | thanks bpepple and jwb .. but i guess .. iam allowed to work with you folks, if okay | |
| bpepple | ok, the FPC had a proposal for font packages, anyone object to it? | |
| * nirik thinks thats fine.... including the comps stuff. | ||
| c4chris | no objection | |
| dwmw2 | seems reasonable | |
| f13 | no objection | |
| * bpepple didn't have any problem with it either. | ||
| dgilmore | seems ok to me | |
| jwb | fine with me | |
| jeremy | looks fine to me | |
| tibbs | +1 from me. | |
| * warren here | ||
| bpepple | ok. I don't see anyone objecting to it, so I think we can safely move on. | |
| --- bpepple has changed the topic to: MISC - Fonts Comps Policy - http://fedoraproject.org/wiki/PackagingDrafts/FontsComps - Nicolas Mailhot | ||
| nirik | thats the same text as the end of the fonts policy right? looks ok to me. | |
| we should make sure existing font packages are made to conform to it tho if there are any that don't. | ||
| f13 | +1 from me. | |
| dgilmore | seems ok to me also | |
| f13 | and yes, I"d like to see a plan of action for existing packages. | |
| dgilmore | nirik: we should make sure all fonts are put in | |
| bpepple | nirik: agreed. I think Nicolas was wondering what group was in charge of the comps package (FPC, FESCo, etc). | |
| dgilmore | bpepple: everyone is responsible for the comps files | |
| warren | what has been the cause of comps corruptions? | |
| nim-nim | bpepple: in fact FPC wrote last week comps was outside its area, and ask you about it | |
| dgilmore | bpepple: you are responsible to add your own packages | |
| f13 | warren: rsync and/or netapp | |
| warren | oh | |
| f13 | only twice have I seen it be malformatted at the source | |
| c4chris | fine with me | |
| tibbs | FPC didn't feel it had jurisdiction over what went into comps where. | |
| * nirik has had anoyances with comps on his mirror this morning, but thats off topic for here... | ||
| tibbs | I think the FontsComps document makes sense. | |
| I'm just not aware that we have other guidelines about comps which are so specific. Maybe we need some. | ||
| bpepple | ok, we should probably move on..... | |
| nim-nim | tibbs: other broups do not have tons of small packages, have you seen mizmo's monster fonts wishlist? | |
| tibbs | I have not. | |
| --- bpepple has changed the topic to: MISC - Drop orphans from F8< at some point during F9 - f13 | ||
| nim-nim | tibbs: here http://fedoraproject.org/wiki/SIGs/Fonts/Triaging/Pipeline#wishes | |
| nirik nim-nim | ||
| f13 | Oh that's me (: | |
| warren | f13, have you checked on the status of the really short list? | |
| f13 | warren: no? | |
| linux_geek | sorry to interrupt .. any work for me .. if possible ? | |
| * warren looks at it real quick | ||
| warren | bpepple, can we go to the next one then come back to this immediately thereafter? | |
| bpepple | warren: np. | |
| c4chris | linux_geek: I think you want the admin meeting later on... | |
| * f13 is a little confused that warren sent mail out on this already, I didn't think fesco had approved this yet. | ||
| --- bpepple has changed the topic to: MISC - Using Matt Domsch's "doesn't rebuild" bugs as AWOL detection, mark as orphaned at some point in F9, drop in F9+ | ||
| warren | f13, we decided we would come back to it after the announcement warning had some time. | |
| f13 | ah | |
| warren | f13, but I suspect there are none left. | |
| f13, so I'm checking now. | ||
| f13 | k | |
| nirik | yeah, I think they all got picked up... but not sure. | |
| f13 | THis topic ties in a bit with last topic | |
| bpepple | f13: the next topic also. | |
| f13 | Matt does full rebuilds fairly often and identifies a lot of potential problems. | |
| nirik | I would like to see a more concrete proposal. With details... | |
| f13 | I'd like to have those be filed in bugzilla and attached to a tracking bug | |
| and we can track those bugs as part of discovering MIA maintainers | ||
| jwb | so matt's builds cover i386 and x86_64 right? | |
| f13 | We would mark the package as orphaned at that point, so that it could be cleaned up later if nobody claims it. | |
| jwb: I think so yes. | ||
| dwmw2 | yeah. I keep meaning to get round to doing the same on ppc (and ppc64 I suppose) | |
| all architectures SHOULD do it, as far as I'm concerned | ||
| jwb | so if ppc does the same, can we use those as bugs as well? | |
| dwmw2 | of course | |
| jwb | i mean bugs to track MIA maintainers | |
| f13 | jwb: I see no reason why not. | |
| jwb | ok | |
| nirik | I think it's a fine idea, but I think there should be concrete details... how long do they have? when is someone marked awol... if it builds again does it reset? | |
| jwb | nirik, agreed | |
| dwmw2 | if a maintainer can't even say "I'm too lazy to fix it; I'll ExcludeArch and put this bug on the FE-ExcludeArch-ppc tracker" then I think that meets the definition of 'missing in action' :) | |
| f13 | nirik: I had assumed the same rules that FESco has used in the past to find MIA maintainers when they did forced mass rebuilds. | |
| bpepple | f13: seems reasonable to me. | |
| nirik | I don't know that those rules are written down anywhere... | |
| http://fedoraproject.org/wiki/PackageMaintainers/Policy/AWOL_Maintainers is what we have. | ||
| f13 | yeah, so maybe I'lll have to come up with my own. | |
| but if FESCo likes this idea in principle I can then spend the effort to work up a full proposal. | ||
| I'm mostly just doing driveby stuff right now | ||
| nirik | I like the idea... things that don't build do need to be fixed. | |
| dgilmore | f13: i think it is a good idea and something we need | |
| f13 | This should also satisfy those that thing we should just rebuild everything every day just for funsies. | |
| bpepple | I'm fine with the idea. | |
| f13 | and we have some bite to go with our bark, in that if you don't respond, your package goes orphane, and later gets garbage collected | |
| c4chris | sound fine to me | |
| bpepple | ok, I don't see anyone saying that this is a bad idea, so f13 I think you've got FESCo's initial approval to the idea. | |
| f13 | ok. I'll try to work on the proposal soon. | |
| warren | OK, I have a complete orphan list now. | |
| jwb | i have one questoin | |
| f13 | jwb: shoot | |
| jwb | mdomsch does these on his local mirror, and it takes a while to actually churn through everything. which means some things fail that have already been fixed | |
| are a few false positives fine, or do we want to look at doing this on the master repos? | ||
| f13 | I'm not sure. | |
| dwmw2 | why not do each build from a current mirror, rather than snapshot and then run the whole set? | |
| nirik | I think the policy could reflect that it should be for packages that don't rebuild over a long period of time... not just once off. | |
| f13 | I'd be more than happy to try and help him make it either A) faster, B) more tolerant to false positives, etc... | |
| jwb | nirik, yes | |
| c4chris | nirik: yes | |
| f13 | sure, we can play some games with how many cycles it has been since it was noticed that it didn't rebuild. | |
| warren | http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt Packages orphaned since before F8 that are still orphaned in devel. (whenever we get back to this topic) | |
| jwb | does he do these builds weekly or monthly? | |
| f13 | jwb: don't know. | |
| nirik | and keep track of NVR to make sure it wasn't a new version that also stopped working. | |
| jwb | f13, that would be important to know too. | |
| i don't really want to bring it internally. i think having mdomsch run them is fine, and shows that not everything needs to be hosted here | ||
| nirik | if we use this as part of awol policy we can perhaps ask that they be done once a month or something on a schedule | |
| f13 | nirik: there was a request to rename "awol" to "mia" | |
| jwb | yeah. some statement about frequency of builds would be good when determining the time periods | |
| f13 | nirik: indeed, that was my thought. | |
| bpepple | ok, anything else on this, or should we go back to the orphan topic? | |
| nirik | neither is that great... 'nonresponsive maintainer' 'orphaning package'... not sure. Oh well. | |
| --- bpepple has changed the topic to: MISC - Drop orphans from F8< at some point during F9 - http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt - f13 | ||
| f13 | MIA makes it sound less like they're goign to go to jail (: | |
| nirik | still has that war type feel to it though... | |
| f13 | yeah, but MIA has a much different meaning than AWOL (: | |
| jwb | back to the topic... | |
| f13 | anyway, I'm OK to move back to last topic | |
| jwb | what was the criteria here again? | |
| bpepple | ok, warren had this list of orphans: http://fedorapeople.org/~wtogami/temp/rawhide-removals.txt | |
| jwb | oh orphans | |
| warren | jwb, orphaned prior to F8, currently still orphaned in devel. | |
| poor orphans | ||
| * c4chris sees that e.g. cdiff already has a dead.package file in its /devel | ||
| warren | eclipse-emf looks important? | |
| f13 | right. | |
| c4chris | what more is wanted ? | |
| f13 | I want to start some active garbage collection | |
| dgilmore | warren: thats all? | |
| warren | dgilmore, yes | |
| jwb | c4chris, blocked from the repos | |
| dgilmore | warren: i expected more | |
| f13 | if it has been orphaned for over a release, I want to block it and drop it. | |
| warren | dgilmore, the list as of 2 weeks ago was real short, and many were claimed | |
| dgilmore | f13: can you kill them today | |
| c4chris | jwb: blocked how ? | |
| nirik | I say block and drop after this meeting. | |
| warren | isn't eclipse-emf important? | |
| nirik | if anyone screams they can revive them. | |
| jwb | c4chris, blocked in koji and removed from rawhide | |
| dgilmore | warren: if it is someone will yell | |
| jwb | c4chris, e.g. the package will no longer exist | |
| f13 | what I'd like to do is set up a predictable date each release that we would process the drops | |
| jwb | except in CVS | |
| c4chris | jwb: you mean there still is a cdiff-*.rpm in rawhide ? | |
| nirik | I think the eariler the better... | |
| dgilmore | f13: 2 weeks after release | |
| f13 | so that it's scheduled and known ahead of time, and reasonable enough time to clean up any messes it introduces | |
| bpepple | dgilmore: +1 | |
| nirik | dgilmore: +1 | |
| tibbs | +1 | |
| f13 | 2 weeks after release, maybe. WHy not tie it with the point when we retire the old Fedora too? one month? | |
| warren | +1 | |
| f13 | cluster the important dates if you will. | |
| dwmw2 | just seems a little weird to me to drop unsupportable stuff _after_ the release | |
| dgilmore | f13: that would be ok also | |
| dwmw2 | given that these are all going to be leaf-node packages, I'm half tempted to suggest two weeks _before_ the release :) | |
| bpepple | f13: I'm fine with that. | |
| c4chris | f13: sounds good | |
| f13 | dwmw2: a package could become orphaned at any point during the release, we can't drop it before the release if it's going to throw up a bunch of broken deps or has been in pre-releases and expected to be in final. | |
| nirik | f13: fine with me too. | |
| f13 | dwmw2: they aren't always leaf nodes. | |
| dgilmore | dwmw2: a few times there have been many packages depending on them | |
| dwmw2 | I suppose so. | |
| poelcat | starting with F10? | |
| c4chris | poelcat: ? | |
| dwmw2 | poelcat: you mean starting 1 month after F9? | |
| poelcat | dwmw2: yes, when would we start this new prohcess? | |
| c4chris | now ? | |
| f13 | poelcat: the idea is to flush what we have now, and have a scheduled flush 1 month after F9 | |
| c4chris | when we drop FC-6 | |
| f13 | er yeah whoops | |
| not now, when we drop FC-6 | ||
| poelcat | got it | |
| dgilmore | c4chris: i think we start immediatly | |
| * f13 gets his dates screwed up. | ||
| jwb | c4chris, answer to your cdiff question: no. | |
| warren, why is cdiff on the list? | ||
| f13 | dgilmore: why would we do it earlier this release than we would next release? | |
| dgilmore | have someone send an email to fedora-devel-announce stating whats going on and why | |
| f13: i mean with this release | ||
| f13 | dgilmore: mail was already sent | |
| but we can re-send and update yes. | ||
| that would be absolutely necessary | ||
| dgilmore | f13: and state that orphans will be dropped from rawhide when a release is dropped | |
| warren | jwb, oops | |
| jwb, I put the list together manually because there wasn't a programmatic way to query it | ||
| jwb | heh, ok | |
| * poelcat should add the drop FC-6 date to the schedule... what is it? | ||
| warren | There is no cdiff on the list. You're crazy. | |
| nirik | dec 7th I think | |
| f13 | one month after F8 was released | |
| so Dec 8th | ||
| poelcat | saturday? :) | |
| f13 | well... (: | |
| dgilmore | f13: dec 7th | |
| f13 | sure why not, happy friday | |
| jwb | warren, heh | |
| jeremy | information on when the last fc6 update push will be was already sent | |
| nirik | we announced the 7th I guess... https://www.redhat.com/archives/fedora-devel-announce/2007-November/msg00000.html | |
| jeremy | yeah, there's the mail I was looking for | |
| bpepple | f13: anything else on dropping orphans? | |
| f13 | good | |
| f13 | bpepple: I don't think so, it seems we're all in agreement that we should do this regularly | |
| mdomsch | Dec 7 is a day that will live on in infamy | |
| f13 | all orphanes collected from the previous release will be purged one month after. | |
| mdomsch | and it's a workday | |
| so I figured that day would work out nicely | ||
| f13 | I'm ready to move on. | |
| bpepple | poelcat: how much time you want for the features discussion? | |
| poelcat | bpepple: that is a dangerous question | |
| f13 | hah | |
| warren | poelcat, argh, is it too late to write more features pages? | |
| one key feature I didn't write yet | ||
| poelcat | warren: no; up until feature feeze | |
| f13 | Can I have one more topic? | |
| bpepple | I know. we've got merge reviews to discuss, but I see that being a long discussion. | |
| poelcat | In the interest of time... how about if we only do 4 or 5 features today? | |
| http://fedoraproject.org/wiki/Features/Dashboard will remain current to voters | ||
| can review in advance of next week's meeting | ||
| bpepple | f13: is it a quick topic? | |
| poelcat | s/to/so | |
| f13 | yeah, it's the more fequent automated conflicts checking with bugs filed and MIA detection. | |
| --- bpepple has changed the topic to: MISC - Do more frequent conflicts testing, with bugs filed, and use AWOL detection | ||
| bpepple | poelcat: sounds good. that will be the next topic. | |
| f13 | ah | |
| nirik | this is multiarch conflicts? | |
| f13 | Just a quick blurb. I'd like to see this done. | |
| nirik: all conflicts | ||
| These bit us in the ass with the F8 release, so I"d like to detect them more early and more often. | ||
| jwb | f13, can't we role that up with dep checks and such in bodhi? | |
| nirik | what other conflicts do we get? two packages with the same files? | |
| f13 | also RPM is going to change so that conflicts are conflicts no matter when installed, either at the same time or in different transactions. | |
| nirik: yes. | ||
| jwb: this isn't (just) for updates. | ||
| it's also for rawhide so that we can avoid having conflicts in the package set, which are not allowed | ||
| jwb | neither should dep checks be | |
| f13 | jwb: we get dep checks each night with rawhide | |
| jwb | right, that's what i'm saying | |
| add it to the same scripts? | ||
| nirik | sounds fine to me... who is going to do that testing tho? for mia detection it should be folded into the policy when it's written up. | |
| f13 | anywho, I'd like to have regular conflicts checks, with bugs filed, and tie into the other MIA + orphan detection we have going on. | |
| jwb: potentially. | ||
| f13 | jwb: would depend on how much time it takes. | |
| bpepple | I'm all for that. | |
| jwb | f13, yeah | |
| f13 | nirik: jeremy ahs some scripts for detecting multilib stuff. | |
| c4chris | sounds fine | |
| jwb | aren't we going to kill multilib anyway? | |
| jeremy | http://katzj.fedorapeople.org/multilib-cmp.py | |
| f13 | this could be someting we place out there as "we want this to happen, please somebody script this" | |
| nirik | sure, go for it... it's worth noting that we should make sure not to re-file already filed bugs tho. | |
| warren | What happened to the multilib plugin thing? | |
| bpepple | f13: +1 | |
| f13 | and if nobody gets to it maybe I'll get to it eventually | |
| nirik | there are already a pile of multilib ones that notting filed. | |
| f13 | nirik: yeah, any such script should have the capability of discovering already filed bugs. | |
| warren: ask notting for a meeting recap | ||
| Ok, I'm done with this topic. I'll work on a write up for it along with the rebuild stuff. | ||
| warren | f13, which meeting? | |
| f13 fab | ||
| bpepple | f13: great. thanks. | |
| --- bpepple has changed the topic to: FESCo-Meeting -- New Features - http://fedoraproject.org/wiki/Features/Dashboard - poelcat | ||
| * nirik guesses we aren't going to get rid of the way we do multilib in f9 either. sigh. ;( | ||
| bpepple | poelcat: floors yours. | |
| --- poelcat has changed the topic to: http://fedoraproject.org/wiki/Releases/FeaturePresto | ||
| poelcat | vote +1/-1 | |
| bpepple | +1 | |
| nirik | +1 here. | |
| jwb | +1 and i'd really like to see it happen with the koji refresh | |
| spot | +1 | |
| tibbs | +1 | |
| c4chris | +1 (just do not understand the "Ensure that changing files from a package lead to downloading the full package rather than the delta" thing) | |
| dgilmore | +1 | |
| jeremy | I'm all for the feature, but there's still not much going on in the koji side of it :-/ | |
| jwb | damn | |
| nirik | is it likely to? is there anything we can do to get more movement on the koji side? | |
| tibbs | c4chris: I think the point is that if you modify non-config files, you don't want presto applying a delta to your modified file. | |
| jwb | nirik, code it? | |
| warren | +1 | |
| We need to talk about delta rpm generation implementation though. There are some differing opinions. | ||
| nirik | jwb: would love to, but I haven't done any hard core coding in a while... ;) | |
| f13 | jwb: I seriously doubt that will happen with the refresh | |
| jwb: the refresh is early in Dec, and there os 0 code written for it in koji. | ||
| tibbs | The bottom line is that we want this, but if the koji integration doesn't happen then the feature will eventually be dropped. | |
| f13 | I'm curious, jeremy are you still going to be a feature owner for this? | |
| warren | I think the point is being missed here. | |
| You don't actually need koji integration for this. | ||
| It can be done entirely asyncronously, and you probably want to for speed. | ||
| * spot needs to head out, sorry | ||
| warren | Given that the repos work with or without delta's. | |
| c4chris | tibbs: oh, I see. Didn't grasp that deltas apply to the installed files... somehow thought they were applied to the rpm | |
| jeremy | I really don't have time for pushing it right now | |
| f13 | warren: are you offering to take ownership of this feature and work out a reasonable way to do this outside of koji that releng can review and approve? | |
| mbonnet | Koji is the wrong place for this. Koji doesn't know anything about what actually gets pushed to the repos. Bodhi would be a better place for it. | |
| warren | f13, FINE, I'LL DO IT | |
| It might query koji but it wont be part of any build process | ||
| or tree build | ||
| jeremy | mbonnet: the problem si that we don't want to have multiple places for storing things. and especially given some of the interactions with signatures | |
| * c4chris has a buzzing ear now... | ||
| f13 | It has to be a part of something so that the deltas go in place at the same time the other repodata does too. | |
| mbonnet | jeremy: but how do you know what to generate deltas against? | |
| warren | f13, I was under the impression that deltas don't have repodata. Maybe that changed. I'll own it and see what's possible. | |
| f13 | but since I don't have time to work on this, I'm not going to dictate how it's done. I do however want releng to have a say before any method of publishing the deltas is "approved" | |
| bpepple | ok, I see eight '+1' for this feature, so we should probably move on. | |
| warren | f13, sure. | |
| jwb | mbonnet, bodhi doesn't work for rawhide | |
| jeremy | mbonnet: you have to say what you want to generate against. but that's no different than having to specify a signature or collinst, etc | |
| jwb | bpepple, yes, lets | |
| jeremy | warren: there is metadata describing the deltas | |
| bpepple | poelcat had to leave for a 2:00 meeting, so I'll take over for him. | |
| warren | jeremy, I'll look into what is possible. | |
| bpepple | http://fedoraproject.org/wiki/Releases/FeatureKDE4 | |
| f13 | mbonnet: we have some reasonable assumptions. We can see what's the latest build in the -gold tag, we can see what the latest build in the -updates tag is, etc... | |
| --- bpepple has changed the topic to: http://fedoraproject.org/wiki/Releases/FeatureKDE4 | ||
| f13 | I'm +1 for KDE4 | |
| bpepple | +1 | |
| jwb | +1 | |
| nirik | +1 for kde4. | |
| c4chris | +1 | |
| dgilmore | +1 | |
| f13 | looks like a very good write up. | |
| tibbs | +1 | |
| bpepple | f13: agreed. | |
| jeremy | +1 | |
| bpepple | ok, that's eight '+1', so the KDE feature has been approved. | |
| --- bpepple has changed the topic to: http://fedoraproject.org/wiki/Features/OneSecondX | ||
| bpepple | +1, sounds like a cool feature to me. | |
| c4chris | +1 | |
| nirik | +several... sounds very nice. | |
| jwb | erm.. +1 | |
| tibbs | +1 | |
| f13 | +1 | |
| dgilmore | +1 | |
| jeremy | looked good to me, +1 | |
| bpepple | ok, that's eight '+1', so we've approved that. | |
| --- bpepple has changed the topic to: http://fedoraproject.org/wiki/Features/ServerProvides | ||
| bpepple | Is Patrice still interested in this? I seem to recall on the mailing list that he wasn't. | |
| f13 | +1 | |
| nirik | I like this one, but it should also get some noise... so 3rd party repos can pick it up. | |
| in any case, +1 | ||
| jwb | this one has the potential to be a rats nest | |
| tibbs | The noise is one reason this is a "feature". | |
| c4chris | jwb: --verbose ? | |
| dgilmore | it seesm really fuzzy | |
| jwb | c4chris, i worry about having only part of the packages switch over | |
| warren | So somebody can write a SMTP server named "a" that wins. | |
| jwb | some require smtpdaemon, some require server(smtp) (or apply that to any web port) | |
| * dwmw2 is happy with exim winning :) | ||
| dwmw2 also has to go... sorry. | ||
| c4chris | I think it's worth a try | |
| +1 | ||
| f13 | warren: not a new problem, nothing to see here, move along. | |
| dwmw2_gone | +1 | |
| bpepple | +1 | |
| warren | This seems like a "minor" feature to me | |
| does this really require a feature page? | ||
| this is a "blurb" | ||
| f13 | warren: it is, however since it touches many packages, and can have effect in our third party repos, it needs some voice. | |
| c4chris | I think we need the noise factor | |
| warren | OH... PR feature, I see. | |
| +1 | ||
| dgilmore | +0 | |
| * jeremy is ambivalent, 0 | ||
| warren | Propaganda Feature | |
| abadger1999 | jwb: If it's policy and a feature for F9 then packages need to be changed to the new Provide: | |
| jwb | abadger1999, and become part of the guidelines, and have someone go through everything, and... | |
| bpepple | ok, I see six '+1', and two '0'. anyone else want to weigh in? | |
| jwb | 0 | |
| tibbs | +1 | |
| bpepple | ok, so we're at seven '+1' and three '0'. This feature has been approved. | |
| abadger1999 | Guidelines were fine for FPC; the second issue is why we wanted it to be a Feature. | |
| bpepple | ok, let's do one more feature, and then wrap up the meeting for this week. | |
| --- bpepple has changed the topic to: http://fedoraproject.org/wiki/Features/XserverOnePointFive | ||
| bpepple | +1 | |
| f13 | +1 | |
| jwb | why is this a feature? | |
| f13 | I saw a partial demo today, really fscking cool | |
| tibbs | +1 | |
| f13 | jwb: because it enables some really really cool shit | |
| and if we don't brag about it, ubuntu will take all the credit | ||
| nirik | +1 | |
| jwb | ok +1 | |
| c4chris | +1 | |
| f13 | also, we'll likely be a driving force in getting upstream to release on time, and have had some testing on it | |
| warren | another Propaganda Feature | |
| dgilmore | +1 | |
| warren | +1 | |
| jwb | can we mark these somehow? | |
| f13 | warren: except that we're (RH) employing not a small number of people working on these features | |
| jwb | so idiots like me don't say "this is just a normal upgrade thing" | |
| bpepple | ok, that's eight '+1', so we've approved this feature. | |
| dgilmore | i do think that when we are first to implement something new we need to capitalise on it | |
| f13 | it's not like we just get it for free when upstream gifts us with a tarball, we're actually doing the work to make it happen. | |
| bpepple | f13: agreed. | |
| f13 | jwb: it's not just a normal upgrade thing. | |
| warren | f13, right, it really doens't change the delivery of the feature though if we approve or disapprove of it here, so it is really only propaganda. | |
| jwb | f13, you could say the same about yum development, etc | |
| anyway, offtopic | ||
| f13 | jwb: we could. However more people use X than yum. | |
| bpepple | ok, is there anything else people want to discuss before wrapping up the meeting? | |
| f13 | RH/Fedora is making this work happen, that other's are goign to get for free. | |
| nirik | I have a quick query... | |
| f13 | Does anybody remember setting a deadline for kmod packages to go bye bye? | |
| jwb | NOW | |
| tibbs | Yeah, I though it was "immediately". | |
| nirik | I have a request to grant a FC-6 branch exception for a xfce plugin... it was orphaned, it's back, and the maintainer would really like to provide it in FC-6 as well... see https://bugzilla.redhat.com/show_bug.cgi?id=392981 | |
| buggbot | Bug 392981: medium, medium, ---, Kevin Fenzi, ASSIGNED , Review Request: xfce4-modemlights-plugin - Modemlights for the Xfce panel | |
| bpepple | nirik: isn't it past the point of creating new branches for F-6? | |
| nirik | bpepple: yes. He wants an exception... I guess FESCO would be the one to grant that? or should I tell him no exceptions...? | |
| f13 | I don't really see this ias a reasonable exception. | |
| jwb | which is why he phrased it as an exception... | |
| f13 | FC6 is days away from being EOL, it's not like we're expecting new installs of it, or upgrades to it. | |
| nirik | he just wants it in all releases... not skipping fc-6... but yeah, I don't care, just wanted to ask here about it. | |
| tibbs | I don't see why it would be "really bad" to have it in FC5 and F7 but not FC6. | |
| nirik | I guess the only way it would be 'really bad' is if someone upgraded to FC-6... | |
| but we shouldn't be encouraging that. | ||
| abadger1999 | Will there be people upgrading from FC5=>Fc6=>F7? | |
| f13 | I hope not. | |
| jwb | why would they do that | |
| notting | when fc6 goes eol in a week or two? | |
| f13 | that's just asking for 2x the potential for failure. | |
| abadger1999 | ie, upgrading version to version instead of trying to do an upgrade all the way to latest? | |
| tibbs | That would still just leave the FC5 package on the "fresh" FC6 system, which would then be upgraded to the F7 package. | |
| c4chris | tibbs: right | |
| * abadger1999 remembers when people advised doing that. | ||
| nirik has nothing else. Thanks for looking at that. | ||
| bpepple | ok, let's wrap up the meeting then. | |
| * bpepple will end the meeting in 60 | ||
| abadger1999 | tibbs: Wouldn't dependencies (in a yum upgrade) break that? | |
| f13 | Ok, I'm going to send mail to the kmod maintainer(s) and let them know kmods are going to be blocked. | |
| tibbs | abadger1999: depends. | |
| bpepple | f13: cool. | |
| * bpepple will end the meeting in 30 | ||
| * bpepple will end the meeting in 15 | ||
| warren | f13, will you mention that htey should work on getting included in the kernel? | |
| (or upstream) | ||
| bpepple | -- MARK -- Meeting End | |
| f13 | yeah, I'll try to find references to when we talked about it | |
| or passed the policy | ||
| bpepple | Thanks, everyone! | |
| tibbs | abadger1999: If upgrading via anaconda, no, the package would be left on the FC6 system with broken dependencies, and then would be properly upgraded to F7. | |
| c4chris | bpepple: thank you | |
| tibbs | At least that's been my experience. | |
| c4chris | later folks | |
| bpepple | warren: I think I included that in my FESCo minutes from last week. http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20071119 | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!