Re: Fedora 12 Features Proposed for Removal
On 08/06/2009 08:50 PM, Christoph Wickert wrote: > I corrected Peter and Rahul, who did review one of the packages. Both > were tankful for my corrections and incorporated the suggestions. That is because they were specific and were things that were in the guidelines. It takes the personalities out of the equation and puts the technical issues upfront. Generalizations such as "All X packages are bad" are obviously not helpful and extrapolating from a few minor things to claims like that are wrong and doesn't help improve quality but discourages people from contributing. If one believes strongly that running autotools from spec files should be banned but there is no consensus on that, then the only way to change the status quo on this is to propose a draft to the packaging committee with a considerable number of specific examples on why this is a problem. Pointing it out on a review and restoring to calling the packages bad quality if people don't follow your controversial recommendation isn't going to scale at all. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On 08/07/2009 11:51 AM, Jeff Spaleta wrote: > On Thu, Aug 6, 2009 at 10:11 PM, Rahul > Sundaram wrote: >> >> I would prefer the system to be opt-out. For completely new maintainers >> or anyone maintaining more than a few packages, it certainly is very >> useful to get notification via bugzilla about new upstream releases. > > Err, uhm...I'd rather not see bugzilla overloaded with this sort of > notification. But I would LOVE to see this integrated as notification > information into the Fedora Community portal concept. > > I know a lot of us rely on bugzilla as the mainstay to a lot of our > workflow...everything is a nail when all you have is a hammer. > Everything is a bug when all you have is a bug tracker...But I think > the maintainer portal concept introduced with the debut of Community > is something we should start driving enhanced functionality at. If you make maintainers go to a portal, you have lost. Bugzilla gets you email notifications and that is what I need. If a portal sends me that notification, that's fine. I don't care where it comes from. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Thu, Aug 6, 2009 at 10:11 PM, Rahul Sundaram wrote: > > I would prefer the system to be opt-out. For completely new maintainers > or anyone maintaining more than a few packages, it certainly is very > useful to get notification via bugzilla about new upstream releases. Err, uhm...I'd rather not see bugzilla overloaded with this sort of notification. But I would LOVE to see this integrated as notification information into the Fedora Community portal concept. I know a lot of us rely on bugzilla as the mainstay to a lot of our workflow...everything is a nail when all you have is a hammer. Everything is a bug when all you have is a bug tracker...But I think the maintainer portal concept introduced with the debut of Community is something we should start driving enhanced functionality at. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On 08/07/2009 01:03 AM, Till Maas wrote: > > 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. I would prefer the system to be opt-out. For completely new maintainers or anyone maintaining more than a few packages, it certainly is very useful to get notification via bugzilla about new upstream releases. I would also like to have a webpage where I can go to check the Fedora vs upstream release status across all maintained branches including Rawhide. So the information needs to be gathered for all upstream releases. There are some cases where the website moves or fall off the face of the earth or where upstream is completely confused about proper versioning but that is the exception and not the norm. Can be dealt with on a case by case basis. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On 08/06/2009 09:33 PM, Till Maas wrote: 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. I'd prefer this system to be kept opt-in, because I think a) A system can only be made opt-out, if a system can handle the overwhelming number of cases automatically. However, [0] indicates this does not (yet?) apply. Conversely it explicitly asks for manual interaction. b) You seem to be presuming all upstreams to apply one single "newer metric" (Versioning scheme). This doesn't apply, there exist several different versioning schemes, e.g. pre-/bugfix-release versionings, perl-versioning vs. rpm versioning etc. Also, many projects occasionally change their versioning schemes or don't even apply one. How do you plan to handle this? c) Some upstreams occasionally change their download URLs or use non-permanent URLs or some "more or less unstable" URL-redirection. How do you want to hangle this? 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. Website? == yet more bureaucracy [0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
Till Maas wrote: > 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. Speaking just for myself, I'd be happy to have it automatic for my packages. But wow, who's going to key in all those regexps and keep it up to date? -eric > Regards > Till > > [0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Plan for tomorrow's (20090807) FESCo meeting
Sorry for the late agenda, I completely had a communication failure today :) Anyhow, here's the list of topics for tomorrow's (today's?) meeting that will take place at 17:00UTC in #fedora-meeting on freenode: 225 Bugzilla 484855 - Mediawiki Fedora-only patch 176 wiki information regarding FESCo seems to be outdated 210 Fedora packages as canonical upstreams 234 Feature submission freeze needs to be before Feature Freeze 239 Create bugs for every outdated package / release monitoring opt-out 240 Drop F12 Features that are not testable 238 Can libvdpau go in Fedora? For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. -- 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 7:10 PM, Jesse Keating wrote: > Right, aggressive between Fedora releases, conservative within a Fedora > release. I kind of wish everybody did that, and actually treated our > stable releases as, you know, stable releases, otherwise what's the > point of even making releases, and going through freezes and feature > processes and... We could always just go the direction of Arch Linux, have a rolling release and just push out new install images every 6 months (or so). :) . only kidding, but it does seem like some of the arguing points are going that direction. -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
2009/8/7 Till Maas wrote: [..] > > 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. > IMO, ideally it would be best to get new version information for all packages, but file bugs only against those maintainers who opt for it and keep the information available some place. Information about current_version -> new_version_available will be helpful to package maintainers. > [0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring > -- Regards, Rakesh Pandit -- 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 19:56 -0400, Bill McGonigle wrote: > Great thread. Glad someone appreciates it :) > On 08/06/2009 01:59 AM, Adam Williamson wrote: > > I'm simply pointing out that it's literally impossible to > > satisfy both possible update policies with a single unitary repository. > > There was some talk about additional tagging in RPM being available in > Fedora 13, wasn't there? Perhaps if that could propagate through the > build, repo, and yum tools there would be a way to solve for various > branches. We discussed that a few branches of the thread back ;). The principal problem with that is that it's tricky to have multiple 'tracks' within one update repository - so if a package does get an 'adventurous' update then hits a security bug, there's no way to have a separate update without the adventurous change but with the security bug fixed. You then don't have the ability to choose the 'stable but secure' path - you're stuck with either the release package (stable but insecure) or the updated package that includes the adventurous change (secure but potentially unstable). > MythDora is a spin that's worth studying here. It provides a specific > purpose, is pretty well-tuned to that purpose, and doesn't necessarily > update for every Fedora release. > > One can imagine a 'Fedora Solid' spin that pays special attention to QA, > maybe only plans on every-other release, sometimes back-porting > release+1 things that make a huge win, maybe takes longer to compose > than a regular Fedora release. There was some talk about extending > updates to 18 months, which would make such a spin feasible. I'm not sure you could _make_ a 'Solid' spin unless there was a Solid update path to work off. -- 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:30 -0700, Jesse Keating wrote: > 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. The other problem is if you'd like stable updates but you prefer KDE, or vice versa =) -- 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 15:53 -0500, Matthew Woehlke wrote: > Adam Williamson wrote: > > 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... > > KDE would generally consider it a bug if that happened (API compat > broken by a non-major* update), unless it was an interface that already > had a big "BC/SC not guaranteed" warning label. > > (* major = e.g. KDE3 -> KDE4) > > There may be situations in which such a break would be done anyway, but > there would have to be a strong argument why such change is so critical > as to warrant a compatibility break. It seems to happen rather a lot for that to be the case, though maybe the situation I'm most familiar with (KDE 4.0 -> 4.1 -> 4.2) is an unusual situation. I was watching KDE quite closely in MDV at that point, as quite a lot of features that people expected from 3.x were missing, and I remember, for instance, that someone was trying to get kmilo (for multimedia keys) working on 4.x, they had to port it to 4.0, then port it to 4.1, then to 4.2... as I said, I suppose this could just be because 4.0 didn't quite have everything settled down yet so some major changes still had to be made for 4.1 / 4.2. I'm not enough of an expert on KDE to be sure. But we're getting bogged down in specifics again :) -- 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 Thu, 2009-08-06 at 13:08 -0700, Jesse Keating wrote: > On Thu, 2009-08-06 at 12:34 -0700, Adam Williamson wrote: > > 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?) > > Our feature process covers both, PR and experimental things, as well as > things that just need a lot of coordination, or just some extra looking > at for testing. If you really want to create one process for pure PR > features, another process for experimental things, and another process > for things that just need some coordination, I welcome you to draft > those proposals. Ahh, bureaucracy, don't you love it. ;) My idea of a 'process' for pure PR features is 'have a look at the product then write the damn thing', so I am not your guy for drafting process documents... However, that's not my suggestion. I made that earlier in the thread, and it's simple: if there are actual features within new versions of some software that we ship that should count as Fedora features - i.e. they're significant changes that it makes sense to 'gatekeep' at the Fedora level, in terms of organizing Fedora-specific concerted testing and providing a contingency plan in case they turn out to be a bad idea - then isolate _those_ and list _them_ as features, don't just call a version number a feature. XZ payloads in RPM is a feature done right, according to this view. We don't say that 'RPM (whatever-EVR-introduced-XZ-payloads)' is a feature, we say XZ payloads are a feature. -- 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 17:47 -0700, Christopher Stone wrote: > Yea well, I dunno about you guys who run rawhide. But as an F-11 user, > I am *very* glad I use KDE and the KDE SIG is giving me the latest and > greatest to use. I am so glad I don't have to wait for F-12 to be > released just to run the latest version of my desktop. Thank you once > again KDE SIG for your awesome support and maintainership, it is > second to none. So you want rawhide-like treatment for some of your packages, but not all of them? Where is the line? -- 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, Aug 6, 2009 at 8:10 PM, Jesse Keating wrote: > On Thu, 2009-08-06 at 19:07 -0400, Matthias Clasen wrote: >> >> Its kinda funny how the GNOME side is ending up on the 'conservative' >> side here. We are pretty agressive in pushing new stuff into each >> release. But we believe it is better to do that _before_ the release, >> not after. > > Right, aggressive between Fedora releases, conservative within a Fedora > release. I kind of wish everybody did that, and actually treated our > stable releases as, you know, stable releases, otherwise what's the > point of even making releases, and going through freezes and feature > processes and... > I believe that is the way it should be. The releases must be there every once in a while when the installer is updated, e.g.. when the default file system is changed, or when gnome is finally obsoleted etc. Otherwise F10=F11 until the last day of F-10's lifetime, in my perspective. It's just my opinion, as I don't maintain any core components and there might be things that I'm not considering. Orcan -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill McGonigle wrote: > CentOS tends to be crufty, Fedora tends to be broken. Average users > usually want to be somewhere in the middle. Having a user- focused SIG > as an additional check on packagers' decisions to update packages could > have quality benefits. > > I like the idea that Fedora is whatever there's a SIG for, not just for > avoiding the question, but for the idea that Fedora is a process, not a > product. > > -Bill Just a thought, but could that SIG just enforce a critical path- like workflow (with overrides from the security team) on FN-2? They would have to be willing to do the QA, talk with SIGs and maintainers, and be large enough to be able to do so. Thoughts? As a bridge, have critical path grab more packages in FN-1 (maybe have it happen at a milestone such as FN+1 the-release- formerly-known-as-beta?). - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkp7fAkACgkQiPi+MRHG3qQa0wCeOkR/xSGvXlJcsYMWuLdTg4TO OfoAnAyF8a1V8D2BwS7lvYE6JpLyci1z =xO/E -END PGP SIGNATURE- -- 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 5:10 PM, Jesse Keating wrote: > On Thu, 2009-08-06 at 19:07 -0400, Matthias Clasen wrote: >> >> Its kinda funny how the GNOME side is ending up on the 'conservative' >> side here. We are pretty agressive in pushing new stuff into each >> release. But we believe it is better to do that _before_ the release, >> not after. > > Right, aggressive between Fedora releases, conservative within a Fedora > release. I kind of wish everybody did that, and actually treated our > stable releases as, you know, stable releases, otherwise what's the > point of even making releases, and going through freezes and feature > processes and... Yea well, I dunno about you guys who run rawhide. But as an F-11 user, I am *very* glad I use KDE and the KDE SIG is giving me the latest and greatest to use. I am so glad I don't have to wait for F-12 to be released just to run the latest version of my desktop. Thank you once again KDE SIG for your awesome support and maintainership, it is second to none. -- 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 19:07 -0400, Matthias Clasen wrote: > > Its kinda funny how the GNOME side is ending up on the 'conservative' > side here. We are pretty agressive in pushing new stuff into each > release. But we believe it is better to do that _before_ the release, > not after. Right, aggressive between Fedora releases, conservative within a Fedora release. I kind of wish everybody did that, and actually treated our stable releases as, you know, stable releases, otherwise what's the point of even making releases, and going through freezes and feature processes and... -- 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
Great thread. On 08/06/2009 01:59 AM, Adam Williamson wrote: > I'm simply pointing out that it's literally impossible to > satisfy both possible update policies with a single unitary repository. There was some talk about additional tagging in RPM being available in Fedora 13, wasn't there? Perhaps if that could propagate through the build, repo, and yum tools there would be a way to solve for various branches. MythDora is a spin that's worth studying here. It provides a specific purpose, is pretty well-tuned to that purpose, and doesn't necessarily update for every Fedora release. One can imagine a 'Fedora Solid' spin that pays special attention to QA, maybe only plans on every-other release, sometimes back-porting release+1 things that make a huge win, maybe takes longer to compose than a regular Fedora release. There was some talk about extending updates to 18 months, which would make such a spin feasible. CentOS tends to be crufty, Fedora tends to be broken. Average users usually want to be somewhere in the middle. Having a user-focused SIG as an additional check on packagers' decisions to update packages could have quality benefits. I like the idea that Fedora is whatever there's a SIG for, not just for avoiding the question, but for the idea that Fedora is a process, not a product. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
F12 Alpha Blocker Bug Meeting: Friday 2009-08-07 @ 15:00 UTC (11 AM EDT)
What: Fedora 12 Alpha Blocker bug meeting When: Friday, 2009-08-07 @ 15:00 UTC (11 AM EDT) Where: #fedora-bugzappers on irc.freenode.net A busy week for Fedora. The Alpha freeze has come and gone, testing against the alpha test compose began, and the alpha compose is delayed, but looming. Please join us tomorrow as we scrub the list of bugs blocking the Alpha release. Time permitting, the F12Beta and F12Blocker bugs will be reviewed as well. For reference, the blocker bug links are below: * F12Alpha - https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Alpha&hide_resolved=1 * F12Beta - https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Beta&hide_resolved=1 * F12Blocker - https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Blocker&hide_resolved=1 Have an issue you'd like to propose for F12Alpha? Please consider the following criteria when escalating an issue: * Can this issue be fixed with a future rawhide update or is it part of the media kit? * Is this defect a high (or greater) severity [1] with no, or an unreasonable, workaround? * Does the presence of this bug dramatically reduce test coverage? See you there! James [1] http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Severity 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 12:30 -0700, Jesse Keating wrote: > 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. Its kinda funny how the GNOME side is ending up on the 'conservative' side here. We are pretty agressive in pushing new stuff into each release. But we believe it is better to do that _before_ the release, not after. -- 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:46 PM, John Poelstra wrote: > Features are expected to be "complete enough" (testable) by Feature Freeze. Would it make sense to have the feature owner define what "complete enough" is going to mean when the feature is targeted for a release? Something the Feature Wrangler could approve, perhaps? Sure, there might be some unexpected things requiring revision, but most of the work would be front-loaded, and exceptions can be dealt with as that. With an up-front expectation, at least everybody would be singing off the same page as to what 100% means per feature. There's such variation with upstream release dates before and after Alpha that it's hard to see a single set of guidelines that will cover all cases. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf -- 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 14:48 -0700, John Poelstra wrote: > > All we need to do to fix #1 is clarify the policy which the Feature > Wrangler seeks to follow and help administer. It has always been a > percentage to measure the completeness of implementing the feature as > described on the feature page. > > We seek to been feature complete (100%) or "testable" (no percentage > defined in the current policy--this would address #2) at Feature Freeze > so those features can be tested in the test releases (Alpha & Beta). I think what people are looking for is "What do I have to frob to stop being nagged about this". What is it you look for to determine that a feature is complete enough to be testable, and thus not at risk of being removed at feature freeze? -- 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: Fedora 12 Features Proposed for Removal
Adam Williamson said the following on 08/06/2009 12:49 PM Pacific Time: On Thu, 2009-08-06 at 13:39 -0600, Kevin Fenzi wrote: On Thu, 06 Aug 2009 12:34:26 -0700 Adam Williamson wrote: ...snip... 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?) It wasn't a suggestion of that, it was our feature wrangler saying: hey, check these features because they are not showing 100%. Please see: https://fedoraproject.org/wiki/Features/Policy Do we need to change some policy there? Er, the _topic_ of this thread is "Fedora 12 Features Proposed for Removal". The email doesn't say anything about 'if you fix this stuff before the meeting it'll be fine' (though that may be the actual case), and the amount of notice given is a princely two days, which isn't that long for anyone to make changes. The way things are worded are clearly "We're going to drop these features", not "please check this, okay? Please? Thanks!" Fair point though one has to asks how many reminders and nags is necessary? I wrongly assumed we had reached a point in this process where everyone was familiar with the definition of feature freeze and the requirements around it. What I overlooked was that new people (which is an excellent thing!) have gotten involved in the process since our early growing pains. The part I don't quite understand is complaints and protests of "I didn't know" from folks that have been involved since the beginning of the feature process. I'm adding some extra dates to the schedule so that the nagging process is consistent for releases going forward. Hopefully that will help. John -- 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
Jesse Keating said the following on 08/06/2009 11:37 AM Pacific Time: On Thu, 2009-08-06 at 14:21 -0400, Bill Nottingham wrote: 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 So really, we need 2 things. 1) a definition of a status that the feature wrangler and FESCo agree upon to be "done enough" for Alpha / Feature Freeze. 2) a % number that indicates #1 All we need to do to fix #1 is clarify the policy which the Feature Wrangler seeks to follow and help administer. It has always been a percentage to measure the completeness of implementing the feature as described on the feature page. We seek to been feature complete (100%) or "testable" (no percentage defined in the current policy--this would address #2) at Feature Freeze so those features can be tested in the test releases (Alpha & Beta). John -- 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
Adam Jackson said the following on 08/06/2009 11:30 AM Pacific Time: 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 Historically we have tracked the percentage as "percentage of development work/implementation completed." Features are expected to be "complete enough" (testable) by Feature Freeze. The idea being that the implementation is done (100%) or close to done going into the Alpha (previously the Beta) and tested during the test releases. I'm sorry there has been so much confusion this release cycle. As far as I can tell in the conversations I've had with the Feature Wrangler we are handling things the same was we have since we started this process. If the Feature Wrangler is being inconsistent or deviating from the set policy, please let me know so I can pass that on to him ;-) John -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Running a command in background inside spec file
On Thu, Aug 6, 2009 at 3:56 PM, Murilo Opsfelder Araujo wrote: > how can I run a command in background inside spec file? > I have to ask because my curiosity is killing me what's the use case for that? -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Running a command in background inside spec file
Murilo Opsfelder Araujo wrote: > Hi, > > how can I run a command in background inside spec file? > > Thanks. > ooh boy, I think the answer is, "you don't" - why do you need to? -Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Running a command in background inside spec file
Hi, how can I run a command in background inside spec file? Thanks. -- Murilo Opsfelder Araujo -- 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: 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... KDE would generally consider it a bug if that happened (API compat broken by a non-major* update), unless it was an interface that already had a big "BC/SC not guaranteed" warning label. (* major = e.g. KDE3 -> KDE4) There may be situations in which such a break would be done anyway, but there would have to be a strong argument why such change is so critical as to warrant a compatibility break. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Thank you for reading all the way to this .sig. You may stop reading now. Really. It is safe to stop. There is no more content. Why are you still reading? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: non root X
Quoting Adam Jackson (a...@redhat.com): > On Thu, 2009-08-06 at 14:50 -0500, Serge E. Hallyn wrote: > > Quoting Dave Airlie (airl...@redhat.com): > > > 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. > > > > The non-kms drivers could carry fe=on,fI=CAP_SYS_RAWIO (or whatever > > they need) and userids or groups allowed to run X could get pI=CAP_SYS_RAWIO > > at login through pam_cap.so. > > > > If you also make the x driver setuid-root, then on filesystems (like > > NFS) or kernels which don't support file capabilities, it'll run setuid > > root as it does now, while if file caps are supported then it should run > > as the calling user with just the granted capabilities. > > It doesn't work like that. Drivers are DSOs, not executables. You drat -serge -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Critical Path Packages - Enforcement?
Sorry for the long delay responding to this - I've been busy breaking things in the critpath. :) Responses inline: On Wed, 22 Jul 2009, Kevin Kofler wrote: Hi, I have a few questions for the folks involved with the Critical Path Packages proposal, as I'm still confused about the implementation details: 1. How will the policy be enforced? Will Bodhi withhold submitted updates for packages in the depsolving hull of @critical-path until they get approval from QA and/or rel-eng, like it currently does for security updates until security team approval? A ticket is in for bodhi to be able to figure out the list of critpath pkgs and not allow them to be sent on w/o approvals. Assuming the answer to 1. is "Yes": Since 1. was a "How" question I don't think the answer could ever be 'yes'. :) 2. Will critical-path-gnome also get the same enforcement? yes. 3. Will critical-path-kde also get the same enforcement? If the kde-sig desire such. 4. Will critical-path-* for spins.fp.o spins also get the same enforcement? if those sigs desire such. If the answer to any of the above (1. to 4.) is "No", what kind of enforcement will there be? When we discussed critical-path-kde today at KDE SIG, we were very much confused about what exactly the practical implications will be. I think it won't be of much use to define critical path packages if that definition doesn't lead to some actual enforcement. It's up to the sig. our SIG.) * It doesn't make much sense for us to define critical path packages if it won't have any actual practical implications. (We already know what's critical to what extent, so a purely-informative critical-path-kde won't be of much use to us.) critpath is really about making sure person X checks in some change and it works on their machine but doesn't work anywhere else and this doesn't result in a bazillion bug reportrs and broken systems and articles on lwn, etc, etc. We're trying to make things more consistently functional so testing/dev/bug killing can happen. I don't think of critpath as a special status, it is something which has been defacto in place for certain pkgs(rpm, yum, createrepo, python - essentially if those pkgs didn't work enough to do the compose, then we couldn't go any further) - we're just expanding the set of pkgs, really. If the kde-sig does not wish to be involved then that's really up to that sig. The rest of the distro is going to moving ahead. This is only my opinion and my interpretation of things, of course. -sv -- 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 03:21:41PM -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; > > Sorry, I should have expanded. It's bad to use the acronym at > all. > > > > > 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. > > You're stating that IT should be in the description as the groups > are 'related'. I don't see how they're really that strongly related > at all, and IT is superfluous information to the use case. No, I did not state that, but maybe it was not obvious. I stated that the groups should be put together. I agree that the "IT security" is not needed in the password tools description and that the typo should be fixed, it the term is used. I fail to understand why you think they are not strongly related, they existence of the security spin proves that they are imho. I considered IT might be redundant information, too, when I created the groups, but also both the terms "Forensics" or "Wireless" are not IT specific, therefore I put the IT-security explanation into the description. There can be wireless analysis that is not security related, e.g. to find sources of disturbance and there are a lot of forensics tasks that are not IT-security related, but still could be assisted via software. But I do not care that much to keep the term in the description, this was just my motivation to put it there. > > > > 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. > > Additional groups under Base System, not sub-sub-groups. This is no solution to grouping the packages together and still be able to know which packages are for which sub group of tasks. Btw. these tools to also not build a base system or at least what I would think of a base system, because their use case is for certain special tasks and does not form a base for other tools to build on, e.g. cron performs a base set of features that can be used by other packages. But this might not the criteria for packages in the base system category. > > > > > 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. > > # yum search wireless sniffer > Loaded plugins: refresh-packagekit, verify > == Matched: sniffer, wireless > == > aircrack-ng.x86_64 : 802.11 (wireless) sniffer and WEP/WPA-PSK key cracker > kismet.x86_64 : WLAN detector, sniffer and IDS > kismet-extras.x86_64 : Non-core programs for 'kismet' I am impressed, I believe to have worse search experiences with yum search. Nevertheless, airsnort is missing there, but on the other hand kismet-extras is maybe missing in comps. But I do not currently know whether or not comps is subpackage aware. > My objections are: > - the use of a toplevel category (they should be under the existing > categories) This is addressed in my new proposal, they would be in no category or can be in any existing category. > - the excessive use of IT-security most everywh
Re: Fedora 12 Features Proposed for Removal
On Thu, 2009-08-06 at 12:34 -0700, Adam Williamson wrote: > 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?) Our feature process covers both, PR and experimental things, as well as things that just need a lot of coordination, or just some extra looking at for testing. If you really want to create one process for pure PR features, another process for experimental things, and another process for things that just need some coordination, I welcome you to draft those proposals. However, we have one process, that seems to handle all of the above fairly well. There are some interesting interactions, and some room for clarification, but in the end we have one process to go through whether you want to tout a version bump, whether you need to get the attention of multiple maintainers to coordinate a change, whether you want to experiment with something and have the backing of developers, QA, releng, and testers, so on and so forth. A single set of rules to follow, because these all tend to need roughly the same kind of things, so might as well have one process to run through. -- 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: non root X
On Thu, 2009-08-06 at 14:50 -0500, Serge E. Hallyn wrote: > Quoting Dave Airlie (airl...@redhat.com): > > 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. > > The non-kms drivers could carry fe=on,fI=CAP_SYS_RAWIO (or whatever > they need) and userids or groups allowed to run X could get pI=CAP_SYS_RAWIO > at login through pam_cap.so. > > If you also make the x driver setuid-root, then on filesystems (like > NFS) or kernels which don't support file capabilities, it'll run setuid > root as it does now, while if file caps are supported then it should run > as the calling user with just the granted capabilities. It doesn't work like that. Drivers are DSOs, not executables. You don't get capabilities magically blessed into your executable just because you dlopen()d a DSO that has them set. Also, having actually done the audit for this, the set of capabilities the X server would need to run with restricted-caps is essentially equivalent to root in the first place. SYS_RAWIO + SYS_ADMIN + DAC_OVERRIDE plus some others I'm forgetting. Really not a solution. - 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, Aug 06, 2009 at 12:49:30PM -0700, Adam Williamson wrote: >On Thu, 2009-08-06 at 13:39 -0600, Kevin Fenzi wrote: >> On Thu, 06 Aug 2009 12:34:26 -0700 >> Adam Williamson wrote: >> >> ...snip... >> >> > 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?) >> >> It wasn't a suggestion of that, it was our feature wrangler saying: >> hey, check these features because they are not showing 100%. >> >> Please see: >> https://fedoraproject.org/wiki/Features/Policy >> >> Do we need to change some policy there? > >Er, the _topic_ of this thread is "Fedora 12 Features Proposed for >Removal". The email doesn't say anything about 'if you fix this stuff >before the meeting it'll be fine' (though that may be the actual case), >and the amount of notice given is a princely two days, which isn't that >long for anyone to make changes. The way things are worded are clearly >"We're going to drop these features", not "please check this, okay? >Please? Thanks!" No, it's worded perfectly. The Feature Wrangler is PROPOSING to FESCo that we drop these Features. It's a proposal, it's not a clear intention of dropping them at all. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: non root X
Quoting Dave Airlie (airl...@redhat.com): > 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. The non-kms drivers could carry fe=on,fI=CAP_SYS_RAWIO (or whatever they need) and userids or groups allowed to run X could get pI=CAP_SYS_RAWIO at login through pam_cap.so. If you also make the x driver setuid-root, then on filesystems (like NFS) or kernels which don't support file capabilities, it'll run setuid root as it does now, while if file caps are supported then it should run as the calling user with just the granted capabilities. -serge -- 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 13:39 -0600, Kevin Fenzi wrote: > On Thu, 06 Aug 2009 12:34:26 -0700 > Adam Williamson wrote: > > ...snip... > > > 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?) > > It wasn't a suggestion of that, it was our feature wrangler saying: > hey, check these features because they are not showing 100%. > > Please see: > https://fedoraproject.org/wiki/Features/Policy > > Do we need to change some policy there? Er, the _topic_ of this thread is "Fedora 12 Features Proposed for Removal". The email doesn't say anything about 'if you fix this stuff before the meeting it'll be fine' (though that may be the actual case), and the amount of notice given is a princely two days, which isn't that long for anyone to make changes. The way things are worded are clearly "We're going to drop these features", not "please check this, okay? Please? Thanks!" Even if we adjust things discussed in this thread (the tone of the email; the definition of '100%'; other stuff that's come up), we still have a feature process which isn't just for pure PR purposes, it's attached to actual development stuff like test plans and contingency plans and freeze dates, and it seems a bit odd to subject what's really just routine package version updates to that process. -- 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, 6 Aug 2009, Bill Nottingham wrote: Till Maas (opensou...@till.name) said: wireless group. Probably, but this cannot be done right now afaik. yum search certainly can be done now. the tag database that is being added to the pkgdb as a part of the Google Summer of Code is what yum will eventually be able to query as well. So you can return packages based on a number of arbitrary keywords/tags that, ultimately, can be set by users/contributors independent of the packager. -sv -- 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, 06 Aug 2009 12:34:26 -0700 Adam Williamson wrote: ...snip... > 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?) It wasn't a suggestion of that, it was our feature wrangler saying: hey, check these features because they are not showing 100%. Please see: https://fedoraproject.org/wiki/Features/Policy Do we need to change some policy there? kevin signature.asc Description: PGP signature -- 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
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: 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
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: 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
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: 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: '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: 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: 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: 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: '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. > > 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; Sorry, I should have expanded. It's bad to use the acronym at all. > > > 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. You're stating that IT should be in the description as the groups are 'related'. I don't see how they're really that strongly related at all, and IT is superfluous information to the use case. > > > 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. Additional groups under Base System, not sub-sub-groups. > > > > 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. # yum search wireless sniffer Loaded plugins: refresh-packagekit, verify == Matched: sniffer, wireless == aircrack-ng.x86_64 : 802.11 (wireless) sniffer and WEP/WPA-PSK key cracker kismet.x86_64 : WLAN detector, sniffer and IDS kismet-extras.x86_64 : Non-core programs for 'kismet' === Matched: sniffer === driftnet.x86_64 : Network image sniffer ... > > 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? Sorry, should have more clearly mentioned I was using the wireless tool as an example. > > "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. ... what I'm saying is how this should be presented. I'm sure there are features that are only in OpenOffice.org that someone may need, and features that are only in KOffice, and features that are only in abiword/gnumerif/etc. But when we're selecting a default set of packages to install for 'Office Suite', we only install one. And we'd prefer that we fix things to where we only need one in the long term. > 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 informa
Re: 'IT Security' in comps?
On Thu, Aug 06, 2009 at 09:07:13PM +0200, Till Maas wrote: > > 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. Thanks to Rahul, there may be a compromise that will be good enough for me and might to acceptable for you. 1) Create the groups with the it-security-prefix 2) Toggle uservisible to false 3) Do not add a category for the groups Then the exposure to uninterested users will be minimal, but interested users can still install the packages easily with 'yum install @it-sec*' and the search can maybe done with some yum plugin or a different application and the ifnromation is still managed centrally. Regards Till pgphYGPwCxPEj.pgp Description: PGP signature -- 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 08:15:59PM +0100, Peter Robinson wrote: > >> > 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 > Yeah, the wireless drivers are "special" since the vendor drivers, as stated elsewhere, usually supply their own entire 802.11 stack and other ugliness. I don't want to speak for John, but I suspect if someone stepped up to maintain a staging wireless driver in the interim, he wouldn't object. regards, Kyle -- 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: 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: 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: 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: '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, b
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: 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: 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 6, 2009 at 1:27 PM, Adam Williamson wrote: > 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'. > 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. 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 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 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 - 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. -- 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 Thu, 2009-08-06 at 14:21 -0400, Bill Nottingham wrote: > 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 > So really, we need 2 things. 1) a definition of a status that the feature wrangler and FESCo agree upon to be "done enough" for Alpha / Feature Freeze. 2) a % number that indicates #1 -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) 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: 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: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: 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: 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
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
>> 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
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. -- 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
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
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: 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: 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: 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 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: '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 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: 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, 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: KDE vs. GNOME on F10
On Thu, 2009-08-06 at 11:52 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > the rt2860sta wireless driver > > Aren't there patches for that one already? There's a hack, because I reported the problem to Orcan and he wrote a hack. If I hadn't done that there probably wouldn't be; Orcan wasn't aware of the issue until then. > 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.) 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. -- 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 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: 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 Corsepius 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: 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}/
>
> 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
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}/
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
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: ABI compliance checker
On Thu, Aug 6, 2009 at 10:35 AM, Andrey Ponomarenko 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
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 Corsepius 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: 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: 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
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: 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 Corsepius 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}/
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
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: 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
