I wrote:
> The election process, on the other hand, is working very badly: only a
> small portion of the eligible voters actually casts a vote (and even for
> those, there are no stats on how many cast all-0 votes), and several
> people who did vote expressed unhappiness about the available candida
Adam Williamson wrote:
> How do we decide which SIGs trump which other SIGs if they disagree?
An arbitration committee can decide in what SIG's area the decision falls.
But they should NOT decide the issue (they should ignore entirely, or
ideally not even know, which SIG holds what position), ju
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
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
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 10:52 -0500, Chris Adams wrote:
> Once upon a time, Kevin Kofler 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
-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
- --
http://home.comcen.com
Once upon a time, Kevin Kofler 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 fails.
That's y
On Fri, Aug 13, 2010 at 18:20:29 +0200,
Kevin Kofler 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 maintainers (and you, ap
On Fri, Aug 13, 2010 at 06:20:29PM +0200, Kevin Kofler 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 maintainers (and you
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
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
devel@lists.f
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 wo
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 imag
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
On Fri, Aug 13, 2010 at 16:54:22 +0200,
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
Once upon a time, Kevin Kofler 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 (technical, cosmeti
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 ker
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 some
Once upon a time, Kevin Kofler 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 over all packages in
Once upon a time, Kevin Kofler 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.
Again, proof
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
>
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 de
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
devel@lists.fedor
Once upon a time, Kevin Kofler 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 packages, and that even FESCo
-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
>> http://fedo
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 shou
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
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. Back
On Fri, Aug 13, 2010 at 01:18:29 +0200,
Kevin Kofler 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 can fit in a gi
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 Thu, Aug 12, 2010 at 13:27:05 +0200,
Jaroslav Reznik 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 hope to occasi
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 l
-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 always
Jaroslav Reznik wrote:
> On Wednesday, August 11, 2010 04:28:07 pm Michał Piotrowski wrote:
>> Hi,
>>
>> 2010/8/11 Andre Robatino :
>> > Fedora 14 Alpha RC3 is now available [1]. Please refer to the
>> > following pages for download links and testing instructions.
>>
>> I downloaded
>> http://a
Jared K. Smith said the following on 08/11/2010 06:15 AM Pacific Time:
> On Wed, Aug 11, 2010 at 1:01 AM, Adam Williamson wrote:
>> Thanks, Andre! Everyone please note we have the go/no-go meeting for
>> Alpha release tomorrow afternoon at 5pm Eastern time, so we really
>> *really* need as much te
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
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 e
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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/
W dniu 11 sierpnia 2010 17:37 użytkownik Brandon Lozza
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 holy wars ;)
Reg
2010/8/11 Michał Piotrowski
> 2010/8/11 Brandon Lozza :
> > On Wed, Aug 11, 2010 at 11:03 AM, 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-2010081
2010/8/11 Brandon Lozza :
> On Wed, Aug 11, 2010 at 11:03 AM, 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 C
On Wed, Aug 11, 2010 at 11:03 AM, 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 ar
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 reus
On Wednesday, August 11, 2010 04:28:07 pm Michał Piotrowski wrote:
> Hi,
>
> 2010/8/11 Andre Robatino :
> > 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/night
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/11/2010 10:28 AM, Michał Piotrowski wrote:
> Hi,
>
> 2010/8/11 Andre Robatino :
>> Fedora 14 Alpha RC3 is now available [1]. Please refer to the following
>> pages for download links and testing instructions.
>>
>
> I downloaded
> http://alt.
Hi,
2010/8/11 Andre Robatino :
> 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 is too large to fit on t
On Wed, Aug 11, 2010 at 1:01 AM, Adam Williamson wrote:
> Thanks, Andre! Everyone please note we have the go/no-go meeting for
> Alpha release tomorrow afternoon at 5pm Eastern time, so we really
> *really* need as much testing as possible by then.
I have the Go/No-Go meeting in my calendar as Th
On Wed, 2010-08-11 at 00:49 -0400, Andre Robatino wrote:
> Fedora 14 Alpha RC3 is now available [1]. Please refer to the following
> pages for download links and testing instructions.
>
> Installation:
>
> https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
>
> Desktop:
>
> h
Fedora 14 Alpha RC3 is now available [1]. Please refer to the following
pages for download links and testing instructions.
Installation:
https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
Desktop:
https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test
Ideally, all
50 matches
Mail list logo
