Re: KDE vs. GNOME on F10
On Thu, 2009-08-06 at 05:37 +0200, Kevin Kofler wrote: Adam Williamson wrote: I probably couldn't do much justice to a comprehensive plan as I have insufficient knowledge of how the buildsystem works. I was acting at a higher level - just trying to point out that it's essentially doomed to try and please everyone with a single update repository, that's not an argument anyone can win. Either the 'we want stable updates' camp or the 'we want shiny new stuff' camp is going to be disappointed. The problem is that your solution doubles maintainer and rel-eng workload. I think we really don't have the resources for that. Please don't personalize things. It's not 'mine', and it's not really a solution. I'm simply pointing out that it's literally impossible to satisfy both possible update policies with a single unitary repository. We either have to make it clear which policy we use and which policy we don't, and hence which theoretical user base we are not targeting, or take on extra work and try to satisfy both. I am not declaring myself in favor of, or against, any particular option. I'm just pointing out the parameters of the question. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, 2009-08-06 at 05:42 +0200, Kevin Kofler wrote: Adam Williamson wrote: If we are - or _want to be_ - that kind of a distribution, we have to provide a stable update set so we can stop telling people who just want a distro to run Aunt Flo's desktop or their webserver or whatever on to run CentOS or Ubuntu instead. If, however, we really don't care about that kind of usage scenario and instead we want to focus only on being a kind of project for the prototyping of systems that will eventually _become_ components of that kind of generally usable operating system - which to my mind is more or less the status at the moment - it doesn't make any sense to provide a stable update set, it's not serving any real purpose, and it'd just be a waste of effort. Actually, I think our KDE updates are very much beneficial even to Aunt Flo type users. We wouldn't push them out if we thought otherwise. At this point you're getting down to update theory, which is a deeply unexciting area to most people, I suspect ;) The problem with that approach is that, in the conventional approach to updates, the key factor is _continuity_. You don't change behaviour or risk regressions. If an update fixes ten bugs but changes the behaviour of some component people see every day - which is a fairly accurate description of both KDE and GNOME point releases - it's not appropriate to be an update, in this theory, because it means the updated product is breaking the expectations of the the initial release. What your frazzled sysadmin cares about most is that things work on Tuesday the same way they did on Monday - even if that just means they're broken in the same way. If you can fix something without changing the fundamental behaviour of the system, great, but that's all. As I said, I'm not arguing in favour of or against any particular position. I'm just pointing out the angles here. There is a conventional approach to updates that many distributions use, and that some types of user expect and would like in any distribution they use. We can choose not to do this, and it's fine, I just want it to be clear where the 'edges' are. Right now, if you ask around in the conventional places - Fedora forums, Linuxquestions, distrowatch, IRC, places like that - people will tell you that, if what you want is a conventional stable operating system to run your servers or whatever on, that doesn't change from day to day, don't run Fedora, run CentOS (or Ubuntu or Debian or SUSE or...whatever they like). If we're happy with that, that's great. But it is worth being aware exactly what the status quo is. It seems like our current policy is more de facto than the result of any reasoned decision. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
On Wed, 2009-08-05 at 21:58 -0700, Markus Kesaromous wrote: I know this is a staging and thus experimental driver. I only wanted to point out that if you compile the kernl without SMP support, then this driver module will have these undefined symbols: spin_lock_bh _per_cpu_offset synchronize_irq spin_unlock_irqrestore del_timer_sync spin_lock_irqsave I did a cursory look at part of the code, and it is obvious this code is not up to snuff in coding style, and in one file, missing header include. At the very least, the code needs to surround locking and unlocking code with #ifdef CONFIG_SMP spin_lock...or spin_unlock ... #endif Wouldn't this be better sent to lkml? I don't think anyone in Fedora works on the in-kernel rt2860 driver, do they? I don't recognize any of the names in http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/staging/rt2860;hb=HEAD as being 'Fedora people'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
RE: rt2860 driver (fc11)
From: ceme...@u.washington.edu To: fedora-devel-list@redhat.com Date: Wed, 5 Aug 2009 23:17:12 -0700 Subject: Re: rt2860 driver (fc11) On Wednesday 05 August 2009 09:58:44 pm Markus Kesaromous wrote: I know this is a staging and thus experimental driver. I only wanted to point out that if you compile the kernl without SMP support, then this driver module will have these undefined symbols: Which Fedora kernels are compiled without SMP support? Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list I compiled the kernel without SMP support deliberately. It is a user configurable option. _ Get your vacation photos on your phone! http://windowsliveformobile.com/en-us/photos/default.aspx?OCID=0809TL-HM -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
RE: rt2860 driver (fc11)
From: awill...@redhat.com To: fedora-devel-list@redhat.com Date: Wed, 5 Aug 2009 23:27:32 -0700 Subject: Re: rt2860 driver (fc11) On Wed, 2009-08-05 at 21:58 -0700, Markus Kesaromous wrote: I know this is a staging and thus experimental driver. I only wanted to point out that if you compile the kernl without SMP support, then this driver module will have these undefined symbols: spin_lock_bh _per_cpu_offset synchronize_irq spin_unlock_irqrestore del_timer_sync spin_lock_irqsave I did a cursory look at part of the code, and it is obvious this code is not up to snuff in coding style, and in one file, missing header include. At the very least, the code needs to surround locking and unlocking code with #ifdef CONFIG_SMP spin_lock... or spin_unlock ... #endif Wouldn't this be better sent to lkml? I don't think anyone in Fedora works on the in-kernel rt2860 driver, do they? I don't recognize any of the names in http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/staging/rt2860;hb=HEAD as being 'Fedora people'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list I was hoping that the devs who worked hard to even make it part of the source rpm might be lurking on this mailing list and see my post :) _ Express your personality in color! Preview and select themes for Hotmail®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=PID23391::T:WLMTAGL:ON:WL:en-US:WM_HYGN_express:082009 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Wed, 2009-08-05 at 23:05 -0700, Adam Williamson wrote: The problem with that approach is that, in the conventional approach to updates, the key factor is _continuity_. You don't change behaviour or risk regressions. If an update fixes ten bugs but changes the behaviour of some component people see every day - which is a fairly accurate description of both KDE and GNOME point releases - it's not appropriate to be an update, in this theory, because it means the updated product is breaking the expectations of the the initial release. What your frazzled The kernel's a great example here, BTW. If we update F10 to kernel 2.6.29, the ATI proprietary driver will stop working. We don't care about proprietary software and yadda yadda yadda, but it's exactly the kind of behaviour change in a supposedly 'final' product that certain groups of users just don't want to have to deal with. It doesn't really matter that the driver's proprietary, even. The point is that an interface that could reasonably be expected not to change in a 'stable' operating system release, by conventional definitions, does change in Fedora. Similar with the changes from 2.6.29 to 2.6.31. If we were to bump F11 from 2.6.29 to 2.6.31, the NVIDIA proprietary driver and the rt2860sta wireless driver (and possibly other out-of-kernel network drivers, too...) would break. The kernel guys consider it fine to do this sort of breakage between point releases, and Fedora considers it fine to ship kernel point releases as updates for 'stable' releases (we've done this in the past, 2.6.29 is still planned for F10 - just stuck due to problems - and I don't see any indication we won't be doing the same for F11). Certain groups of users just don't want this hassle. They have enough pain getting their graphics card / wireless card / whatever bit of hardware working right _once_, they don't want to have to do it again every two months (or whenever the next kernel point release happens to come out). They figure, since it's a stable release, once they get something working it ought to _keep_ working. This is the scenario that's problematic as long as we don't have a reliable conservative update path available. Again, if we decide that's a hit we're willing to take, that's fine. To bring it back to where we came in, we have a problem in that the KDE team are following one policy (update to the latest KDE release on the basis that it brings in new shiny goodness and fixes more stuff than it breaks) while the GNOME team are following the other (don't go to the latest point release in the interest of consistency). This doesn't make sense - if some parts of the distro are going with the adventurous policy, it renders the caution of other parts essentially null and void. The caution of the GNOME team doesn't really work, overall, if the kernel is following the adventurous policy. Conservative users still aren't going to go with Fedora. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 'IT Security' in comps?
On 08/06/2009 02:37 AM, Till Maas wrote: The IT prefix is only used in the group id, which is afaik not visible to the used and not translated. That's not true. yum -v grouplist will display them. I use them all the time as a shorter form of the full group names. Something like # yum install @xfce-desktop Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crontab configuration
On Wed, 2009-08-05 at 17:42 -0400, Ricky Zhou wrote: On 2009-08-05 04:32:57 PM, Mike Chambers wrote: Ok, in F11 it had /etc/anacrontab file that I could edit to get my cron.daily time to be set. But I don't see that file and can't find where the time is set that I want it ran from. I believe it was 4am this morning when it ran but I don't know where that time to run came from? My random guess from an rpm -ql cronie is /etc/regularly-jobs. All these anacron/crontab changes should hopefully be mentioned the release notes somehow :-/ Yes, however this name change will be reverted in the next upstream cronie release due some time during the next week. This change is too confusing to users. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
RE: rt2860 driver (fc11)
On Wed, 2009-08-05 at 23:50 -0700, Markus Kesaromous wrote: I was hoping that the devs who worked hard to even make it part of the source rpm might be lurking on this mailing list and see my post :) I don't think anything special is done to make it part of our kernel .src.rpm, it's just in there because it's in the upstream kernel tarball :). I don't _think_ any of the Fedora kernel devs will jump to fix this driver. But hey, I'm happy if I'm wrong, I have an rt2860-based card and it'd be nice not to have to rely on an out-of-tree, not-in-Fedora driver! I'm almost sure you'd do better to contact lkml or one of the main committers directly, though. Actually, now I look at it, it appears the driver is developed as part of the serialmonkey project: http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page which has links in the blue bar at the top for 'lists' and 'forum'. Those sound like good places to poke. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
On Thu, Aug 6, 2009 at 9:12 AM, Adam Williamsonawill...@redhat.com wrote: On Wed, 2009-08-05 at 23:50 -0700, Markus Kesaromous wrote: I was hoping that the devs who worked hard to even make it part of the source rpm might be lurking on this mailing list and see my post :) I don't think anything special is done to make it part of our kernel .src.rpm, it's just in there because it's in the upstream kernel tarball :). I don't _think_ any of the Fedora kernel devs will jump to fix this driver. But hey, I'm happy if I'm wrong, I have an rt2860-based card and it'd be nice not to have to rely on an out-of-tree, not-in-Fedora driver! I'm almost sure you'd do better to contact lkml or one of the main committers directly, though. Actually, now I look at it, it appears the driver is developed as part of the serialmonkey project: http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page which has links in the blue bar at the top for 'lists' and 'forum'. Those sound like good places to poke. The rt2860 driver is the Vendor driver provided by Ralink, it is considered crap by linux-wireless developers (for good reasons). Upstream work is being done on rt2800pci / rt2800usb the usb driver is supposed to be in a working state right now, the pci one could need some help (its not there yet). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mozvoikko doesn't build on F12, please help
On 08/06/2009 01:49 AM, Christopher Aillon wrote: On 08/05/2009 01:31 PM, Christopher Aillon wrote: It's also the reason why firefox doesn't yet build. http://koji.fedoraproject.org/koji/getfile?taskID=1581586name=build.log It's being worked on by Martin and Jan. They'll get the rebuilds for F12 ready too. In the interim, the F11 builds of XR and FF have been tagged into rawhide, so rebuilds can start happening. They should be in the buildroots soon. It's a gcc bug and it's tracked here - https://bugzilla.redhat.com/show_bug.cgi?id=515700 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
I was hoping that the devs who worked hard to even make it part of the source rpm might be lurking on this mailing list and see my post :) I don't think anything special is done to make it part of our kernel .src.rpm, it's just in there because it's in the upstream kernel tarball :). I don't _think_ any of the Fedora kernel devs will jump to fix this driver. But hey, I'm happy if I'm wrong, I have an rt2860-based card and it'd be nice not to have to rely on an out-of-tree, not-in-Fedora driver! I'm almost sure you'd do better to contact lkml or one of the main committers directly, though. Actually, now I look at it, it appears the driver is developed as part of the serialmonkey project: http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page which has links in the blue bar at the top for 'lists' and 'forum'. Those sound like good places to poke. Good luck with that! This driver has been in the process of being re-written for well over a year, I've long given up hope. Its unfortunate as its in alot of netbooks including all the atom based eeePCs. Fortunately rpmfusion has one that works reasonably well (it even suspends and resumes!) appart from spewing massive amount of debug into /var/log/messages (if left on about half a gig a day). Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Thursday 06 August 2009 01:59:02 Bastien Nocera wrote: On Thu, 2009-08-06 at 00:56 +0100, Bastien Nocera wrote: On Wed, 2009-08-05 at 15:15 -0700, John Poelstra wrote: Hi FESCo, After requesting status updates, including direct email to the feature owners, the following feature pages do not have a current status or their ability to tested during the Alpha is unclear based on the lack of information provided or percentage of completion. snip https://fedoraproject.org/wiki/Features/Gnome2.28 snip Feature will obviously be done on time. The feature process doesn't seem so forgiving about things happening upstream rather than downstream... In accordance with our recorded process about providing status, I am proposing that they reviewed and dropped from the Fedora 12 feature list at Friday's FESCo meeting. https://fedoraproject.org/wiki/Features/Policy/Dropping I'll make sure one of the Desktop-y guys updates this (presumably Matthias). I actually looked at this, and the feature process just isn't good enough for this. We can't really say we're at 100% for GNOME 2.28 when it hasn't been released, now can we? It's same for us - KDE SIG. Percentage completion is not the only one criterion for completeness, if we have everything prepared, we have betas/RC already imported and we're just waiting for final release (and as KDE has time based releases we know we can do it for Fedora release). And same for artwork - it's part of feauture but we have to wait for design team etc... The criteria should be - is it 100% ready? If not and it's waiting for upstream release (probably few more exceptions can be found) - is it possible to deliver this feauture 100% ready in time of release? Yes, we have schedule. Then OK. Jaroslav So what's expected of such features when the feature process seems inappropriate? Cheers -- Jaroslav Řezník jrez...@redhat.com Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
After requesting status updates, including direct email to the feature owners, the following feature pages do not have a current status or their ability to tested during the Alpha is unclear based on the lack of information provided or percentage of completion. https://fedoraproject.org/wiki/Features/FedoraMoblin I'm the maintainer of this. I think its very much in a similar category to gnome/kde. The only difference is there is some packages still awaiting review, about 2 that are actually critical, but moblin 2 like gnome etc are still in there development phase so its a moving target. In accordance with our recorded process about providing status, I am proposing that they reviewed and dropped from the Fedora 12 feature list at Friday's FESCo meeting. I'm not sure what I'm meant to be doing about providing status, I've been regularly updating the 2 pages percentages which is as far as I can tell the main thing I'm meant to be doing. There are a couple of dependant packages that need to get in and it will be in a testing state, I've been testing these myself so if they're not in by alpha they won't be far from it. This is the first time I've been involved in the Feature Process and I must say the whole thing has been about as clear as mud. I mean why isn't dracut on the cutting list, its listed as being at 90% which feature wise it may well be but it hasn't even been enabled yet so who knows what's going to break at that point, I see another anaconda storage rewrite coming up. Yet Moblin which doesn't even impact any of the rest of the distro has issues, I can put it at 100% but I don't see how that actually assists in the process. I don't see why if there's reasonable forward movement that features that don't impact other components of the distro have to be cut at the alpha stage of the process. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/06/2009 10:39 AM, Peter Robinson wrote: After requesting status updates, including direct email to the feature owners, the following feature pages do not have a current status or their ability to tested during the Alpha is unclear based on the lack of information provided or percentage of completion. https://fedoraproject.org/wiki/Features/FedoraMoblin I'm the maintainer of this. I think its very much in a similar category to gnome/kde. The only difference is there is some packages still awaiting review, about 2 that are actually critical, but moblin 2 like gnome etc are still in there development phase so its a moving target. IMO, this feature should be scratched, because the packages in question are of immature nature (... and of low packaging quality from my POV). Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
On Thu, Aug 6, 2009 at 4:23 AM, Peter Robinson wrote: I was hoping that the devs who worked hard to even make it part of the source rpm might be lurking on this mailing list and see my post :) I don't think anything special is done to make it part of our kernel .src.rpm, it's just in there because it's in the upstream kernel tarball :). I don't _think_ any of the Fedora kernel devs will jump to fix this driver. But hey, I'm happy if I'm wrong, I have an rt2860-based card and it'd be nice not to have to rely on an out-of-tree, not-in-Fedora driver! I'm almost sure you'd do better to contact lkml or one of the main committers directly, though. Actually, now I look at it, it appears the driver is developed as part of the serialmonkey project: http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page which has links in the blue bar at the top for 'lists' and 'forum'. Those sound like good places to poke. Good luck with that! This driver has been in the process of being re-written for well over a year, I've long given up hope. Its unfortunate as its in alot of netbooks including all the atom based eeePCs. Fortunately rpmfusion has one that works reasonably well (it even suspends and resumes!) appart from spewing massive amount of debug into /var/log/messages (if left on about half a gig a day). Peter I maintain those drivers at RPMFusion. I will be happy beyond imagination when the staging drivers are marked stable. It would save me a lot of work, for it's not just rt2860, but also rt2870 and rt3070. I keep writing patches and hacks to them for almost every kernel update since Ralink is a bit slow with kernel updates. I'm glad they are working though :) Orcan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/06/2009 02:14 PM, Ralf Corsepius wrote: IMO, this feature should be scratched, because the packages in question are of immature nature (... and of low packaging quality from my POV). Be specific. This is not enough information to influence the decision at this stage. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
On Thu, Aug 6, 2009 at 10:45 AM, Orcan Ogetbiloget.fed...@gmail.com wrote: On Thu, Aug 6, 2009 at 4:23 AM, Peter Robinson wrote: I was hoping that the devs who worked hard to even make it part of the source rpm might be lurking on this mailing list and see my post :) I don't think anything special is done to make it part of our kernel .src.rpm, it's just in there because it's in the upstream kernel tarball :). I don't _think_ any of the Fedora kernel devs will jump to fix this driver. But hey, I'm happy if I'm wrong, I have an rt2860-based card and it'd be nice not to have to rely on an out-of-tree, not-in-Fedora driver! I'm almost sure you'd do better to contact lkml or one of the main committers directly, though. Actually, now I look at it, it appears the driver is developed as part of the serialmonkey project: http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page which has links in the blue bar at the top for 'lists' and 'forum'. Those sound like good places to poke. Good luck with that! This driver has been in the process of being re-written for well over a year, I've long given up hope. Its unfortunate as its in alot of netbooks including all the atom based eeePCs. Fortunately rpmfusion has one that works reasonably well (it even suspends and resumes!) appart from spewing massive amount of debug into /var/log/messages (if left on about half a gig a day). Peter I maintain those drivers at RPMFusion. I will be happy beyond imagination when the staging drivers are marked stable. They won't ever (the rt Vendor drivers) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
Good luck with that! This driver has been in the process of being re-written for well over a year, I've long given up hope. Its unfortunate as its in alot of netbooks including all the atom based eeePCs. Fortunately rpmfusion has one that works reasonably well (it even suspends and resumes!) appart from spewing massive amount of debug into /var/log/messages (if left on about half a gig a day). Peter I maintain those drivers at RPMFusion. I will be happy beyond imagination when the staging drivers are marked stable. It would save me a lot of work, for it's not just rt2860, but also rt2870 and rt3070. I keep writing patches and hacks to them for almost every kernel update since Ralink is a bit slow with kernel updates. I'm glad they are working though :) I'm very glad of your efforts. a massive THANK YOU! Now I just wish the rewrites of the driver would speed up somewhat :) Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
On Thu, Aug 6, 2009 at 4:58 AM, drago01 wrote: On Thu, Aug 6, 2009 at 10:45 AM, Orcan Ogetbil wrote: I maintain those drivers at RPMFusion. I will be happy beyond imagination when the staging drivers are marked stable. They won't ever (the rt Vendor drivers) From my understanding, the staging tree of the kernel contains drivers that are being prepared to be included in the main kernel tree[1]. Correct me if I'm wrong. I'm not quite sure if I could catch what you meant. Are you being sarcastic, implying that the rt2xxx staging drivers will stay in the staging repo forever? I sure hope not :) Hey! Don't break my hopes! Orcan [1] http://lwn.net/Articles/285594/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
On 08/06/2009 02:44 PM, Orcan Ogetbil wrote: On Thu, Aug 6, 2009 at 4:58 AM, drago01 wrote: On Thu, Aug 6, 2009 at 10:45 AM, Orcan Ogetbil wrote: I maintain those drivers at RPMFusion. I will be happy beyond imagination when the staging drivers are marked stable. They won't ever (the rt Vendor drivers) From my understanding, the staging tree of the kernel contains drivers that are being prepared to be included in the main kernel tree[1]. Correct me if I'm wrong. That is the general intention but not all drivers will pass through however. Some of them are getting replaced with alternative drivers and that happens to be the case for the ones you have packaged. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Wed, 2009-08-05 at 12:58 -0700, Jesse Keating wrote: All this really does is create a pseudo rawhide for each release, blurring the lines even more around why we even do releases. With a 6 month cycle, do we really want to take on all this extra headaches and hassles just so that you can have some newer experimental software a bit sooner, or without doing a wholesale update to the next release? For fedora-virt folks, we have a virt-preview repository, the general idea being: - a repo where you can pull f11 builds of the latest rawhide virt bits - purely for people who want to help with testing f12 virt, but aren't willing to run rawhide - it's not about making new features available to f11 users, it's about allowing f11 users to get involved with f12 development - if it breaks, you get to keep both pieces - we'll do our best to fix problems specific to this repo, but in reality we care more about problems which affect stock f11 or rawhide/f12 - we're trying to keep the limit the packages in the repo to purely virt related packages - e.g. right now we need something from f12 selinux-policy, but I'm hoping we can get added in an f11 update rather than pulling in the f12 version and breaking non-virt stuff It hasn't been around long, but it's working well and we're getting valuable testing from it. The only thing we're missing is that we can't add virt-preview packages to the buildroot. We're considering switching from koji to mock for the builds because of this. With a little automation, I think this model could work fairly well for the likes of GNOME. Cheers, Mark. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
Le mercredi 05 août 2009 à 14:27 -0700, Adam Williamson a écrit : On Wed, 2009-08-05 at 13:03 -0700, Jesse Keating wrote: On Wed, 2009-08-05 at 12:58 -0700, Jesse Keating wrote: It also would require multiple CVS branches, one for security, one for adventurous, as well as different buildroots to go along with those, since you wouldn't be able to build a security update for a gnome package against the newer adventurous gtk and expect it to work on the older GTK, likewise if you had to modify a gnome package to work with newer gtk, you dont' want those modifications in the way if/when you need to do a conservative security update for it later. Oh I forgot, you also need -testing versions of each of those repos, so for any release, you could have updates, updates-testing, experimental, and experimental-testing repo options and build targets and buildroot shuffling going on. WHAT FUN! Mandriva has a /testing repository for /updates, but not for /backports, on the basis that /backports is fundamentally unstable so you may as well just do your testing in the repo. This works fine, so far. Well, some people ( me to some extend ) are not really happy with this, because some users tends to auto upgrade even with /backports and then complaint when something is broken. Once you tell them this is backports, do not expect everything to be functionnal, they start to recommend to others to not use this repository, thus giving /backports a bad reputation because of a few bad apples. But having /testing for /backports would have been maybe too complex, indeed. We didn't found a good solution when we discussed last time. ( and this was also discussed to death on mandriva mailling list too ) -- Michael Scherer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Wed, 2009-08-05 at 20:30 -0400, Matthias Clasen wrote: On Thu, 2009-08-06 at 00:56 +0100, Bastien Nocera wrote: I'll make sure one of the Desktop-y guys updates this (presumably Matthias). I've updated it recently and bumped it to 75%. It would seem disingenuous to bump it to 100% when GNOME 2.28 has not been released yet. Well, presumably you have a feature frozen 2.27 version in rawhide. IMHO, that means the actual features in 2.28 are at 100% - i.e. available for testing in the alpha release, definitely going to be in the final release etc. It is fine for the feature wrangler to propose it for removal. But I certainly hope that Fesco will not only look at pretty meaningless percentages, but at precedents and schedule alignments. Indeed. Cheers, Mark. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
Am Donnerstag, den 06.08.2009, 10:44 +0200 schrieb Ralf Corsepius: On 08/06/2009 10:39 AM, Peter Robinson wrote: https://fedoraproject.org/wiki/Features/FedoraMoblin I'm the maintainer of this. I think its very much in a similar category to gnome/kde. The only difference is there is some packages still awaiting review, about 2 that are actually critical, but moblin 2 like gnome etc are still in there development phase so its a moving target. IMO, this feature should be scratched, because the packages in question are of immature nature (... and of low packaging quality from my POV). This is what the review is for. The ones that are reviewed should be in good shape, if not, please speak up in the reviews and CC me with the address fedora at christoph - wickert . de. Ralf Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
On Thu, Aug 6, 2009 at 11:14 AM, Orcan Ogetbiloget.fed...@gmail.com wrote: On Thu, Aug 6, 2009 at 4:58 AM, drago01 wrote: On Thu, Aug 6, 2009 at 10:45 AM, Orcan Ogetbil wrote: I maintain those drivers at RPMFusion. I will be happy beyond imagination when the staging drivers are marked stable. They won't ever (the rt Vendor drivers) From my understanding, the staging tree of the kernel contains drivers that are being prepared to be included in the main kernel tree[1]. Correct me if I'm wrong. I'm not quite sure if I could catch what you meant. Are you being sarcastic, implying that the rt2xxx staging drivers will stay in the staging repo forever? I sure hope not :) Hey! Don't break my hopes! The rt vendor drivers are considered a dead end by the linux-wireless developers (just try to read the code and you would now why), the plan is to get rt2800pci and rt2800usb into shape and get them upstreamed. They get no support from the wireless developers at all, Greg added them to staging because they are better than no drivers. See the linux-wireless list for details. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
Adam Williamson wrote: the rt2860sta wireless driver Aren't there patches for that one already? As the driver is Free Software, it can be fixed. By the time 2.6.31 gets even to updates-testing, RPM Fusion will already have the patches. And, by the way, Fedora intentionally refuses to support out-of-tree kernel drivers, see also the FESCo decision some time ago to ban standalone kmod packages in Fedora and the rationale that was given (paraphrasing: we don't want kmods as we think out-of-tree kernel modules should not exist). (My personal opinion is that Free out-of-tree modules can be supported because they can be fixed if they're broken, proprietary ones are a wholely different issue though.) To bring it back to where we came in, we have a problem in that the KDE team are following one policy (update to the latest KDE release on the basis that it brings in new shiny goodness and fixes more stuff than it breaks) while the GNOME team are following the other (don't go to the latest point release in the interest of consistency). This doesn't make sense - if some parts of the distro are going with the adventurous policy, it renders the caution of other parts essentially null and void. The caution of the GNOME team doesn't really work, overall, if the kernel is following the adventurous policy. Conservative users still aren't going to go with Fedora. I think upgrading GNOME too should really be considered. But according to what our GNOME maintainers replied, it seems to be much more reliant on the very latest version of core system components than KDE is, so there appear to be good reasons for the current inconsistency. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20090806 changes
Compose started at Thu Aug 6 06:15:06 UTC 2009 Updated Packages: firefox-3.5.2-2.fc11 * Mon Aug 03 2009 Martin Stransky stran...@redhat.com - 3.5.2-2 - Updated to 3.5.2. gnome-web-photo-0.8-4.fc12 -- * Tue Aug 04 2009 Jan Horak jho...@redhat.com - 0.8-4 - Rebuild against newer gecko libtheora-1.1beta1-1.fc12 - * Wed Aug 05 2009 Matthias Clasen mcla...@redhat.com - 1.1beta1 - 1.1beta1 * Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1:1.1alpha2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild mozvoikko-0.9.7-0.7.rc1.fc12 * Tue Aug 04 2009 Jan Horak jho...@redhat.com - 0.9.7-0.7.rc1 - Rebuild against newer gecko xulrunner-1.9.1.2-1.fc11 yum-3.2.23-13.fc12 -- * Wed Aug 05 2009 Seth Vidal skvidal at fedoraproject.org - 3.2.23-13 - latest head - right after freeze Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 6 Broken deps for i386 -- 389-ds-1.1.3-4.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.i586 requires openmpi-libs asterisk-fax-1.6.1-0.24.rc1.fc12.i686 requires libspandsp.so.1 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-gtk-0.9.so.0 clutter-gtkmm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-gtk-0.9) cluttermm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 cluttermm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-0.9) dap-hdf4_handler-3.7.9-2.fc11.i586 requires libdap.so.9 dap-hdf4_handler-3.7.9-2.fc11.i586 requires libdapserver.so.6 entertainer-0.4.2-5.fc12.noarch requires pyclutter-cairo octave-forge-20080831-10.fc12.i686 requires octave(api) = 0:api-v32 perl-DBIx-Class-Schema-Loader-0.04006-4.fc12.noarch requires perl(DBIX::Class) php-layers-menu-3.2.0-0.2.rc.fc12.noarch requires php-pear(HTML_Template_PHPLIB) plplot-octave-5.9.4-1.fc12.i586 requires octave(api) = 0:api-v32 ppl-yap-0.10.2-5.fc12.i686 requires libYap.so python-repoze-what-quickstart-1.0-2.fc12.noarch requires python-repoze-who-plugins-sql qtparted-0.4.5-19.fc11.i586 requires libparted-1.8.so.8 rubygem-main-2.8.4-3.fc12.noarch requires rubygem(fattr) = 0:1.0.3 sems-1.1.1-2.fc12.i586 requires libspandsp.so.1 sems-g722-1.1.1-2.fc12.i586 requires libspandsp.so.1 sems-gsm-1.1.1-2.fc12.i586 requires libspandsp.so.1 sems-speex-1.1.1-2.fc12.i586 requires libspandsp.so.1 serpentine-0.9-5.fc12.noarch requires gnome-python2-nautilus-cd-burner showimg-pgsql-0.9.5-22.fc11.i586 requires libpqxx-2.6.8.so sugar-pippy-34-2.fc12.i686 requires libstdc++.so.6(CXXABI_1.3)(64bit) sugar-pippy-34-2.fc12.i686 requires libc.so.6()(64bit) sugar-pippy-34-2.fc12.i686 requires libgcc_s.so.1(GCC_3.0)(64bit) sugar-pippy-34-2.fc12.i686 requires libm.so.6()(64bit) sugar-pippy-34-2.fc12.i686 requires libm.so.6(GLIBC_2.2.5)(64bit) sugar-pippy-34-2.fc12.i686 requires libstdc++.so.6()(64bit) sugar-pippy-34-2.fc12.i686 requires libc.so.6(GLIBC_2.2.5)(64bit) sugar-pippy-34-2.fc12.i686 requires libstdc++.so.6(GLIBCXX_3.4)(64bit) sugar-pippy-34-2.fc12.i686 requires libgcc_s.so.1()(64bit) trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires trac-webadmin-plugin trac-customfieldadmin-plugin-0.1-0.1.svn5073.fc10.noarch requires python(abi) = 0:2.5 Broken deps for x86_64 -- 389-ds-1.1.3-4.fc12.noarch requires 389-ds-admin R-RScaLAPACK-0.5.1-19.fc11.x86_64 requires openmpi-libs asterisk-fax-1.6.1-0.24.rc1.fc12.x86_64 requires libspandsp.so.1()(64bit) clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8)
Re: rawhide report: 20090806 changes
On Thu, Aug 6, 2009 at 11:06 AM, Rawhide Reportrawh...@fedoraproject.org wrote: Compose started at Thu Aug 6 06:15:06 UTC 2009 Updated Packages: firefox-3.5.2-2.fc11 * Mon Aug 03 2009 Martin Stransky stran...@redhat.com - 3.5.2-2 - Updated to 3.5.2. gnome-web-photo-0.8-4.fc12 -- * Tue Aug 04 2009 Jan Horak jho...@redhat.com - 0.8-4 - Rebuild against newer gecko libtheora-1.1beta1-1.fc12 - * Wed Aug 05 2009 Matthias Clasen mcla...@redhat.com - 1.1beta1 - 1.1beta1 * Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1:1.1alpha2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild mozvoikko-0.9.7-0.7.rc1.fc12 * Tue Aug 04 2009 Jan Horak jho...@redhat.com - 0.9.7-0.7.rc1 - Rebuild against newer gecko xulrunner-1.9.1.2-1.fc11 yum-3.2.23-13.fc12 -- * Wed Aug 05 2009 Seth Vidal skvidal at fedoraproject.org - 3.2.23-13 - latest head - right after freeze This looks somewhat truncated. I have at least one new package that should be in the list :-( Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
Christopher Aillon wrote: Sure, you can blame Gecko for having it's unstable ABI be, well, unstable. But blame also goes to the apps for not using the stable ABI. Why does Mozilla expect apps to use an ABI: * which didn't exist when the apps were written and * which they aren't even using for their own apps? Everyone complains about M$ using internal W32 APIs in IE, why does Mozilla do the same with internal xulrunner APIs? If you think everyone should use the stable ABI, why is Firefox not using it? Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
Mark McLoughlin wrote: For fedora-virt folks, we have a virt-preview repository, the general idea being: - a repo where you can pull f11 builds of the latest rawhide virt bits - purely for people who want to help with testing f12 virt, but aren't willing to run rawhide - it's not about making new features available to f11 users, it's about allowing f11 users to get involved with f12 development - if it breaks, you get to keep both pieces - we'll do our best to fix problems specific to this repo, but in reality we care more about problems which affect stock f11 or rawhide/f12 - we're trying to keep the limit the packages in the repo to purely virt related packages - e.g. right now we need something from f12 selinux-policy, but I'm hoping we can get added in an f11 update rather than pulling in the f12 version and breaking non-virt stuff We have that too for KDE, it's called kde-redhat unstable. But it's not a replacement for stable, tested version upgrades. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, Aug 6, 2009 at 11:56 AM, Kevin Koflerkevin.kof...@chello.at wrote: Christopher Aillon wrote: Sure, you can blame Gecko for having it's unstable ABI be, well, unstable. But blame also goes to the apps for not using the stable ABI. Why does Mozilla expect apps to use an ABI: * which didn't exist when the apps were written and * which they aren't even using for their own apps? Everyone complains about M$ using internal W32 APIs in IE, who does that? why does Mozilla do the same with internal xulrunner APIs? If you think everyone should use the stable ABI, why is Firefox not using it? I don't see whats wrong with providing a an ABI that you can/want to support (i.e no ABI breaks for minor updates) and one for your internal use (i.e you know when it breaks and therefore fix your own app). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Thu, 2009-08-06 at 10:44 +0200, Ralf Corsepius wrote: On 08/06/2009 10:39 AM, Peter Robinson wrote: After requesting status updates, including direct email to the feature owners, the following feature pages do not have a current status or their ability to tested during the Alpha is unclear based on the lack of information provided or percentage of completion. https://fedoraproject.org/wiki/Features/FedoraMoblin I'm the maintainer of this. I think its very much in a similar category to gnome/kde. The only difference is there is some packages still awaiting review, about 2 that are actually critical, but moblin 2 like gnome etc are still in there development phase so its a moving target. IMO, this feature should be scratched, because the packages in question are of immature nature (... and of low packaging quality from my POV). Low packaging quality? I certainly don't think so, given the amount of time Peter spent on them, and the fact that they all seemed good enough to pass review. As for the feature being scrapped, the goal of it is to package the current sources of Moblin, which is what it's doing. If we removed all the beta software from Fedora, we wouldn't have much left... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
On 06.08.2009 11:34, drago01 wrote: On Thu, Aug 6, 2009 at 11:14 AM, Orcan Ogetbiloget.fed...@gmail.com wrote: On Thu, Aug 6, 2009 at 4:58 AM, drago01 wrote: On Thu, Aug 6, 2009 at 10:45 AM, Orcan Ogetbil wrote: I maintain those drivers at RPMFusion. I will be happy beyond imagination when the staging drivers are marked stable. They won't ever (the rt Vendor drivers) From my understanding, the staging tree of the kernel contains drivers that are being prepared to be included in the main kernel tree[1]. Correct me if I'm wrong. I'm not quite sure if I could catch what you meant. Are you being sarcastic, implying that the rt2xxx staging drivers will stay in the staging repo forever? I sure hope not :) Hey! Don't break my hopes! The rt vendor drivers are considered a dead end by the linux-wireless developers (just try to read the code and you would now why), the plan is to get rt2800pci and rt2800usb into shape and get them upstreamed. They get no support from the wireless developers at all, Greg added them to staging because they are better than no drivers. See the linux-wireless list for details. A small just for your information in addition to what drago said (which is all afaics correct): Some rough support for newrt ralink usb devices was added for 2.6.31; see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d53d9e67b55f6a9fc3f836c5c392eb41ce5676f4 for details like this commit-comment: Current problems: * Cannot scan 11n AP's * No TX during first minute after association * Broken Hardware encryption CU knurd -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/06/2009 10:55 AM, Rahul Sundaram wrote: On 08/06/2009 02:14 PM, Ralf Corsepius wrote: IMO, this feature should be scratched, because the packages in question are of immature nature (... and of low packaging quality from my POV). Be specific. This is not enough information to influence the decision at this stage. OK, more verbose: * In their present shape the packages are non-functional. According to the submitter, this is due to lack of upstream vs. Fedora integration. * IM (NSH) O, the packaging quality of the submitted packages is close to being inacceptable low. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/06/2009 12:32 PM, Bastien Nocera wrote: On Thu, 2009-08-06 at 10:44 +0200, Ralf Corsepius wrote: On 08/06/2009 10:39 AM, Peter Robinson wrote: After requesting status updates, including direct email to the feature owners, the following feature pages do not have a current status or their ability to tested during the Alpha is unclear based on the lack of information provided or percentage of completion. https://fedoraproject.org/wiki/Features/FedoraMoblin I'm the maintainer of this. I think its very much in a similar category to gnome/kde. The only difference is there is some packages still awaiting review, about 2 that are actually critical, but moblin 2 like gnome etc are still in there development phase so its a moving target. IMO, this feature should be scratched, because the packages in question are of immature nature (... and of low packaging quality from my POV). Low packaging quality? I certainly don't think so, given the amount of time Peter spent on them, and the fact that they all seemed good enough to pass review. Yes, they somehow sneeked through reviews. This doesn't invalidate what I said. It only proves my impression of Fedora quality standards being low and about the quality of reviews. As for the feature being scrapped, the goal of it is to package the current sources of Moblin, which is what it's doing. If we removed all the beta software from Fedora, we wouldn't have much left... Well, ... yes, we have a lot of semifunctional stuff in Fedora, which should never have been released. At least I am having the impression Fedora 11 has derailed more into a rawhide shapshot but an end-users suitable distro (which it once used to be). - But this is off-topic wrt. moblin. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
Adam Williamson awill...@redhat.com writes: To bring it back to where we came in, we have a problem in that the KDE team are following one policy (update to the latest KDE release on the basis that it brings in new shiny goodness and fixes more stuff than it breaks) while the GNOME team are following the other (don't go to the latest point release in the interest of consistency). This doesn't make sense The KDE packagers have decided that KDE is good enough at avoiding regressions that upgrading from 4.2 to 4.3 is reasonably safe. (Or alternatively, that KDE 4.2 was so bad that 4.3 could only be an improvement.) The Gnome packagers have the opposite views of Gnome. Those 2 views do not conflict, and even if the teams were using the exact same criteria, they could still come to those conclusions. You can only call it inconsistent if KDE and Gnome have exactly the same release policy and exactly the same history of bugs (or the absence of bugs). This is clearly not the case. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Thu, Aug 6, 2009 at 1:33 PM, Ralf Corsepiusrc040...@freenet.de wrote: On 08/06/2009 10:55 AM, Rahul Sundaram wrote: On 08/06/2009 02:14 PM, Ralf Corsepius wrote: IMO, this feature should be scratched, because the packages in question are of immature nature (... and of low packaging quality from my POV). Be specific. This is not enough information to influence the decision at this stage. OK, more verbose: * In their present shape the packages are non-functional. According to the submitter, this is due to lack of upstream vs. Fedora integration. * IM (NSH) O, the packaging quality of the submitted packages is close to being inacceptable low. Can you be more verbose on that one? Instead of hand waving its low quality -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
IMO, this feature should be scratched, because the packages in question are of immature nature (... and of low packaging quality from my POV). Be specific. This is not enough information to influence the decision at this stage. OK, more verbose: * In their present shape the packages are non-functional. According to the submitter, this is due to lack of upstream vs. Fedora integration. * IM (NSH) O, the packaging quality of the submitted packages is close to being inacceptable low. More verbose? You've made a comment on a single bug and the issue bought up has long been addressed. The issue that you mentioned was a pair of applets in a single package auto starting through the xdg autostart. I removed the autostart and plan to start them through the moblin session manger instead. Please don't make broad sweeping statements that are no where near the truth. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
Am Donnerstag, den 06.08.2009, 13:39 +0200 schrieb Ralf Corsepius: On 08/06/2009 12:32 PM, Bastien Nocera wrote: On Thu, 2009-08-06 at 10:44 +0200, Ralf Corsepius wrote: On 08/06/2009 10:39 AM, Peter Robinson wrote: After requesting status updates, including direct email to the feature owners, the following feature pages do not have a current status or their ability to tested during the Alpha is unclear based on the lack of information provided or percentage of completion. https://fedoraproject.org/wiki/Features/FedoraMoblin I'm the maintainer of this. I think its very much in a similar category to gnome/kde. The only difference is there is some packages still awaiting review, about 2 that are actually critical, but moblin 2 like gnome etc are still in there development phase so its a moving target. IMO, this feature should be scratched, because the packages in question are of immature nature (... and of low packaging quality from my POV). Low packaging quality? I certainly don't think so, given the amount of time Peter spent on them, and the fact that they all seemed good enough to pass review. Yes, they somehow sneeked through reviews. This doesn't invalidate what I said. It only proves my impression of Fedora quality standards being low and about the quality of reviews. Would you please be so kind and name names here? What packages and what reviews are you talking about? I asked you to write down the problems you found in bz and CC me, but so far I haven't received a mail. Instead you spend time on writing mails with abstract accusations to the list. As you know I'm really interested in improving both the packaging and the review quality and I appreciate your cooperation. Why not pick up some of the reviews? This is the easiest and fastest way to enforce your quality standards. TIA, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Wed, 2009-08-05 at 15:15 -0700, John Poelstra wrote: Hi FESCo, After requesting status updates, including direct email to the feature owners, the following feature pages do not have a current status or their ability to tested during the Alpha is unclear based on the lack of information provided or percentage of completion. https://fedoraproject.org/wiki/Features/Thusnelda The upstream release was a few days late since they actually test their stuff before release, but a feature-complete beta has been released yesterday, and in is in rawhide today. I have moved the feature to 90% since it is not the final 1.1 release yet, but for all practical matters, the Thusnelda feature should be considered complete now, just some bugfixing remains to be done. Matthias -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
Adam Williamson, Wed, 05 Aug 2009 14:26:53 -0700: Well, I think it's really the same issue. The problem is one of expectation: we have two similar components, GNOME and KDE, in the same distribution, following different update polices - GNOME favours stable, KDE favours adventurous. This confounds expectation. Yes, my problem is potentially almost solved with the tools at our disposal and some little tweaks to interfaces, except for the problem raised by Jesse, see my reply to his post. :) Adam, I see where you are coming from, but aside from the unclear definition of the Fedora's target audience (which is IMHO clearly defined as developers needing bleeding-edge distro with huge engineering support; we just live in denial for not saying so clearly) you are getting into much deeper organizational problem ... how manages Fedora. Actually, it seems to me the answer is no-one really ... this is really a community of packagers held together by very rough consensus and necessity to support each other. As such there is no such thing as corporate brand and expected behavior ... if KDE folks decide they want to package their packages (and they are their packages, not of the folks in the RH Desktop team) as they do and have multiple upgrades even for N-1 distros, it is only their business -- they will have to hold all pieces together if it blows up in their face. If Gnome folks decide to be more conservative (or conserving effort for Gnome 3.* and bigger stability of Gnome before Fedora 12 aka RHEL 6 Alpha) it is their business and nobody could them anything. I am not sure about Mandriva, I have never had it installed ever (even though I got kindly LiveUSB disk at Guadec 2007 -- it was wonderful free 3GB USB drive before I lost it ;-)), but if it is smaller distro, it could be true it was smaller community with more centrally controlled strategy? Or in other words ... read “Nature of the firm” (Coase, 1937) and “The Problem of Social Cost” (Coase, 1960) ... to understand one way how to get grasp of this community. In the situation where opportunity cost of cooperation is quite low, transaction cost is perceived as quite high, and cost of leaving the community quite low, there is no way how to centralize management of the community. There are some communities where it is possible to achieve *slightly* higher degree of centralization (Ubuntu, and possibly Mandriva), but certainly it is not the case of Fedora which is probably quite close to the extreme of market-driven organization (to use Coase's terminology). Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Wed, Aug 05, 2009 at 10:59:25PM -0700, Adam Williamson wrote: On Thu, 2009-08-06 at 05:37 +0200, Kevin Kofler wrote: Adam Williamson wrote: I probably couldn't do much justice to a comprehensive plan as I have insufficient knowledge of how the buildsystem works. I was acting at a higher level - just trying to point out that it's essentially doomed to try and please everyone with a single update repository, that's not an argument anyone can win. Either the 'we want stable updates' camp or the 'we want shiny new stuff' camp is going to be disappointed. The problem is that your solution doubles maintainer and rel-eng workload. I think we really don't have the resources for that. Please don't personalize things. It's not 'mine', and it's not really a solution. I'm simply pointing out that it's literally impossible to satisfy both possible update policies with a single unitary repository. You are under the impression that we have an update policy at all. We don't. So we have nothing to satisfy, which makes it very possible. We either have to make it clear which policy we use and which policy we don't, and hence which theoretical user base we are not targeting, or take on extra work and try to satisfy both. I am not declaring myself in Actually, we could do nothing and be just fine. Let the users decide if and when and what they want to update. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090806 changes
This looks somewhat truncated. I have at least one new package that should be in the list :-( We're in Freeze. If you didn't request a freeze tag, it won't get into the rawhide compose. Of course! I thought the alpha was going to be a running snapshot of rawhide without a freeze this time round, or did that not make it through the final hurdles? Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: License change for ghostscript
On 08/05/2009 07:15 PM, Gregory Maxwell wrote: So if you create a piece of software that can equally link to X or Y, and you never use/distribute X yourself you are simply not within reach of X's licensing terms. If someone else takes your software and X then sticks them on a CD, then they are obligated to follow X's license, which may include terms that make depends about the licensing of other software— ... software that links to it... software on the same media software in the same building ... software that starts with the same letter. Doesn't matter. Whatever the conditions are, they are the conditions for using X. If you can't simultaneously satisfy the requirements of X and the requirements of some other software package you'll have to stop distributing one or the other or risk litigation from whomevers requirements you're violating. This is another reason why in Fedora, we ensure that linked packages are compatible, but we don't try to label the license of a package based upon externally inherited licensing. The concept of what makes up a derived work in software is extremely complicated, and widely disputed, depending upon who you ask. There is also not a lot of case law in the US that would help provide clarification on how the courts would interpret things. The FSF is rather outspoken in their opinion that all linking creates a shared work, but that is simply their opinion. I would argue that there are probably many situations like the one Chris described where the software could clearly be argued to not be a derived work of either crypto API, or when a dependent library can be easily replaced with an ABI compatible alternative (either with a recompile or without). What if an application dlopens another library to use it? At the end of the day, the answer that any lawyer worth talking to will give you is that it depends on the specifics of the situation at hand. Red Hat Legal is comfortable with the general policies that we've adopted in Fedora, which is to ensure that there is license compatibility across shared library linking, with the exception of System Libraries. (I'm in the middle of trying to convince them that OpenSSL consists of a system library at this point, but we still haven't decided whether we're going to adopt that stance or not) ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
Bastien Nocera said the following on 08/05/2009 04:56 PM Pacific Time: On Wed, 2009-08-05 at 15:15 -0700, John Poelstra wrote: Hi FESCo, After requesting status updates, including direct email to the feature owners, the following feature pages do not have a current status or their ability to tested during the Alpha is unclear based on the lack of information provided or percentage of completion. snip https://fedoraproject.org/wiki/Features/Gnome2.28 snip Feature will obviously be done on time. The feature process doesn't seem so forgiving about things happening upstream rather than downstream... The feature process can be very forgiving when there is *information* on the feature page about how testable a particular feature is or further information what is left to be done past feature freeze. I don't currently have the ability to know what every upstream project is doing or know what every developer plans to do real soon now ;-) Thus it helps to add it to the feature page :) As a result my goal is to treat every feature page equally, using the information that has been provided on each page, in light of the feature process that everyone has agreed on. As always, the feature process is not written in stone and if there are ways the current process should be amended or changed I'm sure FESCo would be open to constructive suggestions to changing it and making it better. John -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090806 changes
On Thu, Aug 06, 2009 at 02:33:58PM +0100, Peter Robinson wrote: This looks somewhat truncated. I have at least one new package that should be in the list :-( We're in Freeze. If you didn't request a freeze tag, it won't get into the rawhide compose. Of course! I thought the alpha was going to be a running snapshot of rawhide without a freeze this time round, or did that not make it through the final hurdles? No-Frozen-Rawhide was deferred to Fedora 13. Another thing to keep in mind is that F12 Alpha is what we used to call Beta. Confusion abound! josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/06/2009 02:10 PM, Christoph Wickert wrote: Am Donnerstag, den 06.08.2009, 13:39 +0200 schrieb Ralf Corsepius: On 08/06/2009 12:32 PM, Bastien Nocera wrote: On Thu, 2009-08-06 at 10:44 +0200, Ralf Corsepius wrote: On 08/06/2009 10:39 AM, Peter Robinson wrote: After requesting status updates, including direct email to the feature owners, the following feature pages do not have a current status or their ability to tested during the Alpha is unclear based on the lack of information provided or percentage of completion. https://fedoraproject.org/wiki/Features/FedoraMoblin I'm the maintainer of this. I think its very much in a similar category to gnome/kde. The only difference is there is some packages still awaiting review, about 2 that are actually critical, but moblin 2 like gnome etc are still in there development phase so its a moving target. IMO, this feature should be scratched, because the packages in question are of immature nature (... and of low packaging quality from my POV). Low packaging quality? I certainly don't think so, given the amount of time Peter spent on them, and the fact that they all seemed good enough to pass review. Yes, they somehow sneeked through reviews. This doesn't invalidate what I said. It only proves my impression of Fedora quality standards being low and about the quality of reviews. Would you please be so kind and name names here? What packages and what reviews are you talking about? In this context, I am talking about all moblin package submissions by Mr. Robinson. I asked you to write down the problems you found in bz and CC me, but so far I haven't received a mail. I haven't received any mail from you. Instead you spend time on writing mails with abstract accusations to the list. Do you want me to flame people in public? As you know I'm really interested in improving both the packaging and the review quality and I appreciate your cooperation. Why not pick up some of the reviews? I did so, but Mr. Robinson refused to listen and preferred to go his way, because the fedora guidelines allow him to do so. It cause me to turn away from his reviews. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090806 changes
This looks somewhat truncated. I have at least one new package that should be in the list :-( We're in Freeze. If you didn't request a freeze tag, it won't get into the rawhide compose. Of course! I thought the alpha was going to be a running snapshot of rawhide without a freeze this time round, or did that not make it through the final hurdles? No-Frozen-Rawhide was deferred to Fedora 13. Another thing to keep in mind is that F12 Alpha is what we used to call Beta. Confusion abound! Oh yes, and I was even at Jesse's FudCon proposal talk in Berlin :-) Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
Would you please be so kind and name names here? What packages and what reviews are you talking about? In this context, I am talking about all moblin package submissions by Mr. Robinson. I asked you to write down the problems you found in bz and CC me, but so far I haven't received a mail. I haven't received any mail from you. Instead you spend time on writing mails with abstract accusations to the list. Do you want me to flame people in public? As you know I'm really interested in improving both the packaging and the review quality and I appreciate your cooperation. Why not pick up some of the reviews? I did so, but Mr. Robinson refused to listen and preferred to go his way, because the fedora guidelines allow him to do so. It cause me to turn away from his reviews. Not true. You mentioned it on a single package. I've filed over 30 for Moblin, and the _ONE_ issue you raised I fixed. There was certainly a discussion about it and I did see your point about it and the issue you raised has now been fixed. There was no refusal, there was discussion. All in the bug for all to see. I don't see how a single issue regarding the autostart of an applet is all moblin package submissions, please stop spreading FUD. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/06/2009 02:18 PM, drago01 wrote:
On Thu, Aug 6, 2009 at 1:33 PM, Ralf Corsepiusrc040...@freenet.de wrote:
* IM (NSH) O, the packaging quality of the submitted packages is close to
being inacceptable low.
Can you be more verbose on that one?
3 Examples:
1. He is running the autotools while building.
This renders building non-deterministic and exposes his packages to
suffer from build breakdowns due to the autotools changing behaviour,
rsp. due to the packages being tied to specific versions of the autotools.
2. Some of his packages contain abuses of %*dir variables.
e.g.:
%post
%{_bindir}/someotherscript
3. Some of his packages don't honor rpm input %*dir variables
(e.g. datadir), but rely on %{_prefix} only, despite they install to
%{_datadir}
Instead of hand waving its low quality
Ralf
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
ABI compliance checker
Colleagues, I'm software engineer from Institute for System Programing of Russian Academy of Sciences and we are developing a free lightweight tool for checking backward/forward binary compatibility of shared C/C++ libraries in OS Linux. It checks interface signatures and data type definitions in two library versions (headers and shared objects) and searches ABI changes that may lead to incompatibility. We have released 1.1 version of this tool and we'd like you to consider its usefulness for your project. The wiki-page with the latest release of binary compatibility checker is http://ispras.linux-foundation.org/index.php/ABI_compliance_checker Andrey Ponomarenko -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
On Thu, Aug 06, 2009 at 05:14:01AM -0400, Orcan Ogetbil wrote: On Thu, Aug 6, 2009 at 4:58 AM, drago01 wrote: On Thu, Aug 6, 2009 at 10:45 AM, Orcan Ogetbil wrote: I maintain those drivers at RPMFusion. I will be happy beyond imagination when the staging drivers are marked stable. They won't ever (the rt Vendor drivers) From my understanding, the staging tree of the kernel contains drivers that are being prepared to be included in the main kernel tree[1]. Correct me if I'm wrong. You are essentially wrong. The drivers in the staging tree may or may not make their way to the main kernel. I'm sure Greg and others hope that they will, and at least some of them probably will. Unfortunately, none of the wireless drivers there appear likely to do that. Beyond the normal atrociousness of the code common to nearly all of the vendor-supplied staging drivers, the wireless drivers also tend to ignore the wireless infrastructure supplied upstream. This includes both the mac80211 component of soft MAC devices and the cfg80211 configuration component for all wireless devices. As a community, we are refusing to accept drivers that duplicate the mac80211 functionality and now we are requiring the use of cfg80211 for new drivers as well. We simply can't afford to support multiple implementations of the soft MAC functionality and the older 'wireless extensions' API is too broken and bug-ridden for continued promulgation. The drivers in staging are best used as a guide to the workings of the hardware. I understand your desire for rt2860 and other devices to be supported, but the staging drivers just aren't acceptable. I would encourage you to put your efforts towards improving the rt2x00 driver family instead of propping-up the drivers in staging. Hth! John -- John W. LinvilleLinux should be at the core linvi...@redhat.com of your literate lifestyle. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
Am Donnerstag, den 06.08.2009, 16:14 +0200 schrieb Ralf Corsepius: On 08/06/2009 02:10 PM, Christoph Wickert wrote: I asked you to write down the problems you found in bz and CC me, but so far I haven't received a mail. I haven't received any mail from you. Instead you spend time on writing mails with abstract accusations to the list. Do you want me to flame people in public? No, I want constructive criticism in bugzilla. Flaming people in public is what you are currently doing on this list. As you know I'm really interested in improving both the packaging and the review quality and I appreciate your cooperation. Why not pick up some of the reviews? I did so, but Mr. Robinson refused to listen and preferred to go his way, because the fedora guidelines allow him to do so. It cause me to turn away from his reviews. Sorry, you didn't pick up any of the bugs, none was assigned to you. You picked on Peter, that's all. You only commented on two bugs regarding autoconf, but this is a controversial topic. Please accept that there are different views on questions like this one. Ralf Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
Am Donnerstag, den 06.08.2009, 16:20 +0200 schrieb Ralf Corsepius: On 08/06/2009 02:18 PM, drago01 wrote: On Thu, Aug 6, 2009 at 1:33 PM, Ralf Corsepiusrc040...@freenet.de wrote: * IM (NSH) O, the packaging quality of the submitted packages is close to being inacceptable low. Can you be more verbose on that one? 3 Examples: So where are your comments in bugzilla for example 2 and 3? I corrected Peter and Rahul, who did review one of the packages. Both were tankful for my corrections and incorporated the suggestions. Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABI compliance checker
On Thu, Aug 6, 2009 at 10:35 AM, Andrey Ponomarenkosusa...@ispras.ru wrote: Hi, Colleagues, I'm software engineer from Institute for System Programing of Russian Academy of Sciences and we are developing a free lightweight tool for checking backward/forward binary compatibility of shared C/C++ libraries in OS Linux. It checks interface signatures and data type definitions in two library versions (headers and shared objects) and searches ABI changes that may lead to incompatibility. We have released 1.1 version of this tool and we'd like you to consider its usefulness for your project. This sounds very useful! Ideally, we would run this tool automatically for the OS core and ABI changes would require signoff of some sort, and unless absolutely necessary were reverted. Tools like this though are at their most effective when they catch changes upstream not long after they're committed, before downstreams have at some indeterminate time incremented integers in .spec files or equivalent to distribute the changes. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
About mass bug filing for error output with --excludedocs
Please postpone fixing scriptlets for this issue until some conclusion gets reached on fedora-packaging-list. Regards, Mamoru -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
Ralf Corsepius wrote:
1. He is running the autotools while building.
It's your personal opinion that this is low quality, many other packagers
don't agree with their assertion and the guidelines (intentionally) don't
ban it.
FYI, all our KDE 3 packages reran the autotools during the build (KDE 3's
make cvs feature) and our KDE 3 compatibility packages still do. (KDE 4
doesn't use autotools, as you know.)
But we have had this discussion many times, it's getting boring. I'd really
appreciate if you stopped using your personal opinion as examples of bad
packaging quality.
2. Some of his packages contain abuses of %*dir variables.
e.g.:
%post
%{_bindir}/someotherscript
That's indeed unnecessary (why not just run the script without the absolute
path?), but not invalid either.
3. Some of his packages don't honor rpm input %*dir variables
(e.g. datadir), but rely on %{_prefix} only, despite they install to
%{_datadir}
That one should be fixed, the guidelines say to use macros where possible,
especially in cases like this. While %{_prefix}/share is not going to
produce a broken package, %{_datadir} is better (because it can change, as
unlikely as that is) and the reviewer should have pointed this out.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
1. He is running the autotools while building.
It's your personal opinion that this is low quality, many other packagers
don't agree with their assertion and the guidelines (intentionally) don't
ban it.
FYI, all our KDE 3 packages reran the autotools during the build (KDE 3's
make cvs feature) and our KDE 3 compatibility packages still do. (KDE 4
doesn't use autotools, as you know.)
But we have had this discussion many times, it's getting boring. I'd really
appreciate if you stopped using your personal opinion as examples of bad
packaging quality.
Agreed.
2. Some of his packages contain abuses of %*dir variables.
e.g.:
%post
%{_bindir}/someotherscript
That's indeed unnecessary (why not just run the script without the absolute
path?), but not invalid either.
Because I've probably picked up the scriptlet from somewhere else. If
its pointed out to me I fix most issues, but then as mentioned above
alot of that stuff comes down to personal choice and is neither right
or wrong.
3. Some of his packages don't honor rpm input %*dir variables
(e.g. datadir), but rely on %{_prefix} only, despite they install to
%{_datadir}
That one should be fixed, the guidelines say to use macros where possible,
especially in cases like this. While %{_prefix}/share is not going to
produce a broken package, %{_datadir} is better (because it can change, as
unlikely as that is) and the reviewer should have pointed this out.
I do believe I use the proper macros just about everywhere, certainly
I'm not perfect and will fix them if I miss something but its never
done intentionally, and fixed when pointed out.
Peter
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/06/2009 05:20 PM, Christoph Wickert wrote: Am Donnerstag, den 06.08.2009, 16:20 +0200 schrieb Ralf Corsepius: On 08/06/2009 02:18 PM, drago01 wrote: On Thu, Aug 6, 2009 at 1:33 PM, Ralf Corsepiusrc040...@freenet.de wrote: * IM (NSH) O, the packaging quality of the submitted packages is close to being inacceptable low. Can you be more verbose on that one? 3 Examples: So where are your comments in bugzilla for example 2 and 3? I turned away from supporting Mr. Robinson, ignored his reviews and left reviews to others ... I only noticed these issues in commits. Low quality reviews - QED. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/06/2009 05:16 PM, Christoph Wickert wrote: Am Donnerstag, den 06.08.2009, 16:14 +0200 schrieb Ralf Corsepius: On 08/06/2009 02:10 PM, Christoph Wickert wrote: I asked you to write down the problems you found in bz and CC me, but so far I haven't received a mail. I haven't received any mail from you. Instead you spend time on writing mails with abstract accusations to the list. Do you want me to flame people in public? No, I want constructive criticism in bugzilla. Flaming people in public is what you are currently doing on this list. As you know I'm really interested in improving both the packaging and the review quality and I appreciate your cooperation. Why not pick up some of the reviews? I did so, but Mr. Robinson refused to listen and preferred to go his way, because the fedora guidelines allow him to do so. It cause me to turn away from his reviews. Sorry, you didn't pick up any of the bugs, none was assigned to you. There is none assigned to me, because I turned away from this person's reviews. You can find traces of them in reviews. You picked on Peter, that's all. Well, your freedom to think so, my freedom to think otherwise -- I think, you are picking on _me_, because I am pronouncing something which doesn't fit into your wishful thinking. You only commented on two bugs regarding autoconf, but this is a controversial topic. Only within uneducated folks, without clues about the autotools. Please accept that there are different views on questions like this one. It's pretty easy to demonstrate the brokenness of running the autotools during builds. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, 2009-08-06 at 09:24 -0400, Josh Boyer wrote: We either have to make it clear which policy we use and which policy we don't, and hence which theoretical user base we are not targeting, or take on extra work and try to satisfy both. I am not declaring myself in Actually, we could do nothing and be just fine. Let the users decide if and when and what they want to update. Doing nothing is an implicit choice in favour of the adventurous option, with the disadvantage that we don't come out clearly and say it. It's rather hard to choose 'if and when and what' you want to update on a system that you only really talk to once a week that otherwise just sits there and does its job. For instance - a server, or a home theater box. I have both of these types of system. They're set to auto-update once a day, I don't spend my life logging into them by SSH, poring over the update list and deciding what to install. I can do this because the conservative update policy of the distribution they run gives me confidence that the updates won't break the things. I couldn't do that with Fedora, as there's no policy to give me the confidence that automatically updating such systems won't break them. As I've said, this isn't a _problem_ per se, but it means Fedora has a particular identity that we don't seem comfortable talking about - 'let's pretend not to make a choice' - for some reason. See what I mean? No choice is a choice. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, 2009-08-06 at 12:46 +, Matej Cepl wrote: Adam Williamson, Wed, 05 Aug 2009 14:26:53 -0700: Well, I think it's really the same issue. The problem is one of expectation: we have two similar components, GNOME and KDE, in the same distribution, following different update polices - GNOME favours stable, KDE favours adventurous. This confounds expectation. Yes, my problem is potentially almost solved with the tools at our disposal and some little tweaks to interfaces, except for the problem raised by Jesse, see my reply to his post. :) Adam, I see where you are coming from, but aside from the unclear definition of the Fedora's target audience (which is IMHO clearly defined as developers needing bleeding-edge distro with huge engineering support; we just live in denial for not saying so clearly) you are getting into much deeper organizational problem ... how manages Fedora. Actually, it seems to me the answer is no-one really ... this is really a community of packagers held together by very rough consensus and necessity to support each other. Actually I agree with you, I'd just really like this to be more out in the open and generally agreed-upon, so we can make saner decisions in certain cases and not have to worry about things we shouldn't need to worry about in the first place. It seems like we're happy to be that kind of distro _in effect_, but not to just come out and say it :) Don't be ashamed, people! We can come out of the closet! We're not your sysadmin's distro! ;) I am not sure about Mandriva, I have never had it installed ever (even though I got kindly LiveUSB disk at Guadec 2007 -- it was wonderful free 3GB USB drive before I lost it ;-)), but if it is smaller distro, it could be true it was smaller community with more centrally controlled strategy? There is slightly more central control possible in MDV's structure, but really I think the difference is just that MDV started off with a traditional update policy, properly enforced (there's a gatekeeper at MDV; official updates go through the security team, maintainers can't push them directly). So at MDV the process was to add a /backports repository to satisfy the adventurous tendency (which, by the way, took me a year and half to get done...). Fedora is the other way around. Or in other words ... read “Nature of the firm” (Coase, 1937) and “The Problem of Social Cost” (Coase, 1960) ... to understand one way how to get grasp of this community. In the situation where opportunity cost of cooperation is quite low, transaction cost is perceived as quite high, and cost of leaving the community quite low, there is no way how to centralize management of the community. This is rather a simplification. There is a degree of central control over Fedora. If you wanted to be cynical you could say it was based in Raleigh, but I'd never do such a thing ;). Otherwise we wouldn't be able to have packaging policies, release freezes...or releases, really. But I agree with the thrust of your argument, yeah. Oh, and the only non-fiction I read is the newspaper :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, Aug 06, 2009 at 09:43:03AM -0700, Adam Williamson wrote: On Thu, 2009-08-06 at 09:24 -0400, Josh Boyer wrote: We either have to make it clear which policy we use and which policy we don't, and hence which theoretical user base we are not targeting, or take on extra work and try to satisfy both. I am not declaring myself in Actually, we could do nothing and be just fine. Let the users decide if and when and what they want to update. Doing nothing is an implicit choice in favour of the adventurous option, with the disadvantage that we don't come out clearly and say it. Um, ok. I disagree, but hey we'll just go in circles. It's rather hard to choose 'if and when and what' you want to update on a system that you only really talk to once a week that otherwise just sits there and does its job. For instance - a server, or a home theater box. I have both of these types of system. They're set to auto-update once a day, I don't spend my life logging into them by SSH, poring over Personally, I don't care about meeting the needs of someone that wants to set their machine to auto-update so they can have warm fuzzies about it. We don't guarantee anything, we don't have official support contracts for Fedora, and as of right now we don't have the maintainer/QA/rel-eng manpower to even come close to making it safe to auto-update 100% of the time. See what I mean? No choice is a choice. Sure. It's called 'sticking with the status quo'. Which isn't all or nothing as you seem to want to paint it. It's left in the hands of the maintainers. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Thu, 2009-08-06 at 07:02 -0700, John Poelstra wrote: The feature process can be very forgiving when there is *information* on the feature page about how testable a particular feature is or further information what is left to be done past feature freeze. I don't currently have the ability to know what every upstream project is doing or know what every developer plans to do real soon now ;-) Thus it helps to add it to the feature page :) As a result my goal is to treat every feature page equally, using the information that has been provided on each page, in light of the feature process that everyone has agreed on. As always, the feature process is not written in stone and if there are ways the current process should be amended or changed I'm sure FESCo would be open to constructive suggestions to changing it and making it better. From the sidelines it seems that there is a confusion on what the % actually means. Some think that 100% means ready to be tested and others think that 100% means It's been tested, the final builds are in and all known and cared about bugs are fixed. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, 2009-08-06 at 10:20 +0100, Mark McLoughlin wrote: For fedora-virt folks, we have a virt-preview repository, the general idea being: - a repo where you can pull f11 builds of the latest rawhide virt bits - purely for people who want to help with testing f12 virt, but aren't willing to run rawhide - it's not about making new features available to f11 users, it's about allowing f11 users to get involved with f12 development - if it breaks, you get to keep both pieces - we'll do our best to fix problems specific to this repo, but in reality we care more about problems which affect stock f11 or rawhide/f12 - we're trying to keep the limit the packages in the repo to purely virt related packages - e.g. right now we need something from f12 selinux-policy, but I'm hoping we can get added in an f11 update rather than pulling in the f12 version and breaking non-virt stuff It hasn't been around long, but it's working well and we're getting valuable testing from it. The only thing we're missing is that we can't add virt-preview packages to the buildroot. We're considering switching from koji to mock for the builds because of this. With a little automation, I think this model could work fairly well for the likes of GNOME. This is essentially what I wanted to create with KoPeRs. https://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 'IT Security' in comps?
Till Maas (opensou...@till.name) said: The IT prefix is only used in the group id, which is afaik not visible to the used and not translated. No, it's not just in the description. These tools can be used to perform IT security related wireless auditing. In this example, IT security related (aside from missing a hyphen or two) is completely superfluous. I don't understand what you want to say with password recovery is password recovery. There is nothing to argue about, but nevertheles the groups are related to each other, How so? aide is not really related to password recovery at all, at least not in any generally describable way. already expresses itself that they are all on the security spin. Also it allows other people to easier ignore them, instead of cluttering other categories. Put it this way: - These packages are all in other groups under 'Base System' - Ergo, if they're being grouped together, the resulting group should still be under 'Base System' Tagging would help with this; as it stands now, 'yum search wireless' or 'yum search wireless sniffer' would return the packages in your wireless group. Probably, but this cannot be done right now afaik. yum search certainly can be done now. Moreover, what's the usage case in that you really need all three tools (which is the default if you install the group you mentioned)? Everyone on a multi user system can use the tool of his preference. ... So, the goal of this is for a multi-user forensic system, where you have multiple users working on the same system su-ing to root and running the tools of their choice? That's an odd usage case to design for by default. Also there may be a feature in one application, that is missing in another. Then fix one app so that it's reasonable enough. To quote Adam Jackson: Choice is not the goal. We have many interesting problems to solve and forcing the user to care about their choice of solutions is both bad UI and actively detracts from the real goal, which is making it work out of the box and enabling people to work on the really cool stuff at the edges. In comps, in most any group, the default item is the best-of-breed app; other implementations are optional. Btw. I fail to understand what trouble this is causing you. Thanks to bundling all together into one category, it will even disturb you less than six (or more) groups in some other category, where the stuff you are interested is. It's about not presenting bad UI and bad groups to our users - it's a design thing. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Wed, 2009-08-05 at 23:51 -0700, Adam Williamson wrote: To bring it back to where we came in, we have a problem in that the KDE team are following one policy (update to the latest KDE release on the basis that it brings in new shiny goodness and fixes more stuff than it breaks) while the GNOME team are following the other (don't go to the latest point release in the interest of consistency). This doesn't make sense - if some parts of the distro are going with the adventurous policy, it renders the caution of other parts essentially null and void. The caution of the GNOME team doesn't really work, overall, if the kernel is following the adventurous policy. Conservative users still aren't going to go with Fedora. If you stop looking at Fedora the repo of packages as a whole, and start looking at our discrete offerings, such as the Desktop spin and the KDE spin, you can start to find consistency within each of those spins. In the Desktop spin, you're going to see more conservative updates, mostly focused on pure bugfix releases with some notable exceptions like the kernel, but even that is fairly conservative. In the KDE spin you'll find more aggressive updates. This does actually match the environments quite well. Gnome targets the conservative, the ease of use, the minimal knobs to twist, the get out of my way and just let me work, where as KDE is really more about fine tuning and tweaking and turning one of the 4000 knobs 8° to the left and being more eager to get latest and greatest stuff. Perhaps we're failing to define a update policy because we have wildly divergent audiences, and we should be allowing SIGs that cater to these audiences define the policy that best suites their respective constituents. Defining Fedora is so darned hard because it's different things to so many different people. Diving down a bit deeper and defining Fedora Desktop vs Fedora KDE gets a bit easier to do. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
On Thu, 2009-08-06 at 11:34 +0200, drago01 wrote: I'm not quite sure if I could catch what you meant. Are you being sarcastic, implying that the rt2xxx staging drivers will stay in the staging repo forever? I sure hope not :) Hey! Don't break my hopes! The rt vendor drivers are considered a dead end by the linux-wireless developers (just try to read the code and you would now why), the plan is to get rt2800pci and rt2800usb into shape and get them upstreamed. They get no support from the wireless developers at all, Greg added them to staging because they are better than no drivers. Thanks for the clarification. From what I read, I inferred that the driver in /staging was the serialmonkey driver, but it seems I read it wrong, and what it actually means to say was 'this is the vendor driver, it sucks, don't contribute any code to this driver, contribute to the serialmonkey driver instead'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On 08/06/2009 09:43 AM, Adam Williamson wrote: On Thu, 2009-08-06 at 09:24 -0400, Josh Boyer wrote: We either have to make it clear which policy we use and which policy we don't, and hence which theoretical user base we are not targeting, or take on extra work and try to satisfy both. I am not declaring myself in Actually, we could do nothing and be just fine. Let the users decide if and when and what they want to update. Doing nothing is an implicit choice in favour of the adventurous option, with the disadvantage that we don't come out clearly and say it. It's rather hard to choose 'if and when and what' you want to update on a system that you only really talk to once a week that otherwise just sits there and does its job. For instance - a server, or a home theater box. I have both of these types of system. They're set to auto-update once a day, I don't spend my life logging into them by SSH, poring over the update list and deciding what to install. I can do this because the conservative update policy of the distribution they run gives me confidence that the updates won't break the things. I couldn't do that with Fedora, as there's no policy to give me the confidence that automatically updating such systems won't break them. As I've said, this isn't a _problem_ per se, but it means Fedora has a particular identity that we don't seem comfortable talking about - 'let's pretend not to make a choice' - for some reason. See what I mean? No choice is a choice. In writing my reply, I figured out where the disconnect is between what you're seeing and what I'm seeing. You're looking at this from the user's point of view. In that case, a hands off policy does make it more likely that the user will have an adventurous experience rather than a conservative experience even if one segment of the maintainer community (the desktop team) is doing its best to play a conservative role. I think we'd be happy to admit to the end users that that's the kind of distro we are and that CentOS/RHEL may be a better venue for the machines that they want to take a hands-off, everything works today and so everything will work tomorrow and the next day approach. We currently tell people to run CentOS or RHEL for the machines in that use case because of the 13 month EOL period anyway. The viewpoint that you also have to see, though, is the packager viewpoint. From within we don't all agree on whether we should have a conservative or an adventurous update policy. As the specifics of whether to update KDE and whether to update GNOME demonstrate, different sets of maintainers want the opposite strategies. Mandating that maintainers will either follow the conservative or the adventurous or follow both the conservative and the adventurous update path may satisfy the most users but leaves the maintainers disgruntled. Being clear that how we're messaging this to the users isn't affecting how the maintainers get to handle their individual packages in this case makes sense. I'm going to note, though, that this still doesn't address the original poster's question or thorsten's followup -- some areas of our distribution will still follow a conservative update policy as long as we give individual maintainers the leeway to use their best judgement. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Wed, 2009-08-05 at 20:30 -0400, Matthias Clasen wrote: On Thu, 2009-08-06 at 00:56 +0100, Bastien Nocera wrote: I'll make sure one of the Desktop-y guys updates this (presumably Matthias). I've updated it recently and bumped it to 75%. It would seem disingenuous to bump it to 100% when GNOME 2.28 has not been released yet. It is fine for the feature wrangler to propose it for removal. But I certainly hope that Fesco will not only look at pretty meaningless percentages, but at precedents and schedule alignments. I think the correct question here is why has a perfectly routine version bump for components included in Fedora been submitted as a 'feature'? If GNOME 2.28 is a feature, isn't KDE 4.3 a feature (oh, I see it is too, lovely...), kernel 2.6.31 a feature...every new version of everything in the distro a feature? What benefit does applying the feature process to a routine update like this bring, to offset its clear inconsistency? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/06/2009 12:37 PM, Adam Williamson wrote: I think the correct question here is why has a perfectly routine version bump for components included in Fedora been submitted as a 'feature'? I figure it's largely about which items of the distro gets focus marketing-wise. -- Rex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
Adam Williamson wrote: As I said, the particular code isn't the issue. We ship a kernel API. At present, we consider it fine to break that API in stable releases. This is not something that would be considered 'stable' in a traditional definition. The kernel's just an example, we do the same kind of non-stable updates all over the place. That's the issue I'm trying to talk about, not just the specific example I happened to mention. Please don't bog down in specifics. Well, the specifics are that packages both within Fedora and in third-party repositories which depend on the bumped API usually get rebuilt (and patched if needed) fairly quickly, normally before the update even goes stable. Of course that's only possible for software which can be patched, which is just another example of how binary-only software is broken by design. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
The feature process can be very forgiving when there is *information* on the feature page about how testable a particular feature is or further information what is left to be done past feature freeze. I don't currently have the ability to know what every upstream project is doing or know what every developer plans to do real soon now ;-) Thus it helps to add it to the feature page :) As a result my goal is to treat every feature page equally, using the information that has been provided on each page, in light of the feature process that everyone has agreed on. As always, the feature process is not written in stone and if there are ways the current process should be amended or changed I'm sure FESCo would be open to constructive suggestions to changing it and making it better. From the sidelines it seems that there is a confusion on what the % actually means. Some think that 100% means ready to be tested and others think that 100% means It's been tested, the final builds are in and all known and cared about bugs are fixed. My understanding was the later. All working tested and ready to go. What is it meant to mean. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
Peter Robinson (pbrobin...@gmail.com) said: From the sidelines it seems that there is a confusion on what the % actually means. Some think that 100% means ready to be tested and others think that 100% means It's been tested, the final builds are in and all known and cared about bugs are fixed. My understanding was the later. All working tested and ready to go. What is it meant to mean. Yeah, I think this is sort of an issue with pushing everything down to a simple number. In my view, '100%' would mean I'm done with this, and not touching it modulo bugs. It can have a lower percentage and still be testable. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
Am Donnerstag, den 06.08.2009, 18:14 +0200 schrieb Ralf Corsepius: Low quality reviews - QED. I can't stand lousy reviews ether, I often comment on already closed reviews in order to show the reviewers problems they did not catch. Someone even said what I did was a witch-hunting him, but nevertheless he was open to constructive criticism. Please be so kind as to name numbers and individual problems. Otherwise, we cannot improve. TIA, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Wed, 2009-08-05 at 15:15 -0700, John Poelstra wrote: https://fedoraproject.org/wiki/Features/DisplayPort I updated this a few days ago. I guess it's still not good enough to be called a feature? I really don't know how much more testing instructions I need to provide, and it seems disingenuous to call it 100% when there's almost certainly bugs remaining and hardware we don't support right. But if this is just a feature for the sake of release notes, then sure, drop it from the list. - ajax signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, 2009-08-06 at 10:27 -0700, Jesse Keating wrote: Perhaps we're failing to define a update policy because we have wildly divergent audiences, and we should be allowing SIGs that cater to these audiences define the policy that best suites their respective constituents. Defining Fedora is so darned hard because it's different things to so many different people. Diving down a bit deeper and defining Fedora Desktop vs Fedora KDE gets a bit easier to do. I definitely see what you're saying, and yeah, perhaps an issue is that we don't have enough of a separate identity for the separate spins. We don't have Kedora and Gedora (or Dedora, if you like ;), we have Fedora...but still, there's enough updates pushed even in packages in the Desktop spin which wouldn't go through in a more conventionally defined update process (ask yourself if RHEL would ship 'em :). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, 2009-08-06 at 11:31 -0700, Adam Williamson wrote: I definitely see what you're saying, and yeah, perhaps an issue is that we don't have enough of a separate identity for the separate spins. We don't have Kedora and Gedora (or Dedora, if you like ;), we have Fedora...but still, there's enough updates pushed even in packages in the Desktop spin which wouldn't go through in a more conventionally defined update process (ask yourself if RHEL would ship 'em :). That's not a useful argument. There is a huge difference between what RHEL would ship, and a conservative bugfix update. RHEL typically requires a paying customer contacting support about an issue, escalation from there, 3 levels of ACK/NACK decisions, and finally gobs of QA on a package before it ever goes out. Vastly different than what we do in Fedora, even for conservative updates. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, 2009-08-06 at 10:31 -0700, Toshio Kuratomi wrote: See what I mean? No choice is a choice. In writing my reply, I figured out where the disconnect is between what you're seeing and what I'm seeing. You're looking at this from the user's point of view. Yes, you could say I have a nasty habit of doing that. ;) Actually I try and look at things from many points of view, but the user's point of view is a rather important one. We're _all_ users, even those of us who are also maintainers. Each maintainer only maintains a little bit of the distro. With regard to all the other packages we don't maintain, we're users. Imagine two staff members in a store discussing an issue, then one turning to the other and saying ohhh, I get it. You're thinking about the CUSTOMER'S point of view! :D In that case, a hands off policy does make it more likely that the user will have an adventurous experience rather than a conservative experience even if one segment of the maintainer community (the desktop team) is doing its best to play a conservative role. I think we'd be happy to admit to the end users that that's the kind of distro we are and that CentOS/RHEL may be a better venue for the machines that they want to take a hands-off, everything works today and so everything will work tomorrow and the next day approach. We currently tell people to run CentOS or RHEL for the machines in that use case because of the 13 month EOL period anyway. Well, I'd be happy if we did that, yes. I guess the best thing would be to take some kind of proposal to the appropriate committee that we just write up a document, for the wiki or fedoraproject.org or wherever's appropriate, to make it clear that we don't have a conservative update policy, and that we don't expect users to be able to treat Fedora like a CentOS/RHEL/Debian stable/whatever-style operating system, from an update point of view. The viewpoint that you also have to see, though, is the packager viewpoint. From within we don't all agree on whether we should have a conservative or an adventurous update policy. As the specifics of whether to update KDE and whether to update GNOME demonstrate, different sets of maintainers want the opposite strategies. Mandating that maintainers will either follow the conservative or the adventurous or follow both the conservative and the adventurous update path may satisfy the most users but leaves the maintainers disgruntled. Yes, I agree, it wasn't my intent to suggest that. Even in the combined case, maintainers always have the choice to not bother to ship adventurous updates, and even if we specify that we don't guarantee conservative updates, maintainers who don't want to do adventurous updates aren't compelled to. I just want to be clear about how the big picture looks to users in each of these cases, and try for consistent messaging on whichever path we end up on, so users know what they can expect from Fedora. I'm going to note, though, that this still doesn't address the original poster's question or thorsten's followup -- some areas of our distribution will still follow a conservative update policy as long as we give individual maintainers the leeway to use their best judgement. Yes, you're right there. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
Thanks for the clarification. From what I read, I inferred that the driver in /staging was the serialmonkey driver, but it seems I read it wrong, and what it actually means to say was 'this is the vendor driver, it sucks, don't contribute any code to this driver, contribute to the serialmonkey driver instead'. I had the same confusion. So there are 3 drivers around: The vendor driver, the staging driver which is a fork of the vendor driver and the serialmonkey driver. Multiply that by 3 for rt2860, rt2870 and rt3070. And this leads to another confusion. Do (or will) the Fedora kernels have these staging drivers compiled by default? If that's the case and if the staging driver is as stable as the original vendor driver, I won't have to maintain those kmods anymore. The fedora kernel developers have always stated that the staging/vendor drivers will never get enabled. Only once the other ones are ready will they be turned on. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
On Thu, Aug 06, 2009 at 07:52:43PM +0100, Peter Robinson wrote: Thanks for the clarification. From what I read, I inferred that the driver in /staging was the serialmonkey driver, but it seems I read it wrong, and what it actually means to say was 'this is the vendor driver, it sucks, don't contribute any code to this driver, contribute to the serialmonkey driver instead'. I had the same confusion. So there are 3 drivers around: The vendor driver, the staging driver which is a fork of the vendor driver and the serialmonkey driver. Multiply that by 3 for rt2860, rt2870 and rt3070. And this leads to another confusion. Do (or will) the Fedora kernels have these staging drivers compiled by default? If that's the case and if the staging driver is as stable as the original vendor driver, I won't have to maintain those kmods anymore. The fedora kernel developers have always stated that the staging/vendor drivers will never get enabled. Only once the other ones are ready will they be turned on. No we haven't, we've stated that they'll be enabled if someone steps up to the plate to make an active contribution to maintenance and improvements. https://fedoraproject.org/wiki/KernelStagingPolicy regards, Kyle -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Thu, 2009-08-06 at 11:14 -0700, Jesse Keating wrote: On Thu, 2009-08-06 at 10:37 -0700, Adam Williamson wrote: I think the correct question here is why has a perfectly routine version bump for components included in Fedora been submitted as a 'feature'? If GNOME 2.28 is a feature, isn't KDE 4.3 a feature (oh, I see it is too, lovely...), kernel 2.6.31 a feature...every new version of everything in the distro a feature? What benefit does applying the feature process to a routine update like this bring, to offset its clear inconsistency? routine version bump may actually introduce new and exciting features, and may need coordination across a wide range of users and testers. Ergo, Fedora Feature. Again, that applies to _everything in the distro_. I don't think 'it's a new version' can be a feature. If we identify something particular within the GNOME or KDE package set which is a significant enough change to qualify as a Fedora feature, fine, submit it as such. But just declaring the entire version upgrade to be a feature seems a bit weird to me. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, 2009-08-06 at 11:35 -0700, Jesse Keating wrote: I definitely see what you're saying, and yeah, perhaps an issue is that we don't have enough of a separate identity for the separate spins. We don't have Kedora and Gedora (or Dedora, if you like ;), we have Fedora...but still, there's enough updates pushed even in packages in the Desktop spin which wouldn't go through in a more conventionally defined update process (ask yourself if RHEL would ship 'em :). That's not a useful argument. There is a huge difference between what RHEL would ship, and a conservative bugfix update. RHEL typically requires a paying customer contacting support about an issue, escalation from there, 3 levels of ACK/NACK decisions, and finally gobs of QA on a package before it ever goes out. Vastly different than what we do in Fedora, even for conservative updates. OK, bad example, but you know what I mean. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 'IT Security' in comps?
On Thu, Aug 06, 2009 at 01:24:24PM -0400, Bill Nottingham wrote: Till Maas (opensou...@till.name) said: The IT prefix is only used in the group id, which is afaik not visible to the used and not translated. No, it's not just in the description. These tools can be used to perform IT security related wireless auditing. In this example, IT security related (aside from missing a hyphen or two) is completely superfluous. 1) It is not a prefix in the description 2) It does not allow easy selection of the packages, which was the feature you said that it allows to have and which is the necessary context you removed: | I'm not sure they need to be bundled. Especially with 'IT' as a | prefix; 3) The description will be translated / meant to be human readable and not to be a machine readible property. I don't understand what you want to say with password recovery is password recovery. There is nothing to argue about, but nevertheles the groups are related to each other, How so? aide is not really related to password recovery at all, at least not in any generally describable way. So the assignement of tools to the groups can be improved. Does this make the groups useless? I say no, there I don't see how this does belong to this general discussion about whether or not there should be these groups in comps. already expresses itself that they are all on the security spin. Also it allows other people to easier ignore them, instead of cluttering other categories. Put it this way: - These packages are all in other groups under 'Base System' - Ergo, if they're being grouped together, the resulting group should still be under 'Base System' It is not technically possible to have subgroups, as you can see in the answer from Jesse Keating. Tagging would help with this; as it stands now, 'yum search wireless' or 'yum search wireless sniffer' would return the packages in your wireless group. Probably, but this cannot be done right now afaik. yum search certainly can be done now. Yes, but is there an easy search expression that will result with the groups that I added? Afaik no. Does 'yum search wireless' returns 43 lines of packages, so it does not qualify. Moreover, what's the usage case in that you really need all three tools (which is the default if you install the group you mentioned)? Everyone on a multi user system can use the tool of his preference. ... So, the goal of this is for a multi-user forensic system, where you have multiple users working on the same system su-ing to root and running the tools of their choice? That's an odd usage case to design for by default. Afaics I did not mention the forensics group. I can't answer your questions if you refer to different groups with the group and then argue against the answer using some other group. The forensics group had 15 packages in it if I counted correclty and e.g. pdfresurect and chkrootkit are completely different applications. But how does searching for good or bad examples help here? Also there may be a feature in one application, that is missing in another. Then fix one app so that it's reasonable enough. To quote Adam Jackson: In reality, one does not very often have the time to first fix a bug, before a task can be completed. So this does not help me right now if I need to perform a task. Nevertheles the fixing can still be done later. Choice is not the goal. We have many interesting problems to solve and forcing the user to care about their choice of solutions is both bad UI and actively detracts from the real goal, which is making it work out of the box and enabling people to work on the really cool stuff at the edges. I do not know users who prefer to wait several days to months to perform a task with one application instead of doing it with another application. Especially not if the need to perform the task right now. In comps, in most any group, the default item is the best-of-breed app; other implementations are optional. I see, comps is not the right place to implement the feature that fulfills my need. Btw. I fail to understand what trouble this is causing you. Thanks to bundling all together into one category, it will even disturb you less than six (or more) groups in some other category, where the stuff you are interested is. It's about not presenting bad UI and bad groups to our users - it's a design thing. I do not agree that my groups are bad or that they are bad by their nature. Nevertheless, I do not see that this discussion is leading anywhere, that will allow to fulfill my needs (Easy installation of the software, easy finding of the software, allowing many people to do this and not maintaining the same information in several places) and your requests. Also it looks for me that you do not want these groups at any cost, because of the way you argue. In conclusion I have reverted the IT-security related changes to the
Re: non root X
On Thu, 2009-08-06 at 01:36 -0400, Ben Boeckel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Airlie wrote: On Mon, 2009-08-03 at 15:08 +0530, Rahul Sundaram wrote: Hi A few days back I ran into http://lists.x.org/archives/xorg-devel/2009-July/001293.html I am wondering, since we are already using KMS in most places in Fedora, how far are we from achieving this by default in a Fedora release? non-root X is a big security hole at the moment, and until we get revoke() support in the kernel, we can probably move X to running as a special user, and maybe once we get revoke to running as the real user. However it doesn't solve the issue how we know we need or don't need root since X only figures out what graphics drivers are needed after starting, so if you needed a non-kms gpu driver we wouldn't know until after we'd started as non-root. Dave. Could permissions be raised temporarily? PolicyKit with (defaulted) auto-approve to load an appropriate driver? Maybe we could do something with SELinux, but I don't think we can do anything without getting revoke. or maybe some process capabilties if such things worked. Dave. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
Ralf Corsepius, Thu, 06 Aug 2009 18:14:47 +0200: I turned away from supporting Mr. Robinson, ignored his reviews and left reviews to others So you lost your right to slander him now. Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rt2860 driver (fc11)
I had the same confusion. So there are 3 drivers around: The vendor driver, the staging driver which is a fork of the vendor driver and the serialmonkey driver. Multiply that by 3 for rt2860, rt2870 and rt3070. And this leads to another confusion. Do (or will) the Fedora kernels have these staging drivers compiled by default? If that's the case and if the staging driver is as stable as the original vendor driver, I won't have to maintain those kmods anymore. The fedora kernel developers have always stated that the staging/vendor drivers will never get enabled. Only once the other ones are ready will they be turned on. No we haven't, we've stated that they'll be enabled if someone steps up to the plate to make an active contribution to maintenance and improvements. https://fedoraproject.org/wiki/KernelStagingPolicy Sorry, hadn't seen that. Was basing it on the comment in this bug https://bugzilla.redhat.com/show_bug.cgi?id=463111 Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
Adam Williamson, Thu, 06 Aug 2009 09:38:43 -0700: Oh, and the only non-fiction I read is the newspaper :) Not only I was a lawyer, I was even in a PhD student in sociology/ criminology in my previous life. :) Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: non root X
On Fri, 2009-08-07 at 05:04 +1000, Dave Airlie wrote: On Thu, 2009-08-06 at 01:36 -0400, Ben Boeckel wrote: Could permissions be raised temporarily? PolicyKit with (defaulted) auto-approve to load an appropriate driver? Maybe we could do something with SELinux, but I don't think we can do anything without getting revoke. or maybe some process capabilties if such things worked. SELinux, as a rule, does not grant rights, only removes them. - ajax signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Thu, 2009-08-06 at 11:41 -0700, Adam Williamson wrote: Again, that applies to _everything in the distro_. I don't think 'it's a new version' can be a feature. If we identify something particular within the GNOME or KDE package set which is a significant enough change to qualify as a Fedora feature, fine, submit it as such. But just declaring the entire version upgrade to be a feature seems a bit weird to me. And not declaring, testing, and coordinating version updates of key sets of software such as Gnome and KDE also seems weird to me. Listing the included versions of these desktops is a time honored tradition for Linux distros, without which the constant questions are what version of $foo does it include?. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, 2009-08-06 at 11:39 -0700, Adam Williamson wrote: But we're providing an operating system, not just a bunch of packages. What if some group's written their own kernel module for their own purposes, rolled it out to all their systems, and doesn't expect an official update to make them re-write it? Same question for KDE - someone writes a tool for their group based on some KDE libraries, doesn't expect an update to come along and do a major KDE version bump and break some interface the tool relied on...reducing the question to 'are all the packages we care about okay' is, again, excluding some use cases, i.e. defining an identity for Fedora. We're providing a bunch of packages, that certain groups use to make a variety of operating systems. If you want to develop a tool and expect that it'll keep working on any given release without aggressive changes underneath, pick the Fedora Desktop operating system. If you want to run with the latest and greatest regardless of change risk, try the Fedora KDE operating system. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 'IT Security' in comps?
On Thu, Aug 06, 2009 at 12:24:18PM +0530, Rahul Sundaram wrote: On 08/06/2009 02:37 AM, Till Maas wrote: The IT prefix is only used in the group id, which is afaik not visible to the used and not translated. That's not true. yum -v grouplist will display them. I use them all the time as a shorter form of the full group names. Something like # yum install @xfce-desktop Thanks, this is very helpful. Regards Till pgpmNwQUbTxST.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Thu, 2009-08-06 at 11:41 -0700, Adam Williamson wrote: Again, that applies to _everything in the distro_. I don't think 'it's a new version' can be a feature. If we identify something particular within the GNOME or KDE package set which is a significant enough change to qualify as a Fedora feature, fine, submit it as such. But just declaring the entire version upgrade to be a feature seems a bit weird to me. A good example of the weirdness here - we're declaring KDE 4.3 a 'Fedora 12 feature' (implying it's something sufficiently potentially problematic that it needs a specific test plan and contingency plan), yet backporting it to Fedora 10 as an official update meets with widespread approval and 'nothing wrong with that!' comments... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, Aug 06, 2009 at 11:39:16AM -0700, Adam Williamson wrote: On Thu, 2009-08-06 at 20:00 +0200, Kevin Kofler wrote: Adam Williamson wrote: As I said, the particular code isn't the issue. We ship a kernel API. At present, we consider it fine to break that API in stable releases. This is not something that would be considered 'stable' in a traditional definition. The kernel's just an example, we do the same kind of non-stable updates all over the place. That's the issue I'm trying to talk about, not just the specific example I happened to mention. Please don't bog down in specifics. Well, the specifics are that packages both within Fedora and in third-party repositories which depend on the bumped API usually get rebuilt (and patched if needed) fairly quickly, normally before the update even goes stable. Of course that's only possible for software which can be patched, which is just another example of how binary-only software is broken by design. But we're providing an operating system, not just a bunch of packages. What if some group's written their own kernel module for their own purposes, rolled it out to all their systems, and doesn't expect an official update to make them re-write it? Same question for KDE - If they don't expect that, they have no idea what Fedora is or how it works. We don't care about out of tree drivers. someone writes a tool for their group based on some KDE libraries, doesn't expect an update to come along and do a major KDE version bump and break some interface the tool relied on...reducing the question to 'are all the packages we care about okay' is, again, excluding some use cases, i.e. defining an identity for Fedora. You keep making strawman arguments that liken Fedora to something more akin to RHEL or Ubuntu LTS. We aren't either of those. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, 2009-08-06 at 12:06 -0700, Adam Williamson wrote: OK, bad example, but you know what I mean. Yes, I do, and I think there is room for a Fedora offering that is released frequently (every 6 months), supported for about a year, with conservative updates to the platform. That's nearly exactly what we have in Fedora Desktop. There is also room for a Fedora offering that is released frequently (every 6 months), supported for about a year, with aggressive updates to the latest and greatest for the platform. That's nearly exactly what we have in Fedora KDE. The real problem is going to be when somebody wants to make an offering that features GNOME but has aggressive updates to latest and greatest GNOME on every update stream, as that cannot coexist with the conservative Fedora Desktop. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Make upstream release monitoring (the service formerly known as FEVer) opt-out?
Hiyas, currently upstream release monitoring[0] bug filing is opt-in, which means that it will be only performed for packages that have been activly added by probably a maintainer of the package. There is at least one maintainer that does not like having these bugs filed for his packages, so he can remove his packages from the list. It might be easily possible in the future to monitor a bunch more packages and create bugs in case there are newer versions available at upstream. Would it be ok, to do this and allow maintainers to add there package to a black list, so that no bugs will be filed or should it continue to be opt-in? Then the packags will still be checked, but only reported by other, non intrusive ways, e.g. via a website. Regards Till [0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring pgpbOvtHTy8yY.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Thu, Aug 06, 2009 at 11:41:20AM -0700, Adam Williamson wrote: On Thu, 2009-08-06 at 11:14 -0700, Jesse Keating wrote: On Thu, 2009-08-06 at 10:37 -0700, Adam Williamson wrote: I think the correct question here is why has a perfectly routine version bump for components included in Fedora been submitted as a 'feature'? If GNOME 2.28 is a feature, isn't KDE 4.3 a feature (oh, I see it is too, lovely...), kernel 2.6.31 a feature...every new version of everything in the distro a feature? What benefit does applying the feature process to a routine update like this bring, to offset its clear inconsistency? routine version bump may actually introduce new and exciting features, and may need coordination across a wide range of users and testers. Ergo, Fedora Feature. Again, that applies to _everything in the distro_. I don't think 'it's a new version' can be a feature. If we identify something particular within the GNOME or KDE package set which is a significant enough change to qualify as a Fedora feature, fine, submit it as such. But just declaring the entire version upgrade to be a feature seems a bit weird to me. Features are about publicity. There is value in saying Fedora NN comes with Frobit 3.14!, if Frobit is a rather popular package. Doubly so if Fedora NN is the first distro to ship it. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Thu, 2009-08-06 at 12:24 -0700, Jesse Keating wrote: On Thu, 2009-08-06 at 11:41 -0700, Adam Williamson wrote: Again, that applies to _everything in the distro_. I don't think 'it's a new version' can be a feature. If we identify something particular within the GNOME or KDE package set which is a significant enough change to qualify as a Fedora feature, fine, submit it as such. But just declaring the entire version upgrade to be a feature seems a bit weird to me. And not declaring, testing, and coordinating version updates of key sets of software such as Gnome and KDE also seems weird to me. Listing the included versions of these desktops is a time honored tradition for Linux distros, without which the constant questions are what version of $foo does it include?. Sure, and I was always happy to write in GNOME and KDE versions as 'Features' when writing release blurbs for Mandriva. But that's just pure PR. PR is not all our feature process does - it comes with all this bureaucracy, intended for dealing with experimental stuff which may turn out to have been a bad idea, attached to it, it's _not_ a pure PR exercise. Which leads to the absurdity we have here, the suggestion that the GNOME 2.28 'feature' should be 'dropped' for Fedora 12 (does anyone really think we're going to ship it with GNOME 2.26?) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, 2009-08-06 at 12:26 -0700, Jesse Keating wrote: We're providing a bunch of packages, that certain groups use to make a variety of operating systems. If you want to develop a tool and expect that it'll keep working on any given release without aggressive changes underneath, pick the Fedora Desktop operating system. Except that doesn't work, because we still change stuff out from under you on Desktop. See the kernel example. There's others. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
