Kevin Kofler wrote:
as long as you require only a few 32-bit packages, requesting them
explicitly is not the end of the world. So if we were to drop support
for that always install all libs as multilibs option
Eh? I didn't even know there was such an option. And I agree, /that/
should be
On Thu, 11 Mar 2010, Matthew Woehlke wrote:
Kevin Kofler wrote:
as long as you require only a few 32-bit packages, requesting them
explicitly is not the end of the world. So if we were to drop support
for that always install all libs as multilibs option
Eh? I didn't even know there was
Kevin Kofler wrote:
Matthew Woehlke wrote:
You forget people developing proprietary software...
Why would we want to encourage or even support that?
I don't expect Fedora to encourage it (nor should we, IMO)... but that
doesn't change the reality of $DAYJOB. If Fedora drops multilib, I will
Matthew Woehlke wrote:
Kevin Kofler wrote:
Matthew Woehlke wrote:
You forget people developing proprietary software...
Why would we want to encourage or even support that?
I don't expect Fedora to encourage it (nor should we, IMO)... but that
doesn't change the reality of $DAYJOB. If
Michael Schwendt wrote:
On Mon, 08 Mar 2010 14:29:42 -0600, Matthew wrote:
There are just too many -devel packages and their dependencies to be ever
relevant to someone for multi-arch installs. Far more users install i686 on
64-bit CPUs, and I have doubts that x86_64 installation users do
Michael Schwendt wrote:
On Wed, 10 Mar 2010 11:30:05 -0600, Matthew wrote:
Probably because
I need multilib and have never experienced multilib-related problems (or
if I have, they were so trivial as to be thoroughly forgettable).
Just out of interest, does enabling a separate 32-bit
Matthew Woehlke wrote:
Hmm, maybe then you are thinking of things that are far less
stand-alone. The only run-time environment we care about is that the
program can be executed (so, kernel can load it, glibc.i?86 exists,
etc.). We tend to have very few if any dependencies beyond libc (and
I wrote:
* yum install glibc.i686.
Actually, you probably want glibc-devel.i686. But my point still stands, as
long as you require only a few 32-bit packages, requesting them explicitly
is not the end of the world. So if we were to drop support for that always
install all libs as multilibs
Matthew Woehlke wrote:
You forget people developing proprietary software...
Why would we want to encourage or even support that?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Michael Schwendt wrote:
There are just too many -devel packages and their dependencies to be ever
relevant to someone for multi-arch installs. Far more users install i686 on
64-bit CPUs, and I have doubts that x86_64 installation users do much
development with i686 packages. At most they
On Fri, Mar 5, 2010 at 2:11 AM, James Antill ja...@fedoraproject.org wrote:
On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote:
On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote:
Extras had significantly fewer packages,
Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is
On Thu, 04 Mar 2010 20:11:47 -0500, James wrote:
On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote:
On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote:
Extras had significantly fewer packages,
Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300
less
On Fri, 05 Mar 2010 02:41:46 -0500, James wrote:
% yum repolist --releasever=11 updates
repo id repo name status
updates Fedora 11 - x86_64 - Updates9,390
...
This probably won't go well unless you two are
(Starting a new thread because this hardly has anything to do with the
original infamous thread.
Dear hall monitors: I hope I won't get put on moderation for posting this,
but this subthread didn't have much to do with the original subject. If you
also want me to stop posting to this split
On Fri, 05 Mar 2010 11:03:12 +0100, Kevin wrote:
Yeah, basically mash is a really brute force solution, I think directly
writing out only the new updates as the first prototypes of Bodhi did and as
the Extras scripts also did/do is a much smarter solution. Always
recomputing everything
Kevin Kofler (kevin.kof...@chello.at) said:
So what? That's not twice as much as FE6, which would not have taken
several hours to push into such a repo. Not even when running repoclosure
on the needsign repo prior to pushing and when updating repoview pages
afterwards. Simply because the
Bill Nottingham wrote:
The issue there is then you have to properly determine what packages
to remove from the repo (unless you just keep everything, which has its
own problems); in this case, recomputing actually makes the code simpler.
Sure, it makes the code simpler, but a lot slower!
Bill Nottingham wrote:
Off the top of my head, it would break the install DVD usage case
The install DVD wouldn't have 32-bit baggage. So what? It's not installed by
default anyway. (At least the live images don't contain ANY multilib stuff.
I'm not sure what the DVD does these days.)
and
On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote:
Extras had significantly fewer packages,
Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less
than F11 stable updates.
http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/repoview/index.html
no
On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote:
On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote:
Extras had significantly fewer packages,
Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less
than F11 stable updates.
On Thu, 2010-03-04 at 20:11 -0500, James Antill wrote:
On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote:
On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote:
Extras had significantly fewer packages,
Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300
On Thu, 2010-03-04 at 18:30 -0800, Jesse Keating wrote:
On Thu, 2010-03-04 at 20:11 -0500, James Antill wrote:
On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote:
Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300
less
than F11 stable updates.
On Tue, 02 Mar 2010 17:53:40 -0800, Jesse wrote:
On Wed, 2010-03-03 at 02:37 +0100, Kevin Kofler wrote:
Jesse Keating wrote:
That's a fair point, but there are significantly fewer people around to
fix critical issues should they arise on a weekend, and after working 5
weekdays, some
Le Mer 3 mars 2010 05:49, Kevin Kofler a écrit :
Jesse Keating wrote:
did a poor job in stating our goals for the operating system, and just
hoped that our maintainers would see things the way we saw them.
Why should they see them that way rather than the right way? ;-)
Please stop
On Mon, Mar 01, 2010 at 01:46:20PM -0500, Seth Vidal wrote:
On Mon, 1 Mar 2010, Till Maas wrote:
What kind of tests need to be done always manually? The only ones I can
think are tests for the appearance of applications or tests that require
specific hardware. But in the general case, I
On Wed, Mar 03, 2010 at 12:33:40AM -0500, James Antill wrote:
You keep saying that 7 days is enough but I haven't seen you provide
_any_ evidence to support it. Noting that it will often take 3-4 days
before a package in testing can be seen by all users. So maybe you are
So there is an easy
On 03/03/2010 08:38 AM, Kevin Kofler wrote:
So maybe you are under the impression that all the users who would test
your package are anxiously waiting for your packages to be available?
For those packages where regressions actually matter to people, they
definitely are. People keep asking
2010/3/3 Josh Boyer jwbo...@gmail.com:
On Tue, Mar 02, 2010 at 11:52:49PM -0800, Adam Williamson wrote:
On Tue, 2010-03-02 at 22:37 -0500, Seth Vidal wrote:
We've made a mess and as a member of fesco I'd expect you to be helping in
cleaning up the mess, not making it worse b/c fesco HAS to be
On Wed, Mar 03, 2010 at 10:54:57AM +0100, Michael Schwendt wrote:
On Tue, 02 Mar 2010 17:53:40 -0800, Jesse wrote:
On Wed, 2010-03-03 at 02:37 +0100, Kevin Kofler wrote:
Jesse Keating wrote:
That's a fair point, but there are significantly fewer people around to
fix critical issues
On Wed, 3 Mar 2010, Thomas Moschny wrote:
2010/3/3 Josh Boyer jwbo...@gmail.com:
On Tue, Mar 02, 2010 at 11:52:49PM -0800, Adam Williamson wrote:
On Tue, 2010-03-02 at 22:37 -0500, Seth Vidal wrote:
We've made a mess and as a member of fesco I'd expect you to be helping in
cleaning up the
On Wed, 2010-03-03 at 07:52 +0100, Kevin Kofler wrote:
James Antill wrote:
This isn't a hard problem, 3.0 should then be marked as a security
update.
But the case we're discussing is that 3.0 was pushed long before it was
known that it happens to fix a security vulnerability. We're not
On Tue, 2010-03-02 at 23:57 -0800, Adam Williamson wrote:
I wasn't suggesting that's what happens in Fedora at present, just that
- given a single update stream in which it's perfectly fine for
'security' updates to build on 'feature' updates - it's impossible to
cherry pick only security
On 03/02/2010 08:42 PM, Kevin Kofler wrote:
Peter Jones wrote:
On 03/02/2010 06:15 AM, Kevin Kofler wrote:
X11 is particularly dangerous for this kind of changes, given how low
it is in the software stack and how some code necessarily looks like
(hardware drivers in particular are always
On Wed, 2010-03-03 at 17:09 +0100, Till Maas wrote:
On Wed, Mar 03, 2010 at 11:02:51AM -0500, James Antill wrote:
If we had less updates, that changed less things and required more
testing before pushing them to users ... this would be entirely
possible.
Less updates mean more changes
James Antill wrote:
I would assume you could just change the updateinfo for the the current
update to mark it as security, this is a tiny amount of extra work on
the packager side ... but without it all the work to create the security
types on updates is worthless.
We can't change Bodhi
On Wed, Mar 3, 2010 at 18:27, Kevin Kofler kevin.kof...@chello.at wrote:
James Antill wrote:
I would assume you could just change the updateinfo for the the current
update to mark it as security, this is a tiny amount of extra work on
the packager side ... but without it all the work to
James Antill wrote:
On Wed, 2010-03-03 at 07:38 +0100, Kevin Kofler wrote:
People who use updates-testing under the current system are signing up to
doing testing. Under your proposal, they'd be forced to sign up to get
any current updates.
Get current updates = so they can be tested!
Le mercredi 03 mars 2010 à 16:32 +0100, Kevin Kofler a écrit :
Nicolas Mailhot wrote:
If KDE wants to be on an equal footing with GNOME (another of your
repeated complains) it needs to learn synchronizing with distro releases
like GNOME (and kernel, and xorg did).
I don't see this as
Mathieu Bridon wrote:
On Wed, Mar 3, 2010 at 18:27, Kevin Kofler kevin.kof...@chello.at wrote:
We can't change Bodhi metadata after the fact at this time. Bodhi admins
might be able to do it, but maintainers definitely aren't.
Where's the RFE ticket?
I've never felt the need. This is the
Nicolas Mailhot wrote:
This is only working for you because KDE is a high-visibility project
and can mobilize resources even outside the distro normal schedule. The
other packages you talk of could benefit if QA was cheap and plentiful
but QA is not cheap and plentiful and pretending we do not
Juha Tuomala wrote:
On Wed, 3 Mar 2010, Kevin Kofler wrote:
You're distorting the Fedora model to accommodate KDE roadmaps.
No, this goes far beyond KDE. KDE roadmaps are just one strong argument
for doing things this way. Many more packages benefit or would benefit
from version upgrades
On Wed, 3 Mar 2010, Chris Adams wrote:
By the same token, if you want rolling update releases, feel free to do
it in your own private repo. See how well that argument works?
No i don't. I'm using a mainstream distribution and thus I expect to
get them. Just like the upstream has intended
On Wed, 3 Mar 2010, Kevin Kofler wrote:
The strong argument is that KDE and Fedora release cycles are not in sync
and our users would thus have to wait months for the new KDE.
As many have stated, not all people *want* those feature updates
to stable release. By pushing them by force, you
Chris Adams wrote:
Once upon a time, Kevin Koflerkevin.kof...@chello.at said:
Such as? We're filling a niche, this is one of our unique selling points,
you want to throw out the baby with the bathwater!
Who is this we you keep speaking of? When did huge dumps of updates
in supposedly
Jesse Keating wrote:
You can put free text in a bodhi comment without giving positive or
negative karma. Seems we already have what you want to replace it with.
But his point (which I agree with, FWIW) is that those arbitrary numbers are
meaningless and thus it makes no sense to count them.
Tom spot Callaway wrote:
* Has ABI/API change (and is a Critical Path package)
Wrong criterion, sorry. Has ABI/API change and fails to include rebuilds of
the affected packages should be the criterion, critical path or not is
irrelevant. But this is basically covered by causes broken deps
James Antill wrote:
So I did my proposal, which I think will motivate packagers to do the
right thing (giving lots of choice to the users and a reasonable number
of packages to test) and not removing the ability of packagers to do
what they want (and have the stable firehose):
Peter Jones wrote:
This is the plan that already isn't working.
Is it really not working? Or are we overblowing a minor incident which
didn't even cause all that much trouble and trying to swallow a cure which
is worse than the disease? I think it's really the latter.
Kevin Kofler
--
Peter Jones wrote:
When you're at the circus watching the clown ride a bicycle across a
high-wire, he's got a safety net. It's not because the circus thinks he's
an incompetent high-wire cyclist - it's because people occasionally make
mistakes, and the circus would rather have him around to do
Jesse Keating wrote:
We do pushes daily,
No we don't. There are usually no pushes on weekends.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
James Antill wrote:
It's still not really usable by normal users, but people on this list
can install yum-plugin-local ... which will make sure you can do
downgrades like this.
Isn't keepcache=yes sufficient? IMHO that should really be the default, I
really don't understand why we default to
Adam Jackson wrote:
If it's ready on Tuesday afternoon, what makes you think anyone's going
to have time to read it thoroughly enough to be able to vote on it? Are
you implying you're the only one on fesco that actually considers the
proposal they're asked to vote on?
Considering that this
Peter Jones wrote:
Other corner cases where your case was wrong include new packages that
Obsolete existing packages.
Nonsense. I wrote new package which doesn't replace anything. Obsoletes =
replacing.
Even if you fix all the fixable problems, testing will still not be a
silver bullet!
On Tue, 2010-03-02 at 11:22 +0100, Kevin Kofler wrote:
James Antill wrote:
It's still not really usable by normal users, but people on this list
can install yum-plugin-local ... which will make sure you can do
downgrades like this.
Isn't keepcache=yes sufficient? IMHO that should really
On Tue, 2010-03-02 at 09:45 +0100, Kevin Kofler wrote:
I didn't bring up the fun argument. My point is that banning direct stable
pushes prevents us from fixing things for our users ASAP when needed. This
is all part of duty, not fun.
And it prevents us from breaking things, with no warning
On Tue, 2010-03-02 at 10:59 +0100, Kevin Kofler wrote:
James Antill wrote:
So I did my proposal, which I think will motivate packagers to do the
right thing (giving lots of choice to the users and a reasonable number
of packages to test) and not removing the ability of packagers to do
On Tue, 2010-03-02 at 11:06 +0100, Kevin Kofler wrote:
Peter Jones wrote:
This is the plan that already isn't working.
Is it really not working? Or are we overblowing a minor incident which
didn't even cause all that much trouble and trying to swallow a cure which
is worse than the
On Tue, 2010-03-02 at 10:57 -0500, Frank Ch. Eigler wrote:
James Antill ja...@fedoraproject.org writes:
https://fedoraproject.org/wiki/Release_Lifecycle_Proposals#Choice_.28james.29
Regarding this, I don't understand this part:
The idea behind this proposal is that a Fedora user
On Tue, 2010-03-02 at 09:45 +0100, Kevin Kofler wrote:
Yet, in practice, I still think a lot
more stuff gets backported in our updates repository than in those
backports repositories of other distros.
Probably true (though in the case of Mandriva, maybe less than you'd
expect; it's
On Tue, 2010-03-02 at 10:57 -0500, Frank Ch. Eigler wrote:
Doesn't just not running random/unrestricted yum update exactly
encode that option?
If you're happy to live with unsecure software, certainly =)
you can try and cherry-pick security updates, but then you get the
problem where initial
James Antill ja...@fedoraproject.org writes:
[...]
...but they have almost no options if they are happy to stay with
the software that they have.
Doesn't just not running random/unrestricted yum update exactly
encode that option?
No, for two reasons:
1. The user is often informed,
2010/3/2 Adam Williamson awill...@redhat.com:
On Tue, 2010-03-02 at 10:57 -0500, Frank Ch. Eigler wrote:
Doesn't just not running random/unrestricted yum update exactly
encode that option?
If you're happy to live with unsecure software, certainly =)
you can try and cherry-pick security
On Tue, 2010-03-02 at 11:17 +0100, Kevin Kofler wrote:
No we don't. There are usually no pushes on weekends.
That's a fair point, but there are significantly fewer people around to
fix critical issues should they arise on a weekend, and after working 5
weekdays, some of us like taking the
On Tue, 2010-03-02 at 11:55 +0100, Kevin Kofler wrote:
My argument is actually: It doesn't matter how good our infrastructure for
testing fixes is, it'll still not catch everything. Therefore, some
regressions make it into stable anyway, and we want them to get fixed (in
the stable updates)
On Tue, 2 Mar 2010, Jesse Keating wrote:
This is the problem with arguing about a proposal that hasn't even been
written yet. You latch onto the one part you assume will be there that
is the most unreasonable, and use that as a tool to bash the entire
concept of the proposal (which hasn't
On Tue, 2010-03-02 at 18:08 +0100, Thomas Moschny wrote:
you can try and cherry-pick security updates, but then you get the
problem where initial release has Foobar 1.0, then Foobar 3.5 gets
shipped in updates, then a security problem emerges and Foobar 3.5-2
with the security fix gets
On Tue, 2010-03-02 at 07:46 +0100, Kevin Kofler wrote:
I just disagree with the claim that ALL updates are
susceptible of breaking things.
Until such time that every update goes through without any breakage, I'm
going to keep on assuming that all updates are susceptible to breaking
things,
On Tue, 2010-03-02 at 12:08 -0500, Frank Ch. Eigler wrote:
James Antill ja...@fedoraproject.org writes:
[...]
...but they have almost no options if they are happy to stay with
the software that they have.
Doesn't just not running random/unrestricted yum update exactly
encode
On 03/02/2010 04:23 AM, Kevin Kofler wrote:
Tom spot Callaway wrote:
* Has ABI/API change (and is a Critical Path package)
Wrong criterion, sorry. Has ABI/API change and fails to include rebuilds of
the affected packages should be the criterion, critical path or not is
irrelevant. But
On 03/02/2010 06:15 AM, Kevin Kofler wrote:
X11 is particularly dangerous for this kind of changes, given how low it
is in the software stack and how some code necessarily looks like
(hardware drivers in particular are always scary stuff). The average leaf
package is much less propice to
On 03/02/2010 05:15 AM, Kevin Kofler wrote:
Peter Jones wrote:
When you're at the circus watching the clown ride a bicycle across a
high-wire, he's got a safety net. It's not because the circus thinks he's
an incompetent high-wire cyclist - it's because people occasionally make
mistakes, and
Frank Ch. Eigler wrote:
OK, but then we're not talking about the person who's happy to stay
with the software they have, but about a more typical person who is
not too risk-averse and is willing to consider unsolicited updates.
Those are different dudes.
The person who's not willing to do any
James Antill wrote:
...but it has the same problem. But IMNSHO this isn't a problem, you
are arguing that people specifically hit by problem X can goto the
updates-testing (or whatever it's called) repo. and get a fix for it.
Anyone not affected doesn't have to risk that update breaking
Adam Williamson wrote:
Oh, I see. You're inferring a cause where there's no reason to. I didn't
realize that.
What other reasons do you consider then? Pure chance? Doesn't look very
likely to me. It's much more likely the reason Mandriva provides fewer new
versions is because of the split
Kevin Kofler wrote:
Even bugfix releases of KDE require a session restart to fully work.
I consider that a serious design flaw in KDE and a strong argument against
releasing any KDE updates to stable releases other than fixes for serious bugs.
The only practical way to keep up with the Fedora
Adam Williamson wrote:
you can try and cherry-pick security updates, but then you get the
problem where initial release has Foobar 1.0, then Foobar 3.5 gets
shipped in updates, then a security problem emerges and Foobar 3.5-2
with the security fix gets shipped in updates. You now have a choice
Mike McGrath wrote:
You can't assume that people are only using software we ship. If someone
is using software they've custom developed (think a webapp). We've now
forced them to do work. There's several use cases here, people building
and shipping appliances, webapps, etc. Why would
Peter Jones wrote:
It means we have to update even more software seems like a reason /not/
to ship an update that isn't a bugfix or security fix. Not a reason it
*should* be done.
1. Nowhere was it said the ABI change is NOT a bugfix or security fix. Even
security fixes can require ABI bumps,
Jesse Keating wrote:
On Wed, 2010-03-03 at 01:34 +0100, Björn Persson wrote:
Kevin Kofler wrote:
Even bugfix releases of KDE require a session restart to fully work.
I consider that a serious design flaw in KDE and a strong argument
against releasing any KDE updates to stable releases
James Antill wrote:
The one minor incident being where the project leader had to post to
the world that we'd screwed it up,
Well, I think he overblew it too. ;-) But he just wanted to get the message
out so people can fix it more easily. Still, I don't see how it's a major
issue. The vast
On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote:
You and everyone else, please stop proposing Rawhide as the solution for me
and people who want the same update everything that doesn't break things
policy, it does NOT fit our usecase at all!
If you don't like rawhide for that use
Peter Jones wrote:
To categorize our analogies, mine is an analogy for Fedora, yours is an
analogy for your desktop machine. If you feel like running new untested
packages on your desktop machine, that's fine, we've got rawhide (and
updates-testing) for that. You can also feel free to
Jesse Keating wrote:
That's a fair point, but there are significantly fewer people around to
fix critical issues should they arise on a weekend, and after working 5
weekdays, some of us like taking the weekend off.
Well, I'm around on the weekends and the lack of update pushes for the whole
Peter Jones wrote:
On 03/02/2010 06:15 AM, Kevin Kofler wrote:
X11 is particularly dangerous for this kind of changes, given how low
it is in the software stack and how some code necessarily looks like
(hardware drivers in particular are always scary stuff). The average
leaf package is
Jesse Keating wrote:
If you don't like rawhide for that use case, find another operating
system.
Such as? We're filling a niche, this is one of our unique selling points,
you want to throw out the baby with the bathwater!
I'm tired of waiting for many many hours while we try to compose out
On Wed, 2010-03-03 at 02:33 +0100, Kevin Kofler wrote:
But the problem is what to do if the testing ALREADY failed. Then the best
strategy is to fix the problem ASAP, bypassing testing this time, to get the
regression out of the way.
So testing failed, ergo the best way to fix it is to
On Wed, 2010-03-03 at 02:37 +0100, Kevin Kofler wrote:
Jesse Keating wrote:
That's a fair point, but there are significantly fewer people around to
fix critical issues should they arise on a weekend, and after working 5
weekdays, some of us like taking the weekend off.
Well, I'm around
On Tue, Mar 02, 2010 at 05:19:03PM -0800, Jesse Keating wrote:
On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote:
On the other hand, your usecase has a solution, it's called CentOS.
Wrong answer. Fedora can provide rapid adoption of new technology in
it's 6 month release cycle. It can
On Tue, 2 Mar 2010, Matthew Woehlke wrote:
Jesse Keating wrote:
On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote:
You and everyone else, please stop proposing Rawhide as the solution for me
and people who want the same update everything that doesn't break things
policy, it does NOT
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
Such as? We're filling a niche, this is one of our unique selling points,
you want to throw out the baby with the bathwater!
Who is this we you keep speaking of? When did huge dumps of updates
in supposedly stable releases become an
On 03/02/2010 06:06 PM, Björn Persson wrote:
Jesse Keating wrote:
On Wed, 2010-03-03 at 01:34 +0100, Björn Persson wrote:
Kevin Kofler wrote:
Even bugfix releases of KDE require a session restart to fully work.
I consider that a serious design flaw in KDE and a strong argument
against
Chris Adams wrote:
Who is this we you keep speaking of? When did huge dumps of updates
in supposedly stable releases become an official selling point of
Fedora?
It just happened, de facto. Probably because it's filling a niche other
distros are ignoring.
Kevin Kofler
--
devel
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
Chris Adams wrote:
Who is this we you keep speaking of? When did huge dumps of updates
in supposedly stable releases become an official selling point of
Fedora?
It just happened, de facto. Probably because it's filling a niche
Seth Vidal wrote:
I do not agree Kevin's view is incumbent. I think what's happened is we
exploded in size when extras came in and when we merged core and extras
and we lost control over the process and over assimilating what was the
CORE process onto extras.
But the Core process wasn't as
On 03/02/2010 08:55 PM, Matthew Woehlke wrote:
Jesse Keating wrote:
On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote:
You and everyone else, please stop proposing Rawhide as the solution for me
and people who want the same update everything that doesn't break things
policy, it does NOT
Jesse Keating wrote:
Except there aren't enough key people available on the weekend to clean
up the crap if something goes wrong.
On the other hand, several of our volunteer packagers are more likely to be
around and have time to fix things on the weekend than during workdays. (I
was one of
Chris Adams wrote:
Who is the we?
What I said was We're filling a niche as in Fedora is filling a niche.
This is not saying who is behind that (I'd say it just de facto happened,
without anybody in particular initiating the process) nor whose niche is
being filled (which shouldn't matter, as
On Wed, 3 Mar 2010, Kevin Kofler wrote:
Seth Vidal wrote:
Again, I fail to see that mess. To me we're actually doing a great job!
We've made a mess and as a member of fesco I'd expect you to be helping in
cleaning up the mess, not making it worse b/c fesco HAS to be about the
long term
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
What I said was We're filling a niche as in Fedora is filling a niche.
This is not saying who is behind that (I'd say it just de facto happened,
without anybody in particular initiating the process) nor whose niche is
being filled
On Wed, 2010-03-03 at 02:52 +0100, Kevin Kofler wrote:
Such as? We're filling a niche, this is one of our unique selling points,
you want to throw out the baby with the bathwater!
Your baby is my bathwater. I don't want the operating system you're
trying to build. If you feel that there is a
1 - 100 of 357 matches
Mail list logo
