Thanks for your reply
since I installed KDE for testing and it failed in some aspects (see my
kmail thread), I am noticing, that even under gnome I get some Qt
dialogs now and then (e.g. nautilus starting as default file manager
You mean dolphin, don't you? Nautilus is the default Gnome
Hi there,
since I installed KDE for testing and it failed in some aspects (see my
kmail thread), I am noticing, that even under gnome I get some Qt
dialogs now and then (e.g. nautilus starting as default file manager
from firefox, policykit auth dialog).
I do not want to start a flamewar, but I
Am Montag, 7. September 2009 16:22:17 schrieb Christoph Höger:
Hi there,
since I installed KDE for testing and it failed in some aspects (see my
kmail thread), I am noticing, that even under gnome I get some Qt
dialogs now and then (e.g. nautilus starting as default file manager
You mean
On 08/08/2009 10:34 AM, Kevin Kofler wrote:
Rahul Sundaram wrote:
As already explained, stable in the sense of things that work the same
(No big UI changes etc).
When did we push *big* UI changes in a KDE update?
Big UI changes is an *example* but if you are going to argue that none
of the
On Fri, Aug 7, 2009 at 8:40 AM, Jesse Keatingjkeat...@redhat.com wrote:
On Fri, 2009-08-07 at 07:38 -0700, Christopher Stone wrote:
I don't draw the line, the maintainers of each package draw their own
line. I just sit back and comfortably sip on my mai tai while the
people who know best make
drago01 wrote:
OK, good to hear that, means that this time no patches to compiz-kde are
needed.
Hopefully. For 4.2, there were some changes in KWin internals which needed
patching too.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
On Friday 07 August 2009 04:21:56 Adam Williamson wrote:
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
On Friday 07 August 2009 10:42:35 Rahul Sundaram wrote:
On 08/07/2009 01:35 PM, Jaroslav Reznik wrote:
The other problem is if you'd like stable updates but you prefer KDE, or
vice versa =)
Why do you expect that updating to the latest KDE means unstable system?
;-)
As already
On 08/07/2009 04:48 PM, Jaroslav Reznik wrote:
On Friday 07 August 2009 10:42:35 Rahul Sundaram wrote:
On 08/07/2009 01:35 PM, Jaroslav Reznik wrote:
The other problem is if you'd like stable updates but you prefer KDE, or
vice versa =)
Why do you expect that updating to the latest KDE means
2009/8/5 Matthias Clasen mcla...@redhat.com:
If we just want to dump all the latest stuff in there, why bother with
freezes and releases at all ? We could all just use rawhide...
While often repeated, I don't think that argument is true.
Some people (including me) like the idea of having a
2009/8/7 Thomas Moschny thomas.mosc...@gmail.com:
2009/8/5 Matthias Clasen mcla...@redhat.com:
If we just want to dump all the latest stuff in there, why bother with
freezes and releases at all ? We could all just use rawhide...
While often repeated, I don't think that argument is true.
On Thu, Aug 6, 2009 at 6:33 PM, Jesse Keatingjkeat...@redhat.com wrote:
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
On Friday 07 August 2009 14:05:25 Thomas Janssen wrote:
And back to the topic, afaik the KDE 4.3 packages have indeed been
tested (via kde-redhat/testing etc) before being thrown on the f10
f11 users.
Indeed. Even the RCs up to 4.2.98 have been tested via the kde-redhat
repo, bugs filed
On 08/06/2009 10:24 PM, Adam Williamson wrote:
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
so, two separate issues: one is making the updates, the other is
On 08/06/2009 08:57 PM, Ben Boeckel wrote:
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.
On Fri, 2009-08-07 at 07:38 -0700, Christopher Stone wrote:
I don't draw the line, the maintainers of each package draw their own
line. I just sit back and comfortably sip on my mai tai while the
people who know best make the proper decisions.
But you obviously have a personal line
On Fri, 2009-08-07 at 07:38 -0700, Christopher Stone wrote:
On Thu, Aug 6, 2009 at 6:33 PM, Jesse Keatingjkeat...@redhat.com wrote:
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
Jesse Keating wrote:
On Fri, 2009-08-07 at 07:38 -0700, Christopher Stone wrote:
I don't draw the line, the maintainers of each package draw their own
line. I just sit back and comfortably sip on my mai tai while the
people who know best make the proper decisions.
But you obviously have a
On Fri, 2009-08-07 at 11:05 -0500, Matthew Woehlke wrote:
For me, that's easy. I don't want updates that the packagers don't
consider stable. It sure sounds to me like Christopher feels the same way.
I am willing to take the latest upstream builds because the maintainer
considers them
Jesse Keating wrote:
On Fri, 2009-08-07 at 11:05 -0500, Matthew Woehlke wrote:
For me, that's easy. I don't want updates that the packagers don't
consider stable. It sure sounds to me like Christopher feels the same way.
I am willing to take the latest upstream builds because the maintainer
On Fri, 2009-08-07 at 12:21 -0500, Matthew Woehlke wrote:
If that put an end to stuff like 'sorry, that last glibc rpm bricks your
system if you have the misfortune of installing it'... maybe. As I said,
right now my line is packages that the maintainers consider stable.
If rawhide became
On Fri, 2009-08-07 at 10:43 -0700, Jesse Keating wrote:
Well with the no frozen rawhide proposal, from the Alpha freeze point on
there would be such an updates-testing for the pending release, while
rawhide remains the wild west. You could say install F12, then at F13
Alpha jump onto F13
Jesse Keating wrote:
Well with the no frozen rawhide proposal, from the Alpha freeze point on
there would be such an updates-testing for the pending release, while
rawhide remains the wild west. You could say install F12, then at F13
Alpha jump onto F13 and have the much newer more often
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. If
Adam Williamson wrote:
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
Rahul Sundaram wrote:
As already explained, stable in the sense of things that work the same
(No big UI changes etc).
When did we push *big* UI changes in a KDE update? We're even making sure
the default Plasma theme in F10 and F11 stays Oxygen rather than switching
to Air which is the new
On Thu, 2009-08-06 at 05:37 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
I probably couldn't do much justice to a comprehensive plan as I have
insufficient knowledge of how the buildsystem works. I was acting at a
higher level - just trying to point out that it's essentially doomed to
regressions. If an update fixes ten bugs but changes the behaviour
of some component people see every day - which is a fairly accurate
description of both KDE and GNOME point releases - it's not appropriate
to be an update, in this theory, because it means the updated product is
breaking
people see every day - which is a fairly accurate
description of both KDE and GNOME point releases - it's not appropriate
to be an update, in this theory, because it means the updated product is
breaking the expectations of the the initial release. What your frazzled
The kernel's a great example
On Wed, 2009-08-05 at 12:58 -0700, Jesse Keating wrote:
All this really does is create a pseudo rawhide for each release,
blurring the lines even more around why we even do releases. With a 6
month cycle, do we really want to take on all this extra headaches and
hassles just so that you can
Le mercredi 05 août 2009 à 14:27 -0700, Adam Williamson a écrit :
On Wed, 2009-08-05 at 13:03 -0700, Jesse Keating wrote:
On Wed, 2009-08-05 at 12:58 -0700, Jesse Keating wrote:
It also would require multiple CVS branches, one for security, one for
adventurous, as well as different
Adam Williamson wrote:
the rt2860sta wireless driver
Aren't there patches for that one already? As the driver is Free Software,
it can be fixed. By the time 2.6.31 gets even to updates-testing, RPM Fusion
will already have the patches.
And, by the way, Fedora intentionally refuses to support
Christopher Aillon wrote:
Sure, you can blame Gecko for having it's unstable ABI be, well,
unstable. But blame also goes to the apps for not using the stable ABI.
Why does Mozilla expect apps to use an ABI:
* which didn't exist when the apps were written and
* which they aren't even using for
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
On Thu, Aug 6, 2009 at 11:56 AM, Kevin Koflerkevin.kof...@chello.at wrote:
Christopher Aillon wrote:
Sure, you can blame Gecko for having it's unstable ABI be, well,
unstable. But blame also goes to the apps for not using the stable ABI.
Why does Mozilla expect apps to use an ABI:
* which
could only be an
improvement.) The Gnome packagers have the opposite views of Gnome.
Those 2 views do not conflict, and even if the teams were using the
exact same criteria, they could still come to those conclusions. You can
only call it inconsistent if KDE and Gnome have exactly the same release
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
On Wed, Aug 05, 2009 at 10:59:25PM -0700, Adam Williamson wrote:
On Thu, 2009-08-06 at 05:37 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
I probably couldn't do much justice to a comprehensive plan as I have
insufficient knowledge of how the buildsystem works. I was acting at a
higher
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
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
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
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
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
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
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
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
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,
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
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,
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
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
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
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
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
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
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,
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?
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,
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
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...
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,
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
On Thu, Aug 6, 2009 at 7:10 PM, Jesse Keatingjkeat...@redhat.com wrote:
snip
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
Hi all.
KDE 4.3 will come to F11 and F10. It's a cool thing.
There aren't updates like this for Gnome. Why not?
F10 with Gnome 2.26 sounds fine to me.
--
Josephine Fine Tannhäuser
2.6.29.6-213.fc11.i586
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
2009/8/5 Josephine Tannhäuser josephine.tannhau...@googlemail.com:
KDE 4.3 will come to F11 and F10. It's a cool thing.
There aren't updates like this for Gnome. Why not?
F10 with Gnome 2.26 sounds fine to me.
Because I don't want to _support_ the latest and greatest GNOME on old
versions. A
On Wed, Aug 5, 2009 at 9:49 AM, Josephine
Tannhäuserjosephine.tannhau...@googlemail.com wrote:
Hi all.
KDE 4.3 will come to F11 and F10. It's a cool thing.
There aren't updates like this for Gnome. Why not?
F10 with Gnome 2.26 sounds fine to me.
Because a lot of GNOME works directly with
, and that's not
something a typical F10 user wants to cope with. In my opinion, if you
want newer functionality, you should just upgrade to F11.
I don't want to get between the lines here (there are good arguments and
against updating Gnome and KDE for older releases) and I hate buzz-words
like Corporate
On Wednesday 05 August 2009 13:08:28 Colin Walters wrote:
Because a lot of GNOME works directly with (and depends on) the core
OS., and we want a stable system.
Does this mean, that every time I've installed my system and left
GNOME out, I made a broken system?
Is there a list of those
Gnome and KDE for older releases) and I hate buzz-words
like Corporate identity, but I find it more and more odd that one
doesn't know what to expect from Fedora, because similar sized things
(KDE and Gnome) are handled quite differently.
Short of passing a policy that says no major desktop upgrades
on the KDE side. While we do a good chunk of the development
work for each GNOME release, the KDE sig is more of a packaging effort,
as far as I understand. Correct me if I'm wrong here...
- It is not compatible with the concept of a finished, stable release.
If we just want to dump all the latest
Josephine Tannhäuser wrote:
KDE 4.3 will come to F11 and F10. It's a cool thing.
There aren't updates like this for Gnome. Why not?
For the most part, those are hard decisions best left to the discretion of
the maintainers in question.
-- Rex
--
fedora-devel-list mailing list
On Wed, Aug 5, 2009 at 12:23 PM, Thorsten Leemhuisfed...@leemhuis.info wrote:
Further: The behavior changes to much IMHO -- one reason why I use
Fedora at home and work and suggested it to others were the major new
kernel versions that got delivered as regular update. But that doesn't
really
On Wed, 2009-08-05 at 08:01 -0400, Josh Boyer wrote:
I don't want to get between the lines here (there are good arguments and
against updating Gnome and KDE for older releases) and I hate buzz-words
like Corporate identity, but I find it more and more odd that one
doesn't know what to expect
On Wed, Aug 5, 2009 at 1:47 PM, Adam Williamsonawill...@redhat.com wrote:
snip
We've had this discussion before, but to re-state my opinion: the only
sane way to handle this is multiple, discretionary update repositories.
A repository for security and stable bugfix updates, and a repository
On Wed, Aug 5, 2009 at 2:49 PM, Adam Millermaxamill...@gmail.com wrote:
On Wed, Aug 5, 2009 at 1:47 PM, Adam Williamsonawill...@redhat.com wrote:
snip
We've had this discussion before, but to re-state my opinion: the only
sane way to handle this is multiple, discretionary update repositories.
On Wed, 2009-08-05 at 17:21 +0300, Juha Tuomala wrote:
On Wednesday 05 August 2009 14:06:43 Jussi Lehtola wrote:
On Wed, 2009-08-05 at 13:46 +0300, Juha Tuomala wrote:
On Wednesday 05 August 2009 13:08:28 Colin Walters wrote:
Because a lot of GNOME works directly with (and depends on)
On Wed, Aug 5, 2009 at 1:51 PM, Mark
Bidewellmark.bidew...@alumni.clemson.edu wrote:
snip
+1
snip
Would we want to consider putting together a proposal for something
that is OpenSuSE Buildservice styled in order to satisfy this?
-Adam
--
http://maxamillion.googlepages.com
On 08/05/2009 11:47 AM, Adam Williamson wrote:
And maintainers can choose whether or not they
want to take on the work of shipping updates in the adventurous
repository.
How does this work? It would seem that the adventurous repository would
be mandatory as something that changes ABI would
On Wed, 2009-08-05 at 13:58 -0500, Adam Miller wrote:
On Wed, Aug 5, 2009 at 1:51 PM, Mark
Bidewellmark.bidew...@alumni.clemson.edu wrote:
snip
+1
snip
Would we want to consider putting together a proposal for something
that is OpenSuSE Buildservice styled in order to satisfy this?
of the examples in question really breaks many public ABIs,
though, AFAIK. GTK+ version bumps don't break the ABI, we don't rebuild
seven thousand packages each time GTK+ gets updated (it's still on the
2.0 ABI). Most KDE / GNOME breakage with new releases is 'internal', I
think - so if you're updating
On Wed, 2009-08-05 at 15:28 -0400, Josh Boyer wrote:
Care to write up a proposal on how this work-flow would look like? Without
some of the details, I'm confused how one would avoid all kinds of weirdness
from repo conflicts if you have multiple of these repos enabled. That, and
the
fact
On 08/05/2009 12:11 PM, Adam Williamson wrote:
On Wed, 2009-08-05 at 11:58 -0700, Toshio Kuratomi wrote:
Also, having the expectation that the other repository is for security
updates doesn't address the problem of a security release breaking ABI.
That's rather unlikely (well, except in
On 08/05/2009 03:41 PM, Adam Williamson wrote:
The missing bit of the argument from before is whether we actually want
to care about people who only want 'stable' updates, and that tracks
back to the question of what Fedora actually is, which I don't believe
the Board has settled yet. If we
On Wed, 2009-08-05 at 12:44 -0700, Toshio Kuratomi wrote:
Sure, this is comparable to the present situation. But it doesn't seem
like it makes things much better.
* It doesn't solve the original poster's issue (that the GNOME stack
isn't going to be updated for F10 since the maintainers
On Wed, 2009-08-05 at 12:58 -0700, Jesse Keating wrote:
It also would require multiple CVS branches, one for security, one for
adventurous, as well as different buildroots to go along with those,
since you wouldn't be able to build a security update for a gnome
package against the newer
On Wed, 2009-08-05 at 12:44 -0700, Toshio Kuratomi wrote:
Sure, this is comparable to the present situation. But it doesn't seem
like it makes things much better.
* It doesn't solve the original poster's issue (that the GNOME stack
isn't going to be updated for F10 since the maintainers
On Wed, 2009-08-05 at 13:04 -0700, Adam Williamson wrote:
An alternative would be to tag updates within a single repo in a way
that yum and PackageKit understand and have appropriate configuration
options to enable certain types of update, which would really be much
the same situation, just
On Wed, 2009-08-05 at 15:49 -0400, Tom spot Callaway wrote:
On 08/05/2009 03:41 PM, Adam Williamson wrote:
The missing bit of the argument from before is whether we actually want
to care about people who only want 'stable' updates, and that tracks
back to the question of what Fedora
On 08/05/2009 04:11 PM, Adam Williamson wrote:
The question is whether Fedora intends to be a distribution suitable for
day-to-day general purpose use by people who are not necessarily that
interested in Fedora per se - whether it's got an aim to be a
general-purpose operating system like other
On 08/05/2009 01:04 PM, Adam Williamson wrote:
On Wed, 2009-08-05 at 12:44 -0700, Toshio Kuratomi wrote:
Sure, this is comparable to the present situation. But it doesn't seem
like it makes things much better.
* It doesn't solve the original poster's issue (that the GNOME stack
isn't
On Wed, 2009-08-05 at 16:18 -0400, Tom spot Callaway wrote:
Maintainers are pushing updates because they
feel there is a reason, a bug fixed, a security hole closed, a
significant feature enhancement that users want (or that they think
users want).
A bug filed by FEVEr or it's replacement
* Jesse Keating [05/08/2009 22:38] :
A bug filed by FEVEr or it's replacement saying there is a bigger number
released somewhere.
Do maintainers really push out updates for this? I've always considered
a reason to push out a build for rawhide but not to issue updates for
the stable releases.
On Wed, August 5, 2009 2:33 pm, Jesse Keating wrote:
On Wed, 2009-08-05 at 16:18 -0400, Tom spot Callaway wrote:
Maintainers are pushing updates because they
feel there is a reason, a bug fixed, a security hole closed, a
significant feature enhancement that users want (or that they think
On Wed, 2009-08-05 at 22:49 +0200, Emmanuel Seyman wrote:
Do maintainers really push out updates for this? I've always considered
a reason to push out a build for rawhide but not to issue updates for
the stable releases.
It's really hard to tell when so many updates pushers put 0 information
On Wed, 2009-08-05 at 13:14 -0700, Jesse Keating wrote:
On Wed, 2009-08-05 at 13:04 -0700, Adam Williamson wrote:
An alternative would be to tag updates within a single repo in a way
that yum and PackageKit understand and have appropriate configuration
options to enable certain types of
your problem better, perhaps yours is already solved :-)
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
On Wed, 2009-08-05 at 13:03 -0700, Jesse Keating wrote:
On Wed, 2009-08-05 at 12:58 -0700, Jesse Keating wrote:
It also would require multiple CVS branches, one for security, one for
adventurous, as well as different buildroots to go along with those,
since you wouldn't be able to build a
On Wed, 2009-08-05 at 14:26 -0700, Adam Williamson wrote:
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
On Wed, Aug 5, 2009 at 10:18 PM, Tom spot Callawaytcall...@redhat.com wrote:
On 08/05/2009 04:11 PM, Adam Williamson wrote:
The question is whether Fedora intends to be a distribution suitable for
day-to-day general purpose use by people who are not necessarily that
interested in Fedora per
On Wed, 2009-08-05 at 14:36 -0700, Jesse Keating wrote:
On Wed, 2009-08-05 at 14:26 -0700, Adam Williamson wrote:
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
1 - 100 of 179 matches
Mail list logo
