Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
To me, this includes shipping a great new
technology such as LZMA SquashFS, without waiting for the upstream kernel.
You've insisted over and over (and over) again that the KDE SIG should
have absolute authority over the KDE
Jesse Keating wrote:
Do you have any sort of proof that it's a political reason? It would
seem to me that our kernel maintainers do not wish to include code that
hasn't been blessed by Linus in our packages.
That's political.
Kevin Kofler
--
devel mailing list
Chris Adams wrote:
Why don't you give the kernel maintainers the same courtesy?
Because LZMA SquashFS is a feature which affects the live images, and almost
exclusively the live images, and as such the SIGs controlling the live
images should be the ones making the decision. This means the 4
On Fri, Aug 13, 2010 at 8:24 PM, Kevin Kofler wrote:
Chris Adams wrote:
Why don't you give the kernel maintainers the same courtesy?
Because LZMA SquashFS is a feature which affects the live images, and
almost
exclusively the live images, and as such the SIGs controlling the live
images
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
Jesse Keating wrote:
Do you have any sort of proof that it's a political reason? It would
seem to me that our kernel maintainers do not wish to include code that
hasn't been blessed by Linus in our packages.
That's political.
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
Because LZMA SquashFS is a feature which affects the live images, and almost
exclusively the live images, and as such the SIGs controlling the live
images should be the ones making the decision.
SIGs don't exist to exercise control
Rahul Sundaram wrote:
Sorry but no. There is only one kernel for the entire distribution and I
rather rely on kernel maintainers expertise on their packages rather than
SIG's trying to dictate what patches the kernel should carry. The SIG
participants are not kernel developers.
But
On Fri, Aug 13, 2010 at 07:16:36AM +0200, Kevin Kofler wrote:
Basically, we're missing out on an important new feature and shipping less
featureful live images than we could for purely political reasons. :-(
The reasons are purely practical. If upstream development is targeting
upstream
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
but it's far from easy for somebody who's
not already an experienced upstream kernel developer to manage that, LKML is
a tough place: there's politics making it hard for new contributors to get
their stuff in, there are many rules
On Fri, Aug 13, 2010 at 16:54:22 +0200,
Kevin Kofler kevin.kof...@chello.at wrote:
Chris Adams wrote:
Why don't you give the kernel maintainers the same courtesy?
Because LZMA SquashFS is a feature which affects the live images, and almost
exclusively the live images, and as such the
On 08/13/2010 08:58 PM, Kevin Kofler wrote:
But sometimes the maintainers of individual package maintainers have to cave
in to allow for a coordinated distribution experience. That's why we are a
distribution and not a bunch of packages thrown together.
Coordinated distribution experience
Chris Adams wrote:
Again, proof? They have enough patches to sort through every release as
it is, and they don't want to add more.
This doesn't strike me as a strong enough TECHNICAL reason to reject a
feature which would make all our live images better. Both the GNOME and the
KDE live image
On Fri, Aug 13, 2010 at 05:51:57PM +0200, Kevin Kofler wrote:
Chris Adams wrote:
Again, proof? They have enough patches to sort through every release as
it is, and they don't want to add more.
This doesn't strike me as a strong enough TECHNICAL reason to reject a
feature which would
Chris Adams wrote:
SIGs don't exist to exercise control over all packages in the
distribution (or all packages that tangentially affect them).
As I said elsewhere on this list, that's exactly where our organizational
structure fails.
Kevin Kofler
--
devel mailing list
Bruno Wolff III wrote:
I really think the benefits and costs need to be looked at on a case by
case basis and the package maintainers should be the ones making the call.
The problem is, the kernel maintainers (and you, apparently) don't seem to
realize what big difference a 10% improvement in
On Fri, Aug 13, 2010 at 18:20:29 +0200,
Kevin Kofler kevin.kof...@chello.at wrote:
Bruno Wolff III wrote:
I really think the benefits and costs need to be looked at on a case by
case basis and the package maintainers should be the ones making the call.
The problem is, the kernel
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
Chris Adams wrote:
SIGs don't exist to exercise control over all packages in the
distribution (or all packages that tangentially affect them).
As I said elsewhere on this list, that's exactly where our organizational
structure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/12/2010 11:15 PM, Michael Cronenworth wrote:
By network install, I meant using a local intranet-based HTTP or FTP
server to install from.
Ok fair enough, I misunderstood what you meant. My apologies.
Regards
- --
On Fri, 2010-08-13 at 10:52 -0500, Chris Adams wrote:
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
but it's far from easy for somebody who's
not already an experienced upstream kernel developer to manage that, LKML
is
a tough place: there's politics making it hard for
On Fri 13 August 2010 18:44:37 Adam Williamson wrote:
Perhaps the problem isn't the projects,
after all?
The KDE Firefox integration patches were written by openSuSE developers, not
Kev.
--
Ryan Rix
== http://hackersramblings.wordpress.com | http://rix.si/ ==
== http://rix.si/page/contact/
On Fri, 2010-08-13 at 18:16 +0200, Kevin Kofler wrote:
Chris Adams wrote:
SIGs don't exist to exercise control over all packages in the
distribution (or all packages that tangentially affect them).
As I said elsewhere on this list, that's exactly where our organizational
structure fails.
On Fri, 2010-08-13 at 18:49 -0700, Ryan Rix wrote:
On Fri 13 August 2010 18:44:37 Adam Williamson wrote:
Perhaps the problem isn't the projects,
after all?
The KDE Firefox integration patches were written by openSuSE developers, not
Kev.
Kevin's the one complaining about how hard they
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It is common for iso size to be over the 700MB target size due to most
developers and testers doing their work in virtual machines these days.
Therefore, iso size is not an issue. And bringing it back down to below
the 700MB size limit for CD is
On Thursday, August 12, 2010 01:10:08 pm Chris Jones wrote:
It is common for iso size to be over the 700MB target size due to most
developers and testers doing their work in virtual machines these days.
Therefore, iso size is not an issue. And bringing it back down to below
the 700MB size
On Thu, Aug 12, 2010 at 13:27:05 +0200,
Jaroslav Reznik jrez...@redhat.com wrote:
Problem is not an image (we will provide it in the future, forever), the
issue
is size constraint - software grows faster and faster, we have more
dependencies
etc. - means less software on LiveCD...
I
Bruno Wolff III wrote:
I hope to occasionally push back a little against this. When LZMA squashfs
makes it upstream (it looks like it won't happen in time for F14) we will
probably gain about 10% on what we can fit in a given size image.
It's quite sad that we're waiting for upstream there.
On Fri, Aug 13, 2010 at 01:18:29 +0200,
Kevin Kofler kevin.kof...@chello.at wrote:
Bruno Wolff III wrote:
I hope to occasionally push back a little against this. When LZMA squashfs
makes it upstream (it looks like it won't happen in time for F14) we will
probably gain about 10% on what we
Bruno Wolff III wrote:
We'll until Lougher writes something that Linus will accept, we need to
wait.
But WHY? IMHO, an upstream tarball is just a base to apply our patches onto.
We shouldn't be prisoners of upstream, especially when upstream processes
are just too slow to fit our needs.
Hi,
Bruno Wolff III wrote:
We'll until Lougher writes something that Linus will accept, we
need to wait.
But WHY? IMHO, an upstream tarball is just a base to apply our
patches onto.
Because the kernel team doesn't agree with you, of course.
This should be unsurprising,
Chris Ball wrote:
This should be unsurprising, because the stated objectives of the
Fedora project as a whole don't agree with you either:
http://fedoraproject.org/wiki/Objectives
http://fedoraproject.org/wiki/Staying_close_to_upstream_projects
Those same objectives say that Fedora should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/12/2010 10:16 PM, Kevin Kofler wrote:
Chris Ball wrote:
This should be unsurprising, because the stated objectives of the
Fedora project as a whole don't agree with you either:
http://fedoraproject.org/wiki/Objectives
Hi,
2010/8/11 Andre Robatino robat...@fedoraproject.org:
Fedora 14 Alpha RC3 is now available [1]. Please refer to the following
pages for download links and testing instructions.
I downloaded
http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-x86_64-20100810.15.iso
- it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/11/2010 10:28 AM, Michał Piotrowski wrote:
Hi,
2010/8/11 Andre Robatino robat...@fedoraproject.org:
Fedora 14 Alpha RC3 is now available [1]. Please refer to the following
pages for download links and testing instructions.
I
On Wednesday, August 11, 2010 04:28:07 pm Michał Piotrowski wrote:
Hi,
2010/8/11 Andre Robatino robat...@fedoraproject.org:
Fedora 14 Alpha RC3 is now available [1]. Please refer to the following
pages for download links and testing instructions.
I downloaded
Michał Piotrowski on 08/11/2010 09:28 AM wrote:
I
downloadedhttp://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-x86_64-20100810.15.iso
- it is too large to fit on the CD.
This is the Green Age what are you doing wasting a CD? Mother earth
frowns on you. Be kind and reuse
On Wed, Aug 11, 2010 at 11:03 AM, Michael Cronenworth m...@cchtml.comwrote:
Michał Piotrowski on 08/11/2010 09:28 AM wrote:
I downloadedhttp://
alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-x86_64-20100810.15.iso
- it is too large to fit on the CD.
This is the Green Age
2010/8/11 Brandon Lozza bran...@pwnage.ca:
On Wed, Aug 11, 2010 at 11:03 AM, Michael Cronenworth m...@cchtml.com
wrote:
Michał Piotrowski on 08/11/2010 09:28 AM wrote:
I
downloadedhttp://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-x86_64-20100810.15.iso
- it is too
2010/8/11 Michał Piotrowski mkkp...@gmail.com
2010/8/11 Brandon Lozza bran...@pwnage.ca:
On Wed, Aug 11, 2010 at 11:03 AM, Michael Cronenworth m...@cchtml.com
wrote:
Michał Piotrowski on 08/11/2010 09:28 AM wrote:
I
downloadedhttp://
W dniu 11 sierpnia 2010 17:37 użytkownik Brandon Lozza
bran...@pwnage.ca napisał:
Political discussion is EXTREMELY off topic and will cause flame wars.
Environmental talk is politics, especially the stuff you're bringing up with
video links.
Sorry, I did not know that the music here evokes
Brandon Lozza on 08/11/2010 10:13 AM wrote:
Keep the greening politics to yourself please
So that there are no further misunderstands or continuation of this
tangent - I was being sarcastic.
/endTangent
--
devel mailing list
devel@lists.fedoraproject.org
On 11/08/10 16:37, Brandon Lozza wrote:
Political discussion is EXTREMELY off topic and will cause flame wars.
Environmental talk is politics, especially the stuff you're bringing up
with video links.
Actually power-saving was a feature of Fedora and Linux in general iirc.
Common sence
On Wed, 2010-08-11 at 10:03 -0500, Michael Cronenworth wrote:
Michał Piotrowski on 08/11/2010 09:28 AM wrote:
I
downloadedhttp://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-x86_64-20100810.15.iso
- it is too large to fit on the CD.
This is the Green Age what are you
Jaroslav Reznik wrote:
On Wednesday, August 11, 2010 04:28:07 pm Michał Piotrowski wrote:
Hi,
2010/8/11 Andre Robatino robat...@fedoraproject.org:
Fedora 14 Alpha RC3 is now available [1]. Please refer to the
following pages for download links and testing instructions.
I downloaded
43 matches
Mail list logo
