[Test-Announce] Fedora 14 Alpha RC3 Available Now!

[Andre Robatino]

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 Alpha priority test cases for installation [2] and desktop
[3] should pass in order to meet the Alpha Release Criteria [4].  Help
is available on #fedora-qa on irc.freenode.net [5], or on the test list [6].

[1] http://poelstra.fedorapeople.org/schedules/f-14/f-14-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[3] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
[4] https://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Criteria
[5] irc://irc.freenode.net/fedora-qa
[6] https://admin.fedoraproject.org/mailman/listinfo/test


_______________________________________________
test-announce mailing list
test-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce

[Adam Williamson]

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:
>  
>  https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test
>  
>  Ideally, all Alpha priority test cases for installation [2] and desktop
>  [3] should pass in order to meet the Alpha Release Criteria [4].  Help
>  is available on #fedora-qa on irc.freenode.net [5], or on the test list [6].
>  
>  [1] http://poelstra.fedorapeople.org/schedules/f-14/f-14-quality-tasks.html
>  [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing
>  [3] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
>  [4] https://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Criteria
>  [5] irc://irc.freenode.net/fedora-qa
>  [6] https://admin.fedoraproject.org/mailman/listinfo/test 
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. Any help you all can
give to fill out the install and desktop matrices would be greatly
appreciated, focusing on the Alpha tests. The live images are not
available yet, but coming soon. There will be live images for all four
main desktops.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

_______________________________________________
test-announce mailing list
test-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce

[Jared K. Smith]

On Wed, Aug 11, 2010 at 1:01 AM, Adam Williamson <awilliam(a)redhat.com&gt; 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 Thursday, August 12,
2010, @ 12:00 AM UTC ( *20:00 EDT/17:00 PDT,
Wednesday, August 11, 2010* ).  I just want to make sure we're all on
the same schedule here.

--
Jared Smith
Fedora Project Leader

[John Poelstra]

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<awilliam(a)redhat.com>  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 Thursday, August 12,
>  2010, @ 12:00 AM UTC ( *20:00 EDT/17:00 PDT,
>  Wednesday, August 11, 2010* ).  I just want to make sure we're all on
>  the same schedule here.
>
>  --
>  Jared Smith
>  Fedora Project Leader 
The correct time for this meeting is:
Thursday, August 12, 2010, @ 12:00 AM UTC

In other words, if you are in the USA, it will happen TODAY at:

20:00 Eastern or 17:00 Pacific

John

p.s. Sorry for the confusion as realize this contradicts the time that 
was on the detailed schedule.  Hopefully the three extra hours helps :)

[Michał Piotrowski]

Hi,

2010/8/11 Andre Robatino <robatino(a)fedoraproject.org&gt;:
>  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...
- it is too large to fit on the CD.

Regards,
Michal

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/11/2010 10:28 AM, Michał Piotrowski wrote:
>  Hi,
>  
>  2010/8/11 Andre Robatino <robatino(a)fedoraproject.org&gt;:
> > 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...
>  - it is too large to fit on the CD.
>  
>  Regards,
>  Michal 
That's very common with the pre-releases. They usually need to be on a DVD.

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEUEARECAAYFAkxiucgACgkQeiVVYja6o6OwbQCgjCygqz0r7hHngIpjjoe9JFmh
> 9PEAl1s4Xt/XWOPZUJj/6afEc3J40h8=
> =J6WU
> -----END PGP SIGNATURE-----

[Jaroslav Reznik]

On Wednesday, August 11, 2010 04:28:07 pm Michał Piotrowski wrote:
>  Hi,
>  
>  2010/8/11 Andre Robatino <robatino(a)fedoraproject.org&gt;:
>  > 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 the CD. 
Same for Plasma Desktop ISO - we are oversized now, we know it.

R.

>  Regards,
>  Michal 
-- 
Jaroslav Řezník <jreznik(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat, Inc.                               http://cz.redhat.com/

[Kevin Kofler]

Jaroslav Reznik wrote:

>  On Wednesday, August 11, 2010 04:28:07 pm Michał Piotrowski wrote:
> > Hi,
> > 
> > 2010/8/11 Andre Robatino <robatino(a)fedoraproject.org&gt;:
> > > 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 the CD.
>  
>  Same for Plasma Desktop ISO - we are oversized now, we know it. 
FYI, what he calls the "Plasma Desktop ISO" is the KDE-Live spin. KDE 
upstream now wants people to refer to "KDE" only when talking about the 
project, the desktop is the "Plasma Desktop" or "KDE Plasma Desktop",
the 
libraries are the "KDE Development Platform", the applications are the "KDE

Applications" and the whole thing is the "KDE Software Compilation" (but 
upstream prefers it if people are specific about what parts of the 
compilation they talk about rather than just using s/KDE/KDE SC/g).

We hope that we will be able to meet the size constraints for the KDE 
(Plasma Desktop) spin for the Beta and Final. We just had other priorities 
for the Alpha.

        Kevin Kofler

[Michael Cronenworth]

Michał Piotrowski on 08/11/2010 09:28 AM wrote:
>  I
> downloadedhttp://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/d...
>  - 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 your ISO by installing via the network. 
I'd recommend a USB drive but I think that is still broken.

[Brandon Lozza]

On Wed, Aug 11, 2010 at 11:03 AM, Michael Cronenworth <mike(a)cchtml.com&gt;wrote:

>  Michał Piotrowski on 08/11/2010 09:28 AM wrote:
>  > I downloadedhttp://
>  alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-x86_64-201...
>  > - 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 your ISO by installing via the network.
>  I'd recommend a USB drive but I think that is still broken.
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  
Keep the greening politics to yourself please

[Michał Piotrowski]

2010/8/11 Brandon Lozza <brandon(a)pwnage.ca&gt;:
>  On Wed, Aug 11, 2010 at 11:03 AM, Michael Cronenworth
> <mike(a)cchtml.com&gt;
>  wrote:
> >
> > Michał Piotrowski on 08/11/2010 09:28 AM wrote:
> > > I
> > >
> downloadedhttp://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/d...
> > > - it is too large to fit on the CD.
> >
> > This is the "Green Age" what are you doing wasting a CD? Mother earth
I love mother earth http://www.youtube.com/watch?v=EC5XgyrzSt0 :)

> > frowns on you. Be kind and reuse your ISO by installing via the
> network. 
My network is too slow for net install of full desktop. I'm using CD-RW

> > I'd recommend a USB drive but I think that is still broken.
> > --
> > devel mailing list
> > devel(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
>
>  Keep the greening politics to yourself please 
I think it's right to recall from time to time others about caring for
the environment

Regards,
M

[Brandon Lozza]

2010/8/11 Michał Piotrowski <mkkp4x4(a)gmail.com&gt;

>  2010/8/11 Brandon Lozza <brandon(a)pwnage.ca&gt;:
>  > On Wed, Aug 11, 2010 at 11:03 AM, Michael Cronenworth <mike(a)cchtml.com&gt;
>  > wrote:
>  >>
>  >> Michał Piotrowski on 08/11/2010 09:28 AM wrote:
>  >> > I
>  >> > downloadedhttp://
>  alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-x86_64-201...
>  >> > - it is too large to fit on the CD.
>  >>
>  >> This is the "Green Age" what are you doing wasting a CD? Mother earth
>
>  I love mother earth http://www.youtube.com/watch?v=EC5XgyrzSt0 :)
>
>  >> frowns on you. Be kind and reuse your ISO by installing via the network.
>
>  My network is too slow for net install of full desktop. I'm using CD-RW
>
>  >> I'd recommend a USB drive but I think that is still broken.
>  >> --
>  >> devel mailing list
>  >> devel(a)lists.fedoraproject.org
>  >> https://admin.fedoraproject.org/mailman/listinfo/devel
>  >
>  > Keep the greening politics to yourself please
>
>  I think it's right to recall from time to time others about caring for
>  the environment
>
>  Regards,
>  M
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  
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.

[Michał Piotrowski]

W dniu 11 sierpnia 2010 17:37 użytkownik Brandon Lozza
<brandon(a)pwnage.ca&gt; 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 ;)

Regards,
M

[Frank Murphy]

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 existed long before "Green" became a political word,
I aggre with you that political\politics is ot.
But I would mabye advise those usind CDs' for testiing to use
DVD-RW in various shades, as testing.iso may be oversized for varying 
reasons.

That is not politics, it's using the litte grey matter left,
along with saving some blaas.

-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of Fedora

[Michael Cronenworth]

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>

[Adam Williamson]

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/d...
>  > - 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 your ISO by installing via the network. 
>  I'd recommend a USB drive but I think that is still broken. 
? Not AFAIK.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Chris Jones]

-----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 aimed for for the final release(s).

And Michael Cronenworth, some of us (myself included) live in countries
where broadband is still way behind where it should be for the year
2010. Namingly where I live, Australia, where high speed b/band suitable
for network installs comes at a rather large cost. Therefore, we resort
to downloading images instead for convenience.

Regards


- -- 
http://home.comcen.com.au/foxmulder881/signature/details.html
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJMY9aQAAoJEDb/U0a6C32qIswIAINyfvyYV8BHK/Jj4Y9FOIrM
> XZA5bimQ/BE7zo1MWmJQYHWYXakNjjjzG5TWKgW2JotrOX+ECZcSiLZ2c52QfNw1
> bf+ZPThzML1pttH6nli2nWxfyzaXI+W757uawygMPiBgYtsDpkSYL+uYNMc/M//j
> cmGCO+n4Y1L9lDLKMeaG9P3Sbt85dXWz3dJDebaA84hpaUbeshj1mvsB2iGFaAUM
> 8oIyK9BFFnFaEqpr5aTAhluF77ymEes2OcdB17ibNj4uGUkiDfSL1PEu0MPif1Ve
> nRn5wzifyqS/UgtgXl2iVdiDCRGw4E9UK9HMFkvTGi3fKID/NFSk8MSVXFOxAQo=
> =bFa0
> -----END PGP SIGNATURE-----

[Jaroslav Reznik]

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 limit for CD is always aimed for for the final release(s).
>  
>  And Michael Cronenworth, some of us (myself included) live in countries
>  where broadband is still way behind where it should be for the year
>  2010. Namingly where I live, Australia, where high speed b/band suitable
>  for network installs comes at a rather large cost. Therefore, we resort
>  to downloading images instead for convenience. 
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... 

Jaroslav
 
>  Regards 
-- 
Jaroslav Řezník <jreznik(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat, Inc.                               http://cz.redhat.com/

[Bruno Wolff III]

On Thu, Aug 12, 2010 at 13:27:05 +0200,
  Jaroslav Reznik <jreznik(a)redhat.com&gt; 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 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. Another
change that could happen is droppong the embedded ext3 image and use squashfs
directly. (Selinux should now be usable on squashsfs file systems.) That
might gain us a bit more space.

Also looking forward, USB drives are less limited in space and faster
(especially seek time) than spinning disks and make more sense for live
images in many circumstances.

[Kevin Kofler]

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. The feature exists, we 
could ship it, yet we prefer crippling our live images by dropping more and 
more applications to meet the size constraints with obsolete compression 
technology. What happened to the leading-edge Fedora?

>  Another change that could happen is droppong the embedded ext3 image
> and
>  use squashfs directly. (Selinux should now be usable on squashsfs file
>  systems.) That might gain us a bit more space. 
Won't that break liveinst?

        Kevin Kofler

[Bruno Wolff III]

On Fri, Aug 13, 2010 at 01:18:29 +0200,
  Kevin Kofler <kevin.kofler(a)chello.at&gt; 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 given size image.
>  
>  It's quite sad that we're waiting for upstream there. The feature exists, we 
>  could ship it, yet we prefer crippling our live images by dropping more and 
>  more applications to meet the size constraints with obsolete compression 
>  technology. What happened to the leading-edge Fedora? 
We'll until Lougher writes something that Linus will accept, we need to wait.
I think someone paid him to work on xattr, so it makes sense that he would
give that higher priority.

>  > Another change that could happen is droppong the embedded ext3
> image and
>  > use squashfs directly. (Selinux should now be usable on squashsfs file
>  > systems.) That might gain us a bit more space.
>  
>  Won't that break liveinst? 
I am not sure. I haven't looked into it too deeply yet. I have enough stuff
to do that I probably won't get to it real soon. I would guess there would
be some way to make it work, but it might be a little different than
what happens now.

[Kevin Kofler]

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. Backporting, sometimes from more or less 
unofficial development branches, is a required part of being on the leading 
edge. We cannot be "First" with a religious adhesion to upstream.

        Kevin Kofler

[Chris Ball]

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, 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

- Chris.
-- 
Chris Ball   <cjb(a)laptop.org&gt;
One Laptop Per Child

[Kevin Kofler]

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 "be on the leading edge of free 
and open source technology". To me, this includes shipping a great new 
technology such as LZMA SquashFS, without waiting for the upstream kernel. 
"Staying close to upstream projects" isn't without exceptions either. In 
addition, another objective of Fedora is to "include a wide range of 
packages", so we should support technologies which allow us to ship more 
packages on our live images.

Basically, we're missing out on an important new feature and shipping less 
featureful live images than we could for purely political reasons. :-(

        Kevin Kofler

[Jesse Keating]

-----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://fedoraproject.org/wiki/Staying_close_to_upstream_projects
>  
>  Those same objectives say that Fedora should "be on the leading edge of free 
>  and open source technology". To me, this includes shipping a great new 
>  technology such as LZMA SquashFS, without waiting for the upstream kernel. 
>  "Staying close to upstream projects" isn't without exceptions either. In 
>  addition, another objective of Fedora is to "include a wide range of 
>  packages", so we should support technologies which allow us to ship more 
>  packages on our live images.
>  
>  Basically, we're missing out on an important new feature and shipping less 
>  featureful live images than we could for purely political reasons. :-(
>  
>          Kevin Kofler
>   
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.  Doing so has burned us in
the past, and perhaps this code has real issues that are keeping it out
of upstream.  We should not presume to be smarter than upstream,
particularly when the kernel is involved.  The package maintainer
ultimately has control over what does or does not go into their package,
and in this case they seem to be favoring sticking close to upstream as
opposed to throwing in code willy nilly because it looks cool.  Upstream
has a code review process for a reason.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkxk14AACgkQ4v2HLvE71NV3AACfSruOoxjL2ZY4R6H/TukKRmr/
> 5KIAoICOg+OAh8Ho+tcECINMHOHNF2ij
> =L+lK
> -----END PGP SIGNATURE-----

"Staying close to upstream"

[Matt McCutchen]

On Thu, 2010-08-12 at 22:26 -0700, 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.  Doing so has burned us in
>  the past, and perhaps this code has real issues that are keeping it out
>  of upstream.  We should not presume to be smarter than upstream,
>  particularly when the kernel is involved.  The package maintainer
>  ultimately has control over what does or does not go into their package,
>  and in this case they seem to be favoring sticking close to upstream as
>  opposed to throwing in code willy nilly because it looks cool.  Upstream
>  has a code review process for a reason. 
IMO, staying close to upstream is simply a means to the end of shipping
better software, and Fedora should be prepared to deviate from upstream
when the benefit is compelling compared to the additional maintenance
cost (though it's hard to say whether this standard is met in any given
case).  That's why I'm so frustrated that Fedora seems to be committed
to keeping the Mozilla trademarks, which moot any discussion of whether
to deviate for those packages.  But this is only my opinion.  Fedora is
welcome to set its own course, and I am welcome to fork (in theory at
least).

-- 
Matt

"Staying close to upstream"

[Jesse Keating]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/12/2010 10:59 PM, Matt McCutchen wrote:
>   That's why I'm so frustrated that Fedora seems to be
> committed
>  to keeping the Mozilla trademarks, which moot any discussion of whether
>  to deviate for those packages.  But this is only my opinion.  Fedora is
>  welcome to set its own course, and I am welcome to fork (in theory at
>  least).
>   
You're making an assumption here that it's the trademarks that prevent
any deviation from upstream, when in fact the maintainer has stated many
times that regardless of trademarks, he would not deviate from upstream
given the sensitivity of a software suite that has to connect to the
wild wild web.  The maintenance burden of upstream deviation is greater
than the maintainer would like to undertake, as is the risk of security
issues and stability.

The kernel folks are likely walking the same path.  For core components
such as the kernel and our web browser, this does not seem like a bad
thing at all.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkxk5lkACgkQ4v2HLvE71NXpVQCfe9w1hgVQgGbN+fQ9hBUoWHSP
> KyAAn2rd71W8ZsCPIMdDPnUsNB2rr5wL
> =WEOp
> -----END PGP SIGNATURE-----

"Staying close to upstream"

[Kevin Kofler]

Jesse Keating wrote:
>  You're making an assumption here that it's the trademarks
> that prevent
>  any deviation from upstream, when in fact the maintainer has stated many
>  times that regardless of trademarks, he would not deviate from upstream
>  given the sensitivity of a software suite that has to connect to the
>  wild wild web.  The maintenance burden of upstream deviation is greater
>  than the maintainer would like to undertake, as is the risk of security
>  issues and stability. 
But the end effect is:
* Firefox, Thunderbird and xulrunner are the ONLY packages in the whole 
Fedora which are NOT open to provenpackager! (The reason given: trademarks.) 
IMHO this shows that the exception process which allows closing packages to 
provenpackager is useless and needs to be abolished, the problem is with 
those particular packages.
* This policy of sticking religiously to upstream means we are not shipping 
KDE integration for Firefox, despite patches from openSUSE existing. This 
makes Firefox suck under KDE. Our Firefox maintainers refuse to do anything 
about it.

In addition, trademarks are often given as one of the reasons they stick so 
closely to upstream when we complain about that, by the very same 
maintainers who then claim it's not about trademarks when we want to get the 
trademarks removed. Their position is not consistent: if we ask for non-
upstream changes, they say the trademarks forbid them so they can't do 
anything, if we ask for getting the trademarks removed, they say that it 
wouldn't change anything anyway. Either they're just using the trademarks as 
an excuse for their laziness, or the trademarks are the problem and need to 
be removed, it's one or the other.

        Kevin Kofler

"Staying close to upstream"

[Rahul Sundaram]

On Fri, Aug 13, 2010 at 8:21 PM, Kevin Kofler  wrote:
   . Their position is not consistent: if we ask for non-

>  upstream changes, they say the trademarks forbid them so they
> can't do
>  anything, if we ask for getting the trademarks removed, they say that it
>  wouldn't change anything anyway. Either they're just using the trademarks
>  as
>  an excuse for their laziness, or the trademarks are the problem and need to
>  be removed, it's one or the other.
>  
------

You seem to refuse to accept that Firefox maintainers in Fedora don't want
the KDE patches without it getting upstream.  Firefox is one of the
frequently updated software and non-upstream patches create a burden.  Why
aren't the patches upstream?  You are fighting in the wrong place.  The
maintainers decision in this matter is final.   Please accept the difference
of opinion and move on.  Repeating your opinions over and over again changes
nothing.

Rahul

"Staying close to upstream"

[Kevin Kofler]

Rahul Sundaram wrote:
>  You seem to refuse to accept that Firefox maintainers in Fedora
> don't want
>  the KDE patches without it getting upstream.  Firefox is one of the
>  frequently updated software and non-upstream patches create a burden.  Why
>  aren't the patches upstream?  You are fighting in the wrong place.  The
>  maintainers decision in this matter is final.   Please accept the
>  difference of opinion and move on.  Repeating your opinions over and over
>  again changes nothing. 
But applying KDE integration patches should be a KDE SIG matter, the 
individual package maintainers should have to comply with KDE SIG decisions 
on the matter.

How can we offer an integrated desktop experience when individual 
maintainers refuse to work with us, and FESCo only makes our work harder 
with useless bureaucratic policies instead of helping us achieve our goals 
in a way coordinated throughout the distribution?

        Kevin Kofler

"Staying close to upstream"

[Rahul Sundaram]

 On 08/13/2010 08:49 PM, Kevin Kofler wrote:
>  But applying KDE integration patches should be a KDE SIG matter, the
>
>  individual package maintainers should have to comply with KDE SIG decisions 
>  on the matter. 
No.  No SIG's have any authority whatsoever over individual package
maintainers outside the packages the team maintains.  No one needs to
"comply" with your requirements.   

>  How can we offer an integrated desktop experience when individual 
>  maintainers refuse to work with us, and FESCo only makes our work harder 
>  with useless bureaucratic policies instead of helping us achieve our goals 
>  in a way coordinated throughout the distribution? 
If you want a integrated experience,  don't work around upstream.  Push
your patches and get it merged there.  Do not try to arm twist Firefox
maintainers to merge patches they do not want to maintain circumventing
upstream.  

Rahul

"Staying close to upstream"

[Kevin Kofler]

Rahul Sundaram wrote:
>  No.  No SIG's have any authority whatsoever over individual
> package
>  maintainers outside the packages the team maintains.  No one needs to
>  "comply" with your requirements. 
That's exactly Fedora's organizational problem.

KDE SIG should have authority over anything KDE-related. Likewise, the Perl 
SIG should have authority over anything Perl-related: if the Perl SIG 
decides that a new Perl developer @ RH should have commit access to all 
perl-* packages, it should be their decision to do so, it was really 
counterproductive of FESCo to interfere with that!

>  If you want a integrated experience,  don't work around upstream.
>  Push
>  your patches and get it merged there. 
Good luck getting Mozilla to accept anything. Just like the kernel, they're 
a very hard to work with upstream. If you don't know the right people, your 
stuff just doesn't get in. :-(

Providing system integration is exactly what a distribution is for. You will 
never achieve an integrated experience by just throwing together disparate 
upstream tarballs.

        Kevin Kofler

"Staying close to upstream"

[Rahul Sundaram]

 On 08/13/2010 09:17 PM, Kevin Kofler wrote:
>  Rahul Sundaram wrote:
> > No.  No SIG's have any authority whatsoever over individual package
> > maintainers outside the packages the team maintains.  No one needs to
> > "comply" with your requirements.
>  That's exactly Fedora's organizational problem.
>
>  KDE SIG should have authority over anything KDE-related.  
You are calling a lot of things including the kernel and Firefox KDE
related even though KDE Spin does not even include Firefox by default. 
In other words, you want a organization policy that lets you dictate to
other maintainers what patches they should merge even if the packages
are only tangentially related such as Firefox.  This is ultimately a
power grab and not healthy and will never be acceptable.  Besides,  you
repeatedly refer to the "KDE SIG" but KDE SIG has made no formal request
to the Firefox maintainers.    I can't accept that you represent all of
KDE SIG's viewpoint in this matter.  This appears just your person view
points. 

Rahul

"Staying close to upstream"

[Kevin Kofler]

Rahul Sundaram wrote:
>  You are calling a lot of things including the kernel and Firefox KDE
>  related even though KDE Spin does not even include Firefox by default.
>  In other words, you want a organization policy that lets you dictate to
>  other maintainers what patches they should merge even if the packages
>  are only tangentially related such as Firefox.  This is ultimately a
>  power grab and not healthy and will never be acceptable.  Besides,  you
>  repeatedly refer to the "KDE SIG" but KDE SIG has made no formal request
>  to the Firefox maintainers.    I can't accept that you represent all of
>  KDE SIG's viewpoint in this matter.  This appears just your person view
>  points. 
Uh, AFAIK Jaroslav Řezník has talked to both the OO.o and the Firefox 
maintainers about KDE integration (there are maintainers or comaintainers of 
both in the same RH office), in both cases with little success so far. In 
OO.o's case, some or all of the KDE stuff actually went upstream (I'm not 
sure if it's finally all upstreamed or if there are still patches from go-oo 
needed; I'll also note that we're the only major distro not to use go-oo), 
the maintainers said they'd look into enabling it, nothing happened. In 
Firefox's case, the answer was just "trademarks" and so we never bothered 
making a formal request because we know it wouldn't get anywhere.

        Kevin Kofler

"Staying close to upstream"

[Rahul Sundaram]

 On 08/13/2010 10:33 PM, Kevin Kofler wrote:
>  Uh, AFAIK Jaroslav Řezník has talked to both the OO.o and the Firefox 
>  maintainers about KDE integration (there are maintainers or comaintainers of 
>  both in the same RH office), in both cases with little success so far. In 
>  OO.o's case, some or all of the KDE stuff actually went upstream (I'm not 
>  sure if it's finally all upstreamed or if there are still patches from go-oo 
>  needed; I'll also note that we're the only major distro not to use go-oo), 
>  the maintainers said they'd look into enabling it, nothing happened. In 
>  Firefox's case, the answer was just "trademarks" and so we never bothered 
>  making a formal request because we know it wouldn't get anywhere. 
My point remains.  You cannot claim to represent all of KDE SIG's
viewpoints on this matter unless you can point to such a request.   Red
Hat employees talking to each other in their offices cannot change
this.  I can't rely on water cooler discussions.  It should be public
for the sake of transparency in this matter.   I recommend KDE SIG push
for KDE integration patches upstream.  The current approach of trying to
force maintainers to accept patches simply does not work. 

Rahul

"Staying close to upstream"

[Kevin Kofler]

Rahul Sundaram wrote:
>  The current approach of trying to force maintainers to accept
> patches
>  simply does not work. 
The only reason it doesn't work is that our organizational structure is not 
built to make this work.

        Kevin Kofler

"Staying close to upstream"

[Chris Adams]

Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at&gt; said:
>  Rahul Sundaram wrote:
>  > The current approach of trying to force maintainers to accept patches
>  > simply does not work.
>  
>  The only reason it doesn't work is that our organizational structure is not 
>  built to make this work. 
But why should it be made to work?  Why should the KDE SIG be able to
force the kernel maintainers to take a patch?  What if that patch
conflicts with one another SIG wants - who "wins" (if you can call it
winning)?

SIGs should stick to their area of expertise.  The KDE SIG should work
on KDE packages and not assume they know what's best for the rest of the
distribution.
-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

"Staying close to upstream"

[Jon Ciesla]

  On 08/13/2010 12:58 PM, Kevin Kofler wrote:
>  Rahul Sundaram wrote:
> > The current approach of trying to force maintainers to accept patches
> > simply does not work.
>  The only reason it doesn't work is that our organizational structure is not
>  built to make this work.
>
>           Kevin Kofler
>  
I've yet to see a convincing argument that it should be so.  If a patch 
has technical merit and for some reason is suitable and beneficial for 
Fedora and not upstream, it should be reasonably easy to convince the 
maintainer of this.  If not, then FESCO.  But these are rare cases.  
Maintaining forks of a slew of packages is not why we're here, for the 
security and sustainability arguments already ably made.

-J

-- 
- in your fear, speak only peace
   in your fear, seek only love

-d. bowie

"Staying close to upstream"

[Jon Ciesla]

  On 08/13/2010 10:47 AM, Kevin Kofler wrote:
>  Rahul Sundaram wrote:
> > No.  No SIG's have any authority whatsoever over individual package
> > maintainers outside the packages the team maintains.  No one needs to
> > "comply" with your requirements.
>  That's exactly Fedora's organizational problem.
>
>  KDE SIG should have authority over anything KDE-related. Likewise, the Perl
>  SIG should have authority over anything Perl-related: if the Perl SIG
>  decides that a new Perl developer @ RH should have commit access to all
>  perl-* packages, it should be their decision to do so, it was really
>  counterproductive of FESCo to interfere with that!
>  
So if someone writes a KDE plugin for Application XYZ, it becomes a KDE 
package?  What?

My understanding of the SIG concept was that they were groups of people 
who were self-organizing around a particular theme to further that theme 
in Fedora, i.e. Games, Live Upgrade, KDE, etc.  I never got the 
impression that they were little fiefdoms with absolute power.

This is shades of the Federal-power vs. State's Rights debate in the 
U.S.  And for similar reasons, it seems.

-J
> > If you want a integrated experience,  don't work around
> upstream.  Push
> > your patches and get it merged there.
>  Good luck getting Mozilla to accept anything. Just like the kernel, they're
>  a very hard to work with upstream. If you don't know the right people, your
>  stuff just doesn't get in. :-(
>
>  Providing system integration is exactly what a distribution is for. You will
>  never achieve an integrated experience by just throwing together disparate
>  upstream tarballs.
>
>           Kevin Kofler
>  

-- 
- in your fear, speak only peace
   in your fear, seek only love

-d. bowie

"Staying close to upstream"

[Kevin Kofler]

Jon Ciesla wrote:
>  My understanding of the SIG concept was that they were groups of
> people
>  who were self-organizing around a particular theme to further that theme
>  in Fedora, i.e. Games, Live Upgrade, KDE, etc. 
Right, but that makes them naturally the best bodies to make decisions 
related to those respective themes.

        Kevin Kofler

"Staying close to upstream"

[Al Dunsmuir]

On Friday, August 13, 2010, 1:05:16 PM, Kevin wrote:
>  Jon Ciesla wrote:
> > My understanding of the SIG concept was that they were groups of people
> > who were self-organizing around a particular theme to further that theme
> > in Fedora, i.e. Games, Live Upgrade, KDE, etc. 
>  Right, but that makes them naturally the best bodies to make
> decisions
>  related to those respective themes.
>          Kevin Kofler 
It  seems to me that "best" depends on the point of view of the person
in question, and the outcome of a given decision.

The  FireFox  maintainer  might  well  be  viewed as best qualified to
determine  which  (if  any) distribution-specific patches they want to
support  over  the life of the package.   If you say no, then put that
maintainer in a "FireFox SIG" and repeat the question.

FESCo  might  well  be viewed as best to deal with policies related to
updates  across  _all_ Fedora SIGs and releases, since that one of the
tasks they were _ELECTED_ to perform.

Seems  you think best is one way in one case, and the other way in the
other  case.   It is this inconsistency that folks are trying to bring
to your attention.

Al

"Staying close to upstream"

[Jon Ciesla]

  On 08/13/2010 12:23 PM, Al Dunsmuir wrote:
>  On Friday, August 13, 2010, 1:05:16 PM, Kevin wrote:
> > Jon Ciesla wrote:
> >> My understanding of the SIG concept was that they were groups of people
> >> who were self-organizing around a particular theme to further that theme
> >> in Fedora, i.e. Games, Live Upgrade, KDE, etc.
> > Right, but that makes them naturally the best bodies to make decisions
> > related to those respective themes.
> >          Kevin Kofler
>  It  seems to me that "best" depends on the point of view of the person
>  in question, and the outcome of a given decision.
>
>  The  FireFox  maintainer  might  well  be  viewed as best qualified to
>  determine  which  (if  any) distribution-specific patches they want to
>  support  over  the life of the package.   If you say no, then put that
>  maintainer in a "FireFox SIG" and repeat the question.
>
>  FESCo  might  well  be viewed as best to deal with policies related to
>  updates  across  _all_ Fedora SIGs and releases, since that one of the
>  tasks they were _ELECTED_ to perform.
>
>  Seems  you think best is one way in one case, and the other way in the
>  other  case.   It is this inconsistency that folks are trying to bring
>  to your attention.
>
>  Al
>  
Hey, no fair stating the same point as I did, at the same time, but 
better, and without ranting.  That's cheating!

:)

-J

-- 
- in your fear, speak only peace
   in your fear, seek only love

-d. bowie

"Staying close to upstream"

[Al Dunsmuir]

On Friday, August 13, 2010, 1:26:34 PM, Jon wrote:
>  Hey, no fair stating the same point as I did, at the same time, but
>  better, and without ranting.  That's cheating!
>  :)
>  -J 
Sorry...  Must  be  feeling  mellow  -  it's Friday afternoon, and I'm
taking next week off.

I'll  make  sure I flick open the napalm dispenser next time. 8^)

Al

"Staying close to upstream"

[Kevin Kofler]

Al Dunsmuir wrote:
>  The  FireFox  maintainer  might  well  be  viewed as best qualified
> to
>  determine  which  (if  any) distribution-specific patches they want to
>  support  over  the life of the package.   If you say no, then put that
>  maintainer in a "FireFox SIG" and repeat the question. 
1. It doesn't make sense to have a SIG for a single package, a SIG needs to 
be for a set of packages. For example, the Perl SIG is not for just the perl 
package, but for most perl-* (and IMHO should be responsible for ALL perl-* 
packages).
2. Even packages primarily maintained by one SIG can be subject to decisions 
by other SIGs. E.g. I fully accept that the Games SIG should have its say 
over kdegames as long as they don't step into KDE territory (e.g. requiring 
us to change the BR kdelibs4-devel to a BR kdelibs-devel >= 6:4.0 would be 
unacceptable), that the SIGs for interpreted languages should have some 
control over their respective subpackages of kdebindings (and in fact we 
already try hard to follow their language-specific packaging guidelines 
there; if we don't, it's a bug) etc. My position is not "the KDE SIG should 
rule everything", it's "SIGs must be given authority over their subject 
matter, even if it means overruling individual maintainers or even, in the 
worst case, other SIGs, in order to allow for a consistent experience across 
the distribution".

>  FESCo  might  well  be viewed as best to deal with policies related
> to
>  updates  across  _all_ Fedora SIGs and releases, since that one of the
>  tasks they were _ELECTED_ to perform. 
FESCo is a too central body and the election process is broken in many ways 
(very low turnaround, too few and not sufficiently diverse candidates etc.).

>  Seems  you think best is one way in one case, and the other way in
> the
>  other  case.   It is this inconsistency that folks are trying to bring
>  to your attention. 
This perceived "inconsistency" just comes out of misunderstandings.

There is a middle ground between an authoritarian central authority and 
anarchic "I refuse to apply the patches you need because of XYZ" attitudes. 
SIGs are the right granularity for management.

Usually, and by default, the maintainer should be trusted. Where integration 
across packages is relevant (and that's exactly the case for those KDE 
_integration_ patches!), that's a matter for the SIGs (who should be allowed 
to overrule individual maintainers). Our central governing bodies are just 
bureaucratic overhead.

        Kevin Kofler

"Staying close to upstream"

[Jon Ciesla]

  On 08/13/2010 01:10 PM, Kevin Kofler wrote:
>  Al Dunsmuir wrote:
> > The  FireFox  maintainer  might  well  be  viewed as best qualified to
> > determine  which  (if  any) distribution-specific patches they want to
> > support  over  the life of the package.   If you say no, then put that
> > maintainer in a "FireFox SIG" and repeat the question.
>  1. It doesn't make sense to have a SIG for a single package, a SIG needs to
>  be for a set of packages. For example, the Perl SIG is not for just the perl
>  package, but for most perl-* (and IMHO should be responsible for ALL perl-*
>  packages).
>  2. Even packages primarily maintained by one SIG can be subject to decisions
>  by other SIGs. E.g. I fully accept that the Games SIG should have its say
>  over kdegames as long as they don't step into KDE territory (e.g. requiring
>  us to change the BR kdelibs4-devel to a BR kdelibs-devel>= 6:4.0 would be
>  unacceptable), that the SIGs for interpreted languages should have some
>  control over their respective subpackages of kdebindings (and in fact we
>  already try hard to follow their language-specific packaging guidelines
>  there; if we don't, it's a bug) etc. My position is not "the KDE SIG should
>  rule everything", it's "SIGs must be given authority over their subject
>  matter, even if it means overruling individual maintainers or even, in the
>  worst case, other SIGs, in order to allow for a consistent experience across
>  the distribution".
>
> > FESCo  might  well  be viewed as best to deal with policies related to
> > updates  across  _all_ Fedora SIGs and releases, since that one of the
> > tasks they were _ELECTED_ to perform.
>  FESCo is a too central body and the election process is broken in many ways
>  (very low turnaround, too few and not sufficiently diverse candidates etc.).
>  
So if I say, "Great, if that's what you want to do, run for FESCO", I

know what your answer is. :)
> > Seems  you think best is one way in one case, and the other way
> in the
> > other  case.   It is this inconsistency that folks are trying to bring
> > to your attention.
>  This perceived "inconsistency" just comes out of misunderstandings.
>
>  There is a middle ground between an authoritarian central authority and
>  anarchic "I refuse to apply the patches you need because of XYZ" attitudes.
>  SIGs are the right granularity for management.
>  
Ok, but it would seem that the community (as expressed via FESCO) would 
disagree.  If you can campaign and get enough people who agree elected, 
then there you go.  I'm not saying FESCO or it's election processes are 
infallible, but if you want the system changed to fit what you think it 
should be, then why can't the system be changed to what *I* think it 
should be?
>  Usually, and by default, the maintainer should be trusted. Where
> integration
>  across packages is relevant (and that's exactly the case for those KDE
>  _integration_ patches!), that's a matter for the SIGs (who should be allowed
>  to overrule individual maintainers). Our central governing bodies are just
>  bureaucratic overhead.
>  
Well, shoot, so is the police force and the court system, but you still 
have to abide by the speed limit until you can get your representatives 
to change it, either by petitioning them or by becoming them.   You 
either work within the system (in Fedora and in Democracy, via 
elections) or you replace the system (fork the distro, or start a 
revolution).  In replacing the system, however, it's good to have 
numerical superiority.  Democracies circumvent revolution by having 
elections and so whenever you have a large enough group to violently 
overthrow the government, they start winning elections and become the 
government.

-J
>           Kevin Kofler
>  

-- 
- in your fear, speak only peace
   in your fear, seek only love

-d. bowie

"Staying close to upstream"

[Jon Ciesla]

  On 08/13/2010 12:05 PM, Kevin Kofler wrote:
>  Jon Ciesla wrote:
> > My understanding of the SIG concept was that they were groups of people
> > who were self-organizing around a particular theme to further that theme
> > in Fedora, i.e. Games, Live Upgrade, KDE, etc.
>  Right, but that makes them naturally the best bodies to make decisions
>  related to those respective themes.
>
>           Kevin Kofler
>  
For most things, probably, but they're still subject to the packaging 
guidelines, review guidelines, and FESCO and FAB.  In some cases, SIGs 
have extra guidelines on top of the general guidelines, but they don't 
exempt themselves from the general guidelines.  If someone from a SIG of 
which I am not a member modifies my package in a way contrary to my 
wishes, am I supposed to just say "Oh, gosh, well, I mean, the SIG is 
the law, so I have to suck it up."?  No.  I engage the person in 
question, and in the event of an unresolvable dispute, I go to FESCO.  
The person may point to their SIGs enhanced guidelines, but unless they 
get FPC to add them to the general guidelines, then they're optional.  
My point in this example is not to imply that the various guidelines are 
the law, but to show that unless I missed a rather major announcement, 
FESCO has authority superior to that of any SIG.  Nor is the point of my 
example to denigrate the expertise gathered in many SIGs.  I get that, 
there are tons.  But a group of expert lawyers sitting around the pub 
are not the same as, say, the Supreme Court, however expert they may be.

</rant>

-J

-- 
- in your fear, speak only peace
   in your fear, seek only love

-d. bowie

"Staying close to upstream"

[Nicolas Mailhot]

Le Ven 13 août 2010 19:24, Jon Ciesla a écrit :

>  The person may point to their SIGs enhanced guidelines, but unless
> they
>  get FPC to add them to the general guidelines, then they're optional. 
Which is a lot of work, and not something everyone will apply even after FPC
blessing, but it's the only way to go forward.

-- 
Nicolas Mailhot

"Staying close to upstream"

[Dave Jones]

On Fri, Aug 13, 2010 at 05:47:37PM +0200, Kevin Kofler wrote:
 
>  Good luck getting Mozilla to accept anything. Just like the kernel,
> they're 
>  a very hard to work with upstream. If you don't know the right people, your 
>  stuff just doesn't get in. :-( 
 
Which is odd, because the number of changesets per release seems to be increasing.
As does the number of new committers.

It's almost like you're talking complete rubbish.

	Dave

"Staying close to upstream"

[Kevin Kofler]

Dave Jones wrote:

>  On Fri, Aug 13, 2010 at 05:47:37PM +0200, Kevin Kofler wrote:
>   
>   > Good luck getting Mozilla to accept anything. Just like the kernel,
>   > they're a very hard to work with upstream. If you don't know the right
>   > people, your stuff just doesn't get in. :-(
>   
>  Which is odd, because the number of changesets per release seems to be
>  increasing. As does the number of new committers.
>
>  It's almost like you're talking complete rubbish. 
Or maybe the situation is slowly improving… :-)

        Kevin Kofler

"Staying close to upstream"

[Chris Tyler]

On Fri, 2010-08-13 at 16:51 +0200, Kevin Kofler wrote:
>  * This policy of sticking religiously to upstream means we are not
> shipping 
>  KDE integration for Firefox, despite patches from openSUSE existing. This 
>  makes Firefox suck under KDE. Our Firefox maintainers refuse to do anything 
>  about it. 
Kevin, it seems to me that open source is about working in community,
and you want to short-circuit that again.

You could work in community by:
- respecting our Firefox maintainers' policies, and
- respecting upstream by shepherding these patches through their review
process

If you (or whoever is interested) can't get those patches through the
upstream review process for technical reasons, then perhaps they're ugly
patches. If you can't get them through because of lack of
time/energy/motivation, then the future maintenance of those patches is
in question. Either way, it strengthens our Firefox maintainers'
position that those patches shouldn't be accepted.

It's easy to complain that people aren't bending the rules to your
liking, and harder to actually work with them and get things done in a
quality, sustainable way.

-Chris

"Staying close to upstream"

[Kevin Kofler]

Chris Tyler wrote:
>  If you (or whoever is interested) can't get those patches through
> the
>  upstream review process for technical reasons, then perhaps they're ugly
>  patches. If you can't get them through because of lack of
>  time/energy/motivation, then the future maintenance of those patches is
>  in question. Either way, it strengthens our Firefox maintainers'
>  position that those patches shouldn't be accepted. 
You forget the sociopolitical aspect: in many upstreams (and AFAICS Mozilla 
is one of those), you can only get your stuff merged if you know the right 
people. :-(

        Kevin Kofler

"Staying close to upstream"

[Andy Gospodarek]

On Fri, Aug 13, 2010 at 05:49:31PM +0200, Kevin Kofler wrote:
>  
>  You forget the sociopolitical aspect: in many upstreams (and AFAICS Mozilla 
>  is one of those), you can only get your poorly-written code merged if you know the right
>
>  people. :-(
>   
FTFY

http://people.redhat.com/agospoda/pics/hackbar.jpg

"Staying close to upstream"

[Chris Tyler]

On Fri, 2010-08-13 at 17:49 +0200, Kevin Kofler wrote:
>  Chris Tyler wrote:
>  > If you (or whoever is interested) can't get those patches through the
>  > upstream review process for technical reasons, then perhaps they're ugly
>  > patches. If you can't get them through because of lack of
>  > time/energy/motivation, then the future maintenance of those patches is
>  > in question. Either way, it strengthens our Firefox maintainers'
>  > position that those patches shouldn't be accepted.
>  
>  You forget the sociopolitical aspect: in many upstreams (and AFAICS Mozilla 
>  is one of those), you can only get your stuff merged if you know the right 
>  people. :-( 
Thanks for reinforcing my point -- you have to work with the community.
Yes, you'll make some relationships along the way.

-Chris

"Staying close to upstream"

[Kevin Kofler]

Chris Tyler wrote:
>  Thanks for reinforcing my point -- you have to work with the
> community.
>  Yes, you'll make some relationships along the way. 
Except it works the other way round: you only have a chance to get into the 
community (well, SOME upstream communities; thankfully, they're not all like 
that!) if you already have the right relationships.

        Kevin Kofler

"Staying close to upstream"

[Rahul Sundaram]

 On 08/13/2010 09:44 PM, Kevin Kofler wrote:
>  Chris Tyler wrote:
> > Thanks for reinforcing my point -- you have to work with the community.
> > Yes, you'll make some relationships along the way.
>  Except it works the other way round: you only have a chance to get into the 
>  community (well, SOME upstream communities; thankfully, they're not all like 
>  that!) if you already have the right relationships. 
New people come into Mozilla and get their patches merged all the time. 
It certainly does not hurt to know people and talk to them in a
cooperative way in any community.  Your approach has much less chance of
succeeding in either case.

Rahul

"Staying close to upstream"

[Matthew Garrett]

On Fri, Aug 13, 2010 at 04:51:40PM +0200, Kevin Kofler wrote:

>  * This policy of sticking religiously to upstream means we are not
> shipping 
>  KDE integration for Firefox, despite patches from openSUSE existing. This 
>  makes Firefox suck under KDE. Our Firefox maintainers refuse to do anything 
>  about it. 
If it's not good enough for upstream, why is it good enough for us? 
Who's committing to maintaining these patches? What's their turnaround 
speed if a security issue forces an update tht breaks them?

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

"Staying close to upstream"

[Garrett Holmstrom]

Kevin Kofler wrote:
>  * This policy of sticking religiously to upstream means we are not
> shipping 
>  KDE integration for Firefox, despite patches from openSUSE existing. This 
>  makes Firefox suck under KDE. Our Firefox maintainers refuse to do anything 
>  about it. 
What reason does upstream give for not accepting said patches?

"Staying close to upstream"

[Matt McCutchen]

On Thu, 2010-08-12 at 23:29 -0700, Jesse Keating wrote:
>  On 08/12/2010 10:59 PM, Matt McCutchen wrote:
>  >  That's why I'm so frustrated that Fedora seems to be committed
>  > to keeping the Mozilla trademarks, which moot any discussion of whether
>  > to deviate for those packages.  But this is only my opinion.  Fedora is
>  > welcome to set its own course, and I am welcome to fork (in theory at
>  > least). 
>  
>  You're making an assumption here that it's the trademarks that prevent
>  any deviation from upstream, when in fact the maintainer has stated many
>  times that regardless of trademarks, he would not deviate from upstream
>  given the sensitivity of a software suite that has to connect to the
>  wild wild web.  The maintenance burden of upstream deviation is greater
>  than the maintainer would like to undertake, as is the risk of security
>  issues and stability. 
I am aware of that.  But FESCo has the authority to override the
maintainer, and in their recent discussion of the SELinux patch, they
decided not to move forward on the basis of the trademarks:

https://meetbot.fedoraproject.org/fedora-meeting/2010-08-03/fesco.2010-08...

Maybe the maintenance burden alone would also be enough to block further
consideration of the patch, but there is no way to tell that from their
discussion.

-- 
Matt

"Staying close to upstream"

[Matthew Garrett]

On Sat, Aug 14, 2010 at 08:25:46PM -0700, Matt McCutchen wrote:

>  I am aware of that.  But FESCo has the authority to override the
>  maintainer, and in their recent discussion of the SELinux patch, they
>  decided not to move forward on the basis of the trademarks:
>  
>
> https://meetbot.fedoraproject.org/fedora-meeting/2010-08-03/fesco.2010-08...
>  
>  Maybe the maintenance burden alone would also be enough to block further
>  consideration of the patch, but there is no way to tell that from their
>  discussion. 
We have the authority to do that, and the decision you're referring to 
effectively *did* override the maintainer by saying that the selinux 
policy change should be reverted. If a package is generally 
well-maintained and then broken by a change introduced by another 
maintainer, there has to be a very strong argument to do anything other 
than revert the change that broke things in the first place.

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

"Staying close to upstream"

[Kevin Kofler]

Matthew Garrett wrote:
>  We have the authority to do that, and the decision you're
> referring to
>  effectively *did* override the maintainer by saying that the selinux
>  policy change should be reverted. If a package is generally
>  well-maintained and then broken by a change introduced by another
>  maintainer, there has to be a very strong argument to do anything other
>  than revert the change that broke things in the first place. 
But the end effect is, we're allowing a web browser to disable memory 
protection, exposing all users to a severe security risk from merely 
browsing web sites. IMHO, the performance improvements in JavaScript aren't 
worth that risk. JavaScript JITs should be banned.

        Kevin Kofler

Javascript JIT in web browsers

[Matt McCutchen]

On Sun, 2010-08-15 at 18:26 +0200, Kevin Kofler wrote:
>  But the end effect is, we're allowing a web browser to disable
> memory 
>  protection, exposing all users to a severe security risk from merely 
>  browsing web sites. IMHO, the performance improvements in JavaScript aren't 
>  worth that risk. 
An alternative is to run the JavaScript in a less-privileged process,
like I believe Chromium does.

-- 
Matt

Javascript JIT in web browsers

[drago01]

On Sun, Aug 15, 2010 at 9:45 PM, Matt McCutchen <matt(a)mattmccutchen.net&gt; wrote:
>  On Sun, 2010-08-15 at 18:26 +0200, Kevin Kofler wrote:
> > But the end effect is, we're allowing a web browser to disable memory
> > protection, exposing all users to a severe security risk from merely
> > browsing web sites. IMHO, the performance improvements in JavaScript aren't
> > worth that risk. 
The times where javascript is only used for some fancy effects are
long over ... welcome to 2010 ;)

>  An alternative is to run the JavaScript in a less-privileged
> process,
>  like I believe Chromium does. 
The "problem" is fixable there is a patch that is being discussed
upstream to fix the issue and allow selinux memory protection it is
just not merged yet.

Using a JIT is not a security risk by itself.

Javascript JIT in web browsers

[Matt McCutchen]

On Sun, 2010-08-15 at 22:41 +0200, drago01 wrote:
>  On Sun, Aug 15, 2010 at 9:45 PM, Matt McCutchen
> <matt(a)mattmccutchen.net&gt; wrote:
>  > On Sun, 2010-08-15 at 18:26 +0200, Kevin Kofler wrote:
>  >> But the end effect is, we're allowing a web browser to disable memory
>  >> protection, exposing all users to a severe security risk from merely
>  >> browsing web sites. IMHO, the performance improvements in JavaScript aren't
>  >> worth that risk. 
>  > An alternative is to run the JavaScript in a less-privileged
> process,
>  > like I believe Chromium does.
>  
>  The "problem" is fixable there is a patch that is being discussed
>  upstream to fix the issue and allow selinux memory protection it is
>  just not merged yet. 
I'm not holding my breath.

The patch would avoid one particularly risky behavior, but the browser
still has a very large attack surface.  OS-level sandboxing is a good
idea in any case.

-- 
Matt

Javascript JIT in web browsers

[drago01]

On Sun, Aug 15, 2010 at 10:49 PM, Matt McCutchen <matt(a)mattmccutchen.net&gt; wrote:
>  On Sun, 2010-08-15 at 22:41 +0200, drago01 wrote:
> > On Sun, Aug 15, 2010 at 9:45 PM, Matt McCutchen <matt(a)mattmccutchen.net&gt;
> wrote:
> > > On Sun, 2010-08-15 at 18:26 +0200, Kevin Kofler wrote:
> > >> But the end effect is, we're allowing a web browser to disable memory
> > >> protection, exposing all users to a severe security risk from merely
> > >> browsing web sites. IMHO, the performance improvements in JavaScript
> aren't
> > >> worth that risk.
>
> > > An alternative is to run the JavaScript in a less-privileged process,
> > > like I believe Chromium does.
> >
> > The "problem" is fixable there is a patch that is being discussed
> > upstream to fix the issue and allow selinux memory protection it is
> > just not merged yet.
>
>  I'm not holding my breath.
>
>  The patch would avoid one particularly risky behavior, but the browser
>  still has a very large attack surface.  OS-level sandboxing is a good
>  idea in any case. 
True, but this is not specific to javascript (jit) but the browser
itself is the number one attack vector on desktop systems, so yeah
sandboxing should indeed help.

But calls like "javascript JITs should be banned" are just nonsense.

Javascript JIT in web browsers

[Kevin Kofler]

drago01 wrote:
>  The times where javascript is only used for some fancy effects are
>  long over ... welcome to 2010 ;) 
Some web sites are indeed abusing JavaScript. Why should we promote this 
behavior? It is a vehicle for proprietary software, where people often 
aren't even aware they're using non-Free code, or just ignore the issue.
See also http://www.gnu.org/philosophy/javascript-trap.html . A web site is 
not and should not be an application, an application is not and should not 
be a web site.

>  The "problem" is fixable there is a patch that is being
> discussed
>  upstream to fix the issue and allow selinux memory protection it is
>  just not merged yet.
>  
>  Using a JIT is not a security risk by itself. 
Workarounds which make SELinux happy are still not as secure as sticking to 
a pure bytecode interpreter. Exploit code can still write to the memory to 
be executed, with ANY JIT, as this is how a JIT works. It's just that the 
writing has to happen through a different address space window as the 
execution, making the JIT harder, but not impossible, to exploit.

So IMHO the right fix is to disable the JIT altogether.

But the proposed patch would still be better than the crappy solution 
implemented now just to "stick to upstream" (having SELinux ignore the 
problem).

        Kevin Kofler

Javascript JIT in web browsers

[Matt McCutchen]

On Mon, 2010-08-16 at 01:15 +0200, Kevin Kofler wrote:
>  Some web sites are indeed abusing JavaScript. 
>  A web site is 
>  not and should not be an application, an application is not and should not 
>  be a web site. 
Just because you said so?  Web applications bring enormous practical
benefits to their users and administrators.

>  It is a vehicle for proprietary software, where people often 
>  aren't even aware they're using non-Free code, or just ignore the issue.
>  See also http://www.gnu.org/philosophy/javascript-trap.html . 
If you use a non-free web site, you have already lost the freedom to
read, distribute, and modify the code you are relying on
(http://www.gnu.org/philosophy/who-does-that-server-really-serve.html).
I fail to see how running the site's non-free JavaScript for the sole
purpose of interacting with that site makes the situation any worse.

-- 
Matt

Javascript JIT in web browsers

[Kevin Kofler]

Matt McCutchen wrote:
>  If you use a non-free web site, you have already lost the freedom to
>  read, distribute, and modify the code you are relying on
>  (http://www.gnu.org/philosophy/who-does-that-server-really-serve.html).
>  I fail to see how running the site's non-free JavaScript for the sole
>  purpose of interacting with that site makes the situation any worse. 
The JavaScript is indeed only part of the problem, the server-side code is 
the other half. But both are non-Free, and therefore both and thus the web 
app as a whole should not be used.

        Kevin Kofler

Javascript JIT in web browsers

[Bruno Wolff III]

On Sun, Aug 15, 2010 at 16:44:29 -0700,
  Matt McCutchen <matt(a)mattmccutchen.net&gt; wrote:
>  On Mon, 2010-08-16 at 01:15 +0200, Kevin Kofler wrote:
>  > Some web sites are indeed abusing JavaScript.
>  
>  > A web site is 
>  > not and should not be an application, an application is not and should not 
>  > be a web site.
>  
>  Just because you said so?  Web applications bring enormous practical
>  benefits to their users and administrators. 
My view is that they show only be used for applications when that application
is going to be used by someone with a trust relationship to the application
provider. For example when using Peoplesoft at work it makes sense, since
I trust my employer to not be trying to hack my work desktop.

I think using javascript for pages meant to be used by the general public
is a bad idea. It encourages people who don't know better to enable
javascript for general browsing, which signifcantly increases the risks
to them for having credentials stolen or their desktop hacked.

Instead things should be done server side, with style sheets or xforms.

Javascript JIT in web browsers

[Gregory Maxwell]

On Sun, Aug 15, 2010 at 8:31 PM, Bruno Wolff III <bruno(a)wolff.to&gt; wrote:
>  On Sun, Aug 15, 2010 at 16:44:29 -0700,
>   Matt McCutchen <matt(a)mattmccutchen.net&gt; wrote:
> > On Mon, 2010-08-16 at 01:15 +0200, Kevin Kofler wrote:
> > > Some web sites are indeed abusing JavaScript.
> >
> > > A web site is
> > > not and should not be an application, an application is not and should not
> > > be a web site.
> >
> > Just because you said so?  Web applications bring enormous practical
> > benefits to their users and administrators.
>
>  My view is that they show only be used for applications when that application
>  is going to be used by someone with a trust relationship to the application
>  provider. For example when using Peoplesoft at work it makes sense, since
>  I trust my employer to not be trying to hack my work desktop.
>
>  I think using javascript for pages meant to be used by the general public
>  is a bad idea. It encourages people who don't know better to enable
>  javascript for general browsing, which signifcantly increases the risks
>  to them for having credentials stolen or their desktop hacked.
>
>  Instead things should be done server side, with style sheets or xforms. 
I don't think I'm going out on a limb in saying that limiting or
handicapping javascript in the stock install is a non-starter.

There are websites which make some use of javascript which are free
software through and through. Even if your motivation is purely
promoting free tools even breaking one of these would not be a good
deal.

As I understand it one of the Mozilla approved ways for integrators to
change the default Firefox experience is through add-ons.  There are a
number of firefox addons which increase safety and privacy— tools like
noscript, adblock, https-everywhere. (I was about to include ghostery
in this list, but I see that it's not free software :( ).

Including some of these addons in the default install may improve the
security posture of fedora users and increase awareness of web-safety
without wading into non-starter proposals like removing javascript.

Moreover, by including these by default fedora would reduce the amount
user conditioning for installing addons manually from assorted sources
as firefox add-ons can be pretty horrific from a security and software
freedom perspective as they can and do ship arbitrary binary code.

Javascript JIT in web browsers

[Adam Williamson]

On Sun, 2010-08-15 at 19:31 -0500, Bruno Wolff III wrote:

>  I think using javascript for pages meant to be used by the general
> public
>  is a bad idea. It encourages people who don't know better to enable
>  javascript for general browsing, which signifcantly increases the risks
>  to them for having credentials stolen or their desktop hacked. 
Meanwhile, back in the real world, it is effectively impossible to use
all sorts of useful websites without Javascript enabled. Even for
freedom-loving geeks. I run noscript by default, but I usually have to
enable scripts for at least the actual host I'm visiting to make most
sites in any way usable. Especially interactive ones (small things like
filling out government forms, buying plane or train or any other kinds
of tickets, etc).

Shipping a Firefox with no ability to use Javascript would be more or
less equal to not shipping it, frankly. No-one would use the thing.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Javascript JIT in web browsers

[Bruno Wolff III]

On Mon, Aug 16, 2010 at 15:48:14 -0700,
  Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  
>  Meanwhile, back in the real world, it is effectively impossible to use
>  all sorts of useful websites without Javascript enabled. Even for 
Then don't use them. If sites don't get used they may stop requiring
people to significantly reduce the security of their systems to use them.
It doesn't even have to be all of them, just the ones that aren't that
important.

>  Shipping a Firefox with no ability to use Javascript would be more
> or
>  less equal to not shipping it, frankly. No-one would use the thing. 
While I think Firefox could do several things to increase it's real
security instead of it's apparent security, I was actually complaining
about the server side. Sites that use javascript encourage people to
leave it turned on and even optional javascript is bad. Other ways of
doing things (xforms, css, server computation) should be used instead.
(Things that are really applications used with a special trust relationship
and not by the general public are different.)

Javascript JIT in web browsers

[Jon Masters]

On Mon, 2010-08-16 at 18:35 -0500, Bruno Wolff III wrote:
>  On Mon, Aug 16, 2010 at 15:48:14 -0700,
>    Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  > 
>  > Meanwhile, back in the real world, it is effectively impossible to use
>  > all sorts of useful websites without Javascript enabled. Even for
>  
>  Then don't use them. If sites don't get used they may stop requiring
>  people to significantly reduce the security of their systems to use them. 
I think most of those websites we all use that rely upon Javascript
wouldn't even notice a drop in numbers. Given the overall number of
computer users out there, and the (much smaller) relative number of
Linux users, and then the (even smaller) relative number of Fedora users
in the game, all it would do is cause pain for folks using Fedora and
achieve nothing beyond that whatsoever. It's not like Apple and Flash,
it's like "oh man, look that Linux thing *really* sucks now, I can't
even use Facebook! I could live with no MP3s, but not Facebook! Next!"

Jon.

Javascript JIT in web browsers

[Manuel Wolfshant]

On 08/17/2010 02:35 AM, Bruno Wolff III wrote:
>  On Mon, Aug 16, 2010 at 15:48:14 -0700,
>    Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>    
> > Meanwhile, back in the real world, it is effectively impossible to use
> > all sorts of useful websites without Javascript enabled. Even for
> >     
>
>  Then don't use them. If sites don't get used they may stop requiring
>  people to significantly reduce the security of their systems to use them.
>  It doesn't even have to be all of them, just the ones that aren't that
>  important.
>     
    Do you REALLY believe that in a world where 90% of the desktops are 
Windows, where 2 thirds of the browser market is shared by IE and safari 
and where making governments to share public documents in a public 
format rather than .doc/.xls/etc, web site managers would care if you 
stop visiting their site ( which you probably NEED to access otherwise 
you would not be trying to visit it in the first place)  ?


> > Shipping a Firefox with no ability to use Javascript would be
> more or
> > less equal to not shipping it, frankly. No-one would use the thing.
> >     
>
>  While I think Firefox could do several things to increase it's real
>  security instead of it's apparent security, I was actually complaining
>  about the server side. Sites that use javascript encourage people to
>  leave it turned on and even optional javascript is bad.  
correct. too bad most
developers do not care at all about anything but 
the easiest way to fix the punctual problem that was given to them and 
simply ignore the larger picture.

>  Other ways of
>  doing things (xforms, css, server computation) should be used instead. 
absolutely
correct. alternate ways exist, but how many companies / web 
developers care about doing it "the right way" ?

wolfy "I absolutely hate sites created in flash"

Javascript JIT in web browsers

[Orcan Ogetbil]

On Mon, Aug 16, 2010 at 8:01 PM, Manuel Wolfshant wrote:
>     Do you REALLY believe that in a world where 90% of the desktops
> are
>  Windows, where 2 thirds of the browser market is shared by IE and safari 
Where did you got these statistics from? Any references? w3schools [1]
say it is otherwise, i.e. IE+Safari = 1/3

Thanks,
Orcan

[1] http://www.w3schools.com/browsers/browsers_stats.asp

Javascript JIT in web browsers

[Manuel Wolfshant]

On 08/17/2010 03:15 AM, Orcan Ogetbil wrote:
>  On Mon, Aug 16, 2010 at 8:01 PM, Manuel Wolfshant wrote:
>    
> >    Do you REALLY believe that in a world where 90% of the desktops are
> > Windows, where 2 thirds of the browser market is shared by IE and safari
> >     
>
>  Where did you got these statistics from? Any references? 
http://www.netmarketshare.com/browser-market-share.aspx?qprid=1



>  w3schools [1] say it is otherwise, i.e. IE+Safari = 1/3
>
>  Thanks,
>  Orcan
>
>  [1] http://www.w3schools.com/browsers/browsers_stats.asp 
I'd be more than happy to be wrong. But based on what I see around me ( 
roughly 10-15 new [*] systems / week not counting whatever I install ) 
firefox is nowhere near 40%.


[*] customers that I visit or I connect to

Javascript JIT in web browsers

[Gregory Maxwell]

On Mon, Aug 16, 2010 at 8:01 PM, Manuel Wolfshant
<wolfy(a)nobugconsulting.ro&gt; wrote:
>     Do you REALLY believe that in a world where 90% of the desktops
> are
>  Windows, where 2 thirds of the browser market is shared by IE and safari
>  and where making governments to share public documents in a public
>  format rather than .doc/.xls/etc, web site managers would care if you
>  stop visiting their site ( which you probably NEED to access otherwise
>  you would not be trying to visit it in the first place)  ? 
[snip]

I don't agree with the suggestions here to restrict it, but I think
the implications here sucks.

Is it better to have a world where 90% is Fedora but every user has
less freedom over their data and applications than they would in
windows because they are only using Fedora as a really excellent
remote terminal to web applications which give them no control over
their data or the programs that they use?

Disallowing compatibility with the world doesn't fix it but neither
does ignoring the significant problems posed by non-free web
applications and the enormous influence they will have over the fedora
experience in the coming decades.

Or in other words— for those who care about freedom making Fedora a
first class platform for web apps is mostly just rearranging the deck
chairs on the titanic— we're screwed either way.

Javascript JIT in web browsers

[Manuel Wolfshant]

On 08/17/2010 03:22 AM, Gregory Maxwell wrote:
>  On Mon, Aug 16, 2010 at 8:01 PM, Manuel Wolfshant
>  <wolfy(a)nobugconsulting.ro&gt; wrote:
>    
> >    Do you REALLY believe that in a world where 90% of the desktops are
> > Windows, where 2 thirds of the browser market is shared by IE and safari
> > and where making governments to share public documents in a public
> > format rather than .doc/.xls/etc, web site managers would care if you
> > stop visiting their site ( which you probably NEED to access otherwise
> > you would not be trying to visit it in the first place)  ?
> >     
>  [snip]
>
>  I don't agree with the suggestions here to restrict it, but I think
>  the implications here sucks.
>
>  Is it better to have a world where 90% is Fedora but every user has
>  less freedom over their data and applications than they would in
>  windows because they are only using Fedora as a really excellent
>  remote terminal to web applications which give them no control over
>  their data or the programs that they use?
>
>  Disallowing compatibility with the world doesn't fix it but neither
>  does ignoring the significant problems posed by non-free web
>  applications and the enormous influence they will have over the fedora
>  experience in the coming decades.
>
>  Or in other words— for those who care about freedom making Fedora a
>  first class platform for web apps is mostly just rearranging the deck
>  chairs on the titanic— we're screwed either way.
>     
To cut it short: I love freedom and this is why I use linux for 16 years 
now (despite starting my professional career as a DOS / windows 
programmer). But I do not write the rules and I prefer to have time to 
see a movie or have a long weekend rather than chasing video / audio / 
browser plugins. When I can, I advise against using proprietary / 
non-free formats. But that is not always a choice and experience has 
shown me that commercial companies most usually that not don't give a 
**** on my opinion when I mail them to tell them " your site looks like 
c**p in anything else but IE ".

As a sidenote, on my home WS ( centos5 /x86_64) I still have to use 
adobe's flash plugin v9. Since upgrading to most recent firefox version 
as provided by the distro, with v10 all I get is a black rectangle 
instead of the clip. While on my work WS, firefox from RHEL6b2 /x86_64 
after some period of usage (counted in dozens of minutes at most) must 
be restarted or it simply does not react to any JS inside the pages.

Javascript JIT in web browsers

[J. Randall Owens]

On 08/16/2010 16:35 -0700, Bruno Wolff III wrote:
>  On Mon, Aug 16, 2010 at 15:48:14 -0700,
>    Adam Williamson <awilliam(a)redhat.com&gt; wrote:
> >
> > Meanwhile, back in the real world, it is effectively impossible to use
> > all sorts of useful websites without Javascript enabled. Even for
>  
>  Then don't use them. If sites don't get used they may stop requiring
>  people to significantly reduce the security of their systems to use them.
>  It doesn't even have to be all of them, just the ones that aren't that
>  important. 
Maybe you should file a bug against Javascript in Firefox?  Oh, wait,
bugzilla uses Javascript, doesn't it?  Scratch that, no bugzilla for the
purists.

Disclaimer: I don't actually know how gracefully bugzilla handles itself
without Javascript enabled; I would hope it would take it well.  But it
certainly does use it quite a bit when it is enabled.

-- 
J. Randall Owens | http://www.ghiapet.net

Javascript JIT in web browsers

[Bruno Wolff III]

On Mon, Aug 16, 2010 at 17:08:27 -0700,
  "J. Randall Owens" <jrowens.fedora(a)ghiapet.net&gt; wrote:
>  
>  Maybe you should file a bug against Javascript in Firefox?  Oh, wait,
>  bugzilla uses Javascript, doesn't it?  Scratch that, no bugzilla for the
>  purists. 
I don't use it with javascript enabled. Unfortunately the javascript code
still slows downloading down.

The only Fedora Project web page that I use with javscript enabled is
the package database. It doesn't seem to work (when asking for access)
if you don't have it enabled.

I have filed bugs against apps where not having javascrip enabled broke
things and they have been fixed.

Javascript JIT in web browsers

[Adam Williamson]

On Mon, 2010-08-16 at 18:35 -0500, Bruno Wolff III wrote:

>  While I think Firefox could do several things to increase it's
> real
>  security instead of it's apparent security, I was actually complaining
>  about the server side. Sites that use javascript encourage people to 
Then why were you doing it on fedora-devel? We don't run the websites.
We don't control whether they use JS. As long as people are going to
want to use the things, we're going to have to deal with them.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Javascript JIT in web browsers

[Kevin Kofler]

Adam Williamson wrote:
>  Shipping a Firefox with no ability to use Javascript would be more
> or
>  less equal to not shipping it, frankly. No-one would use the thing. 
What I suggest is just to use the same old JavaScript interpreter we have 
used before the JIT was introduced, which they undoubtedly keep working for 
those platforms which don't have JIT support available at all. That doesn't 
mean no JavaScript support, just a performance impact which is probably 
negligible on most sites and much better security.

FWIW, another JavaScript JIT, the same issue (QtWebKit):
https://bugzilla.redhat.com/show_bug.cgi?id=604003
(and there too I've been arguing to disable the JIT, as we've actually done 
in all stable Fedora releases so far).

And webkitgtk has the same JIT as QtWebKit and it is also disabled in 
Fedora.

        Kevin Kofler

Javascript JIT in web browsers

[Matt McCutchen]

On Tue, 2010-08-17 at 21:31 +0200, Kevin Kofler wrote: 
>  Adam Williamson wrote:
>  > Shipping a Firefox with no ability to use Javascript would be more or
>  > less equal to not shipping it, frankly. No-one would use the thing.
>  
>  What I suggest is just to use the same old JavaScript interpreter we have 
>  used before the JIT was introduced, which they undoubtedly keep working for 
>  those platforms which don't have JIT support available at all. That doesn't 
>  mean no JavaScript support, just a performance impact which is probably 
>  negligible on most sites 
Gmail makes very heavy use of JavaScript, so I bet the difference there
is significant.  There may be Free Software web applications for which
the same is true, I'm just not familiar with them.  I know you won't
believe me; someone who knows how will have to perform a test.

>  and much better security. 
You haven't convinced me of this.  Are vulnerabilities that let one
inject enough code to exploit the JIT (particularly after the SELinux
patch) really that easy to find?  But others have a better understanding
of attacks in machine code than I do.

-- 
Matt

Javascript JIT in web browsers

[Ilyes Gouta]

Hi,

Since JavaScript has a client-side execution model and since the all
the JS scripts are downloaded in plain text format (even if sometimes
obfuscated) along with the html code, then can't we assume that JS
code is available in source format and hence can't be classified as
closed source programs?

>  What I suggest is just to use the same old JavaScript interpreter we
> have
>  used before the JIT was introduced, which they undoubtedly keep working for 
So much effort and expertise were spent to bring JS execution to
higher performance levels using VMs like V8, Tamarin, Squirrelfish,
and we're speaking here about a 6x to 8x speed up ratio compared to an
interpreted execution. JIT VMs are important for the end-user
experience, being in the context of the web or webapp and are a corner
stone for the next-gen Web where most applications are going to be
written in HTML5 and JavaScript and almost near-native execution
performance is going to be desired (think <canvas> and WebGL for
in-browser standard 2D and 3D rendering), and In my opinion Fedora
should pave the way for such kind of bleeding edge tech. Security
comes from an implementation which is specification compliant and
projects such as Firefox, WebKit (and any other browser which claims
to be standard compliant) that won't save any effort to get to that
point. Techniques such as sand-boxing would also help a lot mitigating
malware and other security issues and constitutes a complementary
design approach for an overall improved browser security model.

-Ilyes Gouta

On Thu, Aug 19, 2010 at 5:10 AM, Matt McCutchen <matt(a)mattmccutchen.net&gt; wrote:
>  On Tue, 2010-08-17 at 21:31 +0200, Kevin Kofler wrote:
> > Adam Williamson wrote:
> > > Shipping a Firefox with no ability to use Javascript would be more or
> > > less equal to not shipping it, frankly. No-one would use the thing.
> >
> > What I suggest is just to use the same old JavaScript interpreter we have
> > used before the JIT was introduced, which they undoubtedly keep working for
> > those platforms which don't have JIT support available at all. That doesn't
> > mean no JavaScript support, just a performance impact which is probably
> > negligible on most sites
>
>  Gmail makes very heavy use of JavaScript, so I bet the difference there
>  is significant.  There may be Free Software web applications for which
>  the same is true, I'm just not familiar with them.  I know you won't
>  believe me; someone who knows how will have to perform a test.
>
> > and much better security.
>
>  You haven't convinced me of this.  Are vulnerabilities that let one
>  inject enough code to exploit the JIT (particularly after the SELinux
>  patch) really that easy to find?  But others have a better understanding
>  of attacks in machine code than I do.
>
>  --
>  Matt
>
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>

Javascript JIT in web browsers

[Kevin Kofler]

Ilyes Gouta wrote:
>  Since JavaScript has a client-side execution model and since the all
>  the JS scripts are downloaded in plain text format (even if sometimes
>  obfuscated) along with the html code, then can't we assume that JS
>  code is available in source format and hence can't be classified as
>  closed source programs? 
Free Software is not just about availability of source code. (That's exactly 
why the term "Open Source" is misleading!) It's no use having the source 
code if you aren't allowed to legally do anything with it.

In addition:
* Obfuscated code is not source code.
* Those web apps also have lots of server-side code which is entirely 
secret.

>  the next-gen Web where most applications are going to be written in
> HTML5
>  and JavaScript and almost near-native execution performance is going to be
>  desired 
I want none of that useless crap, thank you very much! Applications should 
be written as applications, delivered through our package repository, in a 
compiled language. Web sites should just be web sites and have as little 
code as possible (ideally none). The web is a medium for information, not 
code.

If you really want a platform for remote services (which I'm not convinced I 
want, I'd rather control the software I'm running), you need to help design 
a real cloud platform from ground up. The way the web is being abused as a 
software platform is really appalling. It's really not designed for that, 
and we have tons of ugly workarounds such as session cookies, AJAX etc. 
JavaScript JITs are a part of those broken workarounds.

>  Security comes from an implementation which is specification
> compliant 
Nonsense. Standards-compliance is completely orthogonal to security.

Security against buffer overflow exploits comes from a security-conscious 
design. Converting untrusted code into native machine code and executing 
that is NOT a security-conscious design, it just begs to get exploited.

>  Techniques such as sand-boxing would also help a lot mitigating
> malware
>  and other security issues 
But an interpreter can enforce the sandboxing in a much more robust and 
failsafe way than a JIT.

        Kevin Kofler

Javascript JIT in web browsers

[Ilyes Gouta]

Kevin,

>  Free Software is not just about availability of source code.
> (That's exactly
>  why the term "Open Source" is misleading!) It's no use having the source
>  code if you aren't allowed to legally do anything with it. 
I did't claim that JS code is open source. It's just that, we all
being able to pull JS code in plain text from a given server, from any
place on the world, doesn't really help classifying that code as a
closed source. Heck, we can even change on the fly a JS piece within
the browser via a JS console (think Greasemonkey for FF, Chome's JS
console). Obfuscation however corroborates the latter aspect.

>  Security against buffer overflow exploits comes from a
> security-conscious
>  design. 
That's what I meant by a (correct) specification and a compliant implementation.

> Converting untrusted code into native machine code and executing
>  that is NOT a security-conscious design, it just begs to get exploited. 
Still, it's can be correctly designed to really lower the risk (or
even eliminate it). That's there is *still* room to make it safer and
I don't see why it has to be completely disabled, banned and shutdown.
Techniques such as process isolation (when running JIT'ed code), I/O
sand-boxing, lowered/restricted privilege resource access, etc. *do*
help.

>  The web is a medium for information, not
>  code.
>  If you really want a platform for remote services (which I'm not convinced I
>  want, I'd rather control the software I'm running), you need to help design
>  a real cloud platform from ground up. 
It's changing. HTML5 and JS are going to be the front-ends for such
remote services provided by those cloud platforms. And these are the
standard way (vs. Adobe's Flash for example) to deliver a rich
experience to the end-user, right in his browser, and IMHO we should
support that.

-Ilyes Gouta

On Thu, Aug 19, 2010 at 3:22 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
> Ilyes Gouta wrote:
>> Since JavaScript has a client-side execution model and since the all
>> the JS scripts are downloaded in plain text format (even if sometimes
>> obfuscated) along with the html code, then can't we assume that JS
>> code is available in source format and hence can't be classified as
>> closed source programs?
>
>  Free Software is not just about availability of source code.
> (That's exactly
>  why the term "Open Source" is misleading!) It's no use having the source
>  code if you aren't allowed to legally do anything with it. 
>
> In addition:
> * Obfuscated code is not source code.
> * Those web apps also have lots of server-side code which is entirely
> secret.
>
>> the next-gen Web where most applications are going to be written in HTML5
>> and JavaScript and almost near-native execution performance is going to be
>> desired
>
> I want none of that useless crap, thank you very much! Applications should
> be written as applications, delivered through our package repository, in a
> compiled language. Web sites should just be web sites and have as little
> code as possible (ideally none). The web is a medium for information, not
> code.
>
> If you really want a platform for remote services (which I'm not convinced I
> want, I'd rather control the software I'm running), you need to help design
> a real cloud platform from ground up. The way the web is being abused as a
> software platform is really appalling. It's really not designed for that,
> and we have tons of ugly workarounds such as session cookies, AJAX etc.
> JavaScript JITs are a part of those broken workarounds.
>
>> Security comes from an implementation which is specification compliant
>
> Nonsense. Standards-compliance is completely orthogonal to security.
>
> Security against buffer overflow exploits comes from a security-conscious
> design. Converting untrusted code into native machine code and executing
> that is NOT a security-conscious design, it just begs to get exploited.
>
>> Techniques such as sand-boxing would also help a lot mitigating malware
>> and other security issues
>
> But an interpreter can enforce the sandboxing in a much more robust and
> failsafe way than a JIT.
>
>        Kevin Kofler
>
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

Javascript JIT in web browsers

[Kevin Kofler]

Ilyes Gouta wrote:
>  It's just that, we all being able to pull JS code in plain text
> from a
>  given server, from any place on the world, doesn't really help classifying
>  that code as a closed source. 
Sorry, but you're arguing against a strawman: I didn't claim that the code 
was "closed source", I said that it's non-Free, which it is.

> > Security against buffer overflow exploits comes from a
> security-conscious
> > design.
>  
>  That's what I meant by a (correct) specification and a compliant
>  implementation. 
And here too, I'm afraid you're missing the point. The same specification 
can be implemented in 2 perfectly compliant ways, one being secure and one 
insecure. A JIT is inherently insecure.

> >Converting untrusted code into native machine code and executing
> > that is NOT a security-conscious design, it just begs to get exploited.
>  
>  Still, it's can be correctly designed to really lower the risk (or
>  even eliminate it). 
I don't believe the risk can be eliminated entirely. There will always be 
unacceptable risk if you execute native code generated at runtime from an 
untrusted source.

>  It's changing. HTML5 and JS are going to be the front-ends for
> such
>  remote services provided by those cloud platforms. And these are the
>  standard way (vs. Adobe's Flash for example) to deliver a rich
>  experience to the end-user, right in his browser, and IMHO we should
>  support that. 
Well, that's not what HTML, nor the underlying HTTP, was designed for. I 
don't see it as being an appropriate platform for software at all. (And I 
don't see plugins such as Flash as being the solution either. I believe this 
needs a completely different protocol, e.g. NX is something going in that 
direction.)

And IMHO, as a Free Software distribution, we should do all we can to 
promote Free Software installed on the end user's machine where he/she has 
full control (freedom!) over the software rather than remote services, web 
or otherwise.

        Kevin Kofler

Javascript JIT in web browsers

[Brandon Lozza]

>  Well, that's not what HTML, nor the underlying HTTP, was designed for. I
>  don't see it as being an appropriate platform for software at all. (And I
>  don't see plugins such as Flash as being the solution either. I believe
>  this
>  needs a completely different protocol, e.g. NX is something going in that
>  direction.)
>
>  
As always Kevin I agree with you. These people don't understand basic OSI
network layers; rather obvious textbook stuff.



>  And IMHO, as a Free Software distribution, we should do all we can
> to
>  promote Free Software installed on the end user's machine where he/she has
>  full control (freedom!) over the software rather than remote services, web
>  or otherwise. 

If we tolerate any non free software then what's the point? Why not just run
Windows or OSX?

Javascript JIT in web browsers

[Adam Jackson]

On Thu, 2010-08-19 at 15:01 -0400, Brandon Lozza wrote:

>  If we tolerate any non free software then what's the point? Why
> not
>  just run Windows or OSX? 
Received: from mail-fx0-f45.google.com (mail-fx0-f45.google.com [209.85.161.45]) by
smtp-mm1.fedoraproject.org (Postfix) with ESMTP id B7DB887E64 for
<devel(a)lists.fedoraproject.org>; Thu, 19 Aug 2010 19:01:22 +0000 (UTC)
Message-id: <AANLkTimAhM2RZXX47G1fuRnM=tzUzuTxJfrW5kVUsEdM(a)mail.gmail.com&gt;

- ajax

Javascript JIT in web browsers

[Ilyes Gouta]

Hi,

> > Well, that's not what HTML, nor the underlying HTTP, was
> designed for. I
> > don't see it as being an appropriate platform for software at all. (And I
> > don't see plugins such as Flash as being the solution either. I believe
> > this
> > needs a completely different protocol, e.g. NX is something going in that
> > direction.)
> >
>
>  As always Kevin I agree with you. These people don't understand basic OSI
>  network layers; rather obvious textbook stuff. 
The cool thing about JS and all what's happening today in the browser
world, is that everything is being done at the application layer
(level 4) of the OSI model, a fact which gives a rather unique
opportunity and freedom to software designers to specify applications
protocols easily and without huge constraints vs. what someone has to
deal with if you're at level 3, that's IP. However, like any protocols
meant to be adopted by the majority, app. protocols must also gain the
approbation and consensus of a majority and ideally the spec. must be
made accessible to everyone and implemented accordingly. This is what
drives tech. adoption and global deployment (think HTTP, SOAP, XML and
on the other hand hopefully WebM vs. H.264) and a basis and a
foundation for the next iteration. It happens that HTML (and its
siblings) and JS are part of this wild landscape and both are
*evolving*, and (IMHO) I would like to see Fedora leading (and
pursuing) the way with this.

-Ilyes Gouta

> >
> > And IMHO, as a Free Software distribution, we should do all we can to
> > promote Free Software installed on the end user's machine where he/she has
> > full control (freedom!) over the software rather than remote services, web
> > or otherwise.
>
>  If we tolerate any non free software then what's the point? Why not just run
>  Windows or OSX?
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>

Javascript JIT in web browsers

[J. Randall Owens]

On 08/19/2010 02:07 PM, Ilyes Gouta wrote:
>  Hi,
>  
> > As always Kevin I agree with you. These people don't understand basic OSI
> > network layers; rather obvious textbook stuff.
>  
>  The cool thing about JS and all what's happening today in the browser
>  world, is that everything is being done at the application layer
>  (level 4) of the OSI model, a fact which gives a rather unique
>  opportunity and freedom to software designers to specify applications
>  protocols easily and without huge constraints vs. what someone has to
>  deal with if you're at level 3, that's IP.  
OK, I'll just tell the transport, session, and presentation layers they
can take the day off now, since we're using a four-layer model that
doesn't allow TCP, UDP, or ICMP, and calling it the OSI model anyway.

-- 
J. Randall Owens | http://www.ghiapet.net/

Javascript JIT in web browsers

[Ilyes Gouta]

> > world, is that everything is being done at the application layer
> > (level 4) of the OSI model, a fact which gives a rather unique 
Should actually read:

at the application layer
(level 4) of the TCP/IP model, a fact which gives a rather unique

-Ilyes Gouta

On Thu, Aug 19, 2010 at 11:25 PM, J. Randall Owens
<jrowens.fedora(a)ghiapet.net&gt; wrote:
> On 08/19/2010 02:07 PM, Ilyes Gouta wrote:
>> Hi,
>>
>>> As always Kevin I agree with you. These people don't understand basic
OSI
>>> network layers; rather obvious textbook stuff.
>>
>> The cool thing about JS and all what's happening today in the browser
> > world, is that everything is being done at the application layer
> > (level 4) of the OSI model, a fact which gives a rather unique 
>>
opportunity and freedom to software designers to specify applications
>> protocols easily and without huge constraints vs. what someone has to
>> deal with if you're at level 3, that's IP.
>
> OK, I'll just tell the transport, session, and presentation layers they
> can take the day off now, since we're using a four-layer model that
> doesn't allow TCP, UDP, or ICMP, and calling it the OSI model anyway.
>
> --
> J. Randall Owens | http://www.ghiapet.net/
>
>
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

Javascript JIT in web browsers

[David Eisner]

On Thu, Aug 19, 2010 at 2:54 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Well, that's not what HTML, nor the underlying HTTP, was designed
> for. I
>  don't see it as being an appropriate platform for software at all. (And I 
Like it or not, the web browser has become a runtime environment,
capable of executing both Free and non-Free code.  HTML and HTTP were
designed to present hypertext documents.  And yet here we are, two
decades later, and HTML has evolved (with the help of other
technologies like CSS and Javascript) so that the browser can also run
applications.

Predicting the future is a fool's errand, but I suspect it is going to
look more and more like this:

  http://googlewebtoolkit.blogspot.com/2010/04/look-ma-no-plugin.html

Warning: contains video and img tags (the latter a perversion of HTML
introduced by Marc Andreessen in 1993).  (I'm not predicting an
alien-infested post-apocalyptic future, btw.)

At one extreme (and not something you're suggesting), the browsers
available on Fedora could be patched to blacklist non-free web apps,
like Gmail.  The browser could instead display the GNU gnu holding a
stop sign, or wagging its finger.

Alternately, these browsers could make web apps second-class citizens,
with poor performance. I don't think that's a good idea, either. At
the very least, it will create the impression that Free software
doesn't perform as efficiently as it's non-Free counterparts.

Or Fedora could endeavor to provide a top-notch web app runtime
capable of executing both Free and non-Free applications (just as it
ships a libc that can run both Free and non-Free applications).  That
would be my vote.

Whatever choice is made, it shouldn't be based on what Sir Tim
Berners-Lee intended HTML to be used for in 1990.

-David

Javascript JIT in web browsers

[drago01]

On Thu, Aug 19, 2010 at 8:54 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:

> > That's what I meant by a (correct) specification and a
> compliant
> > implementation.
>
>  And here too, I'm afraid you're missing the point. The same specification
>  can be implemented in 2 perfectly compliant ways, one being secure and one
>  insecure. A JIT is inherently insecure. 
The same specification can be implemented in 2 perfectly compliant
ways, one being slow and one being fast.
An interpreter is inherently slow ;)

> > It's changing. HTML5 and JS are going to be the front-ends
> for such
> > remote services provided by those cloud platforms. And these are the
> > standard way (vs. Adobe's Flash for example) to deliver a rich
> > experience to the end-user, right in his browser, and IMHO we should
> > support that.
>
>  Well, that's not what HTML, nor the underlying HTTP, was designed for. I
>  don't see it as being an appropriate platform for software at all. (And I
>  don't see plugins such as Flash as being the solution either. I believe this
>  needs a completely different protocol, e.g. NX is something going in that
>  direction.)
>
>  And IMHO, as a Free Software distribution, we should do all we can to
>  promote Free Software installed on the end user's machine where he/she has
>  full control (freedom!) over the software rather than remote services, web
>  or otherwise. 
Every browser has an option to disable JS, firefox even has an option
to disable it for specific sites or enable it using a whitelist.
You are free to do that on your machine but you have to accept that
others want to 1) use web apps 2) want them to be fast.

Javascript JIT in web browsers

[Kevin Kofler]

drago01 wrote:
>  The same specification can be implemented in 2 perfectly compliant
>  ways, one being slow and one being fast.
>  An interpreter is inherently slow ;) 
Sorry, but I don't think exposing our users to remote arbitrary code 
execution (!) vulnerabilities just to make web apps a bit faster is a 
reasonable tradeoff.

        Kevin Kofler

Javascript JIT in web browsers

[Michael Cronenworth]

Kevin Kofler wrote:
>  Sorry, but I don't think exposing our users to remote arbitrary
> code
>  execution (!) vulnerabilities just to make web apps a bit faster is a
>  reasonable tradeoff. 
Kevin, if you took off your FSF blindfold you would see that it's better 
for web sites to use JavaScript. If they complied to /your/ wishes we 
would have a thousand proprietary protocols, probably all /closed/ 
source, to communicate in between /closed/ source applications. Most 
likely Microsoft or another Closed Source vendor would create a protocol 
standard that applications would adopt, and you yourself would probably 
have to write to! In this situation we have to choose the lesser of two 
evils instead of no evils.

Javascript JIT in web browsers

[Kevin Kofler]

Michael Cronenworth wrote:
>  Kevin, if you took off your FSF blindfold you would see that it's
> better
>  for web sites to use JavaScript. If they complied to /your/ wishes we
>  would have a thousand proprietary protocols, probably all /closed/
>  source, to communicate in between /closed/ source applications. Most
>  likely Microsoft or another Closed Source vendor would create a protocol
>  standard that applications would adopt, and you yourself would probably
>  have to write to! In this situation we have to choose the lesser of two
>  evils instead of no evils. 
The "lesser of 2 evils" is no solution. Only NO evil at all will keep the 
user's freedom. Users should NEVER use proprietary software, be it as 
JavaScript or using a proprietary protocol.

        Kevin Kofler

Javascript JIT in web browsers

[Léon Keijser]

On Fri, 2010-08-20 at 03:46 +0200, Kevin Kofler wrote: 
>  The "lesser of 2 evils" is no solution. Only NO evil at all
> will keep the 
>  user's freedom. Users should NEVER use proprietary software, be it as 
>  JavaScript or using a proprietary protocol. 

Shouldn't users be free to make that decision on their own? :)


Léon

Javascript JIT in web browsers

[Brandon Lozza]

On Fri, Aug 20, 2010 at 1:48 AM, Léon Keijser <keijser(a)stone-it.com&gt; wrote:

>  On Fri, 2010-08-20 at 03:46 +0200, Kevin Kofler wrote:
>  > The "lesser of 2 evils" is no solution. Only NO evil at all will keep the
>  > user's freedom. Users should NEVER use proprietary software, be it as
>  > JavaScript or using a proprietary protocol.
>
>
>  Shouldn't users be free to make that decision on their own? :)
>
>  
Shouldn't companies be free to spy on us and rip us off?

Javascript JIT in web browsers

[Matthew Garrett]

On Fri, Aug 20, 2010 at 03:46:11AM +0200, Kevin Kofler wrote:
>  Michael Cronenworth wrote:
>  > Kevin, if you took off your FSF blindfold you would see that it's better
>  > for web sites to use JavaScript. If they complied to /your/ wishes we
>  > would have a thousand proprietary protocols, probably all /closed/
>  > source, to communicate in between /closed/ source applications. Most
>  > likely Microsoft or another Closed Source vendor would create a protocol
>  > standard that applications would adopt, and you yourself would probably
>  > have to write to! In this situation we have to choose the lesser of two
>  > evils instead of no evils.
>  
>  The "lesser of 2 evils" is no solution. Only NO evil at all will keep the 
>  user's freedom. Users should NEVER use proprietary software, be it as 
>  JavaScript or using a proprietary protocol. 
How's your open x86 microcode coming along?

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

Javascript JIT in web browsers

[Jon Masters]

On Fri, 2010-08-20 at 16:55 +0100, Matthew Garrett wrote:
>  On Fri, Aug 20, 2010 at 03:46:11AM +0200, Kevin Kofler wrote: 
>  > The "lesser of 2 evils" is no solution. Only NO evil
> at all will keep the 
>  > user's freedom. Users should NEVER use proprietary software, be it as 
>  > JavaScript or using a proprietary protocol.
>  
>  How's your open x86 microcode coming along? 
Or BIOS code? Or device firmware for the adapters installed?

Don't forget to get a completely open cellphone, laptop, fridge,
microwave, car, house, etc. You'll need to give up using anything
non-open, so unfortunately will probably not be able to post here due to
the entire chain of devices between you and the outside not being open.

Jon.

Javascript JIT in web browsers

[Peter Jones]

On 08/20/2010 12:43 PM, Jon Masters wrote:
>  On Fri, 2010-08-20 at 16:55 +0100, Matthew Garrett wrote:
> > On Fri, Aug 20, 2010 at 03:46:11AM +0200, Kevin Kofler wrote:
>  
> >> The "lesser of 2 evils" is no solution. Only NO evil at all will keep
> the 
> >> user's freedom. Users should NEVER use proprietary software, be it as 
> >> JavaScript or using a proprietary protocol.
> >
> > How's your open x86 microcode coming along?
>  
>  Or BIOS code? 
Fedora support for GPL-compatible system firmware on x86 is working pretty
well at this point.

Thanks for asking.

-- 
        Peter

All parts should go together without forcing. You must remember that
the parts you are  reassembling were disassembled by you.  Therefore,
if you can't get them together again, there must be a reason. By all
means, do not use a hammer.
		-- IBM maintenance manual, 1925

01234567890123456789012345678901234567890123456789012345678901234567890123456789

Javascript JIT in web browsers

[Ryan Rix]

On Thu 19 August 2010 15:01:17 Michael Cronenworth wrote:
>  Kevin Kofler wrote:
>  > Sorry, but I don't think exposing our users to remote arbitrary code
>  > execution (!) vulnerabilities just to make web apps a bit faster is a
>  > reasonable tradeoff.
>  
>  Kevin, if you took off your FSF blindfold you would see that it's better
>  for web sites to use JavaScript. If they complied to /your/ wishes we
>  would have a thousand proprietary protocols, probably all /closed/
>  source, to communicate in between /closed/ source applications. Most
>  likely Microsoft or another Closed Source vendor would create a protocol
>  standard that applications would adopt, and you yourself would probably
>  have to write to! In this situation we have to choose the lesser of two
>  evils instead of no evils. 
You should meet my friend Chicken Little.

-- 
Ryan Rix
== http://hackersramblings.wordpress.com | http://rix.si/ ==
== http://rix.si/page/contact/ if you need a word         ==

Javascript JIT in web browsers

[Ilyes Gouta]

Hi,

> > Still, it's can be correctly designed to really lower the
> risk (or
> > even eliminate it).
>
>  I don't believe the risk can be eliminated entirely. There will always be
>  unacceptable risk if you execute native code generated at runtime from an
>  untrusted source. 
How about a very well maintained open source piece of software, such
as Firefox, WebKit and WebKit2 (http://trac.webkit.org/wiki/WebKit2),
as a source of that generated native code at runtime? This would
immensely help verifying the emitter of such a code and take the
appropriate action, if needed.

-Ilyes Gouta

> > It's changing. HTML5 and JS are going to be the front-ends
> for such
> > remote services provided by those cloud platforms. And these are the
> > standard way (vs. Adobe's Flash for example) to deliver a rich
> > experience to the end-user, right in his browser, and IMHO we should
> > support that.
>
>  Well, that's not what HTML, nor the underlying HTTP, was designed for. I
>  don't see it as being an appropriate platform for software at all. (And I
>  don't see plugins such as Flash as being the solution either. I believe this
>  needs a completely different protocol, e.g. NX is something going in that
>  direction.)
>
>  And IMHO, as a Free Software distribution, we should do all we can to
>  promote Free Software installed on the end user's machine where he/she has
>  full control (freedom!) over the software rather than remote services, web
>  or otherwise.
>
>         Kevin Kofler
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>

Javascript JIT in web browsers

[Kevin Kofler]

Ilyes Gouta wrote:
>  How about a very well maintained open source piece of software, such
>  as Firefox, WebKit and WebKit2 (http://trac.webkit.org/wiki/WebKit2),
>  as a source of that generated native code at runtime? This would
>  immensely help verifying the emitter of such a code and take the
>  appropriate action, if needed. 
Sorry, but you misunderstood me (again :-( )! The source of the native code 
is the JavaScript. Those pieces of software you list (or rather, the JITs 
they include) are only the mechanism which translates it to native code.

        Kevin Kofler

Javascript JIT in web browsers

[Matej Cepl]

Ilyes Gouta, Thu, 19 Aug 2010 21:43:45 +0100:
>  How about a very well maintained open source piece of software, such
> as
>  WebKit 
which of the two forks of KHTML is well maintained in your opinion? 
Google one? (http://spot.livejournal.com/312320.html)

>  and WebKit2 (http://trac.webkit.org/wiki/WebKit2), as a 
well-maintained piece of pre-Alpha unreleased code.

Please,

Matěj

-- 
http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
SCSI is *not* magic. There are *fundamental* *technical*
reasons why you have to sacrifice a young goat to your SCSI
chain every now and then.
    -- John F. Woods (jfw(a)funhouse.com)

Javascript JIT in web browsers

[Ilyes Gouta]

Matej,

> > and WebKit2 (http://trac.webkit.org/wiki/WebKit2), as a
>
>  well-maintained piece of pre-Alpha unreleased code. 
I brought this one because of the architecture redesign, that tries to
address some security and performance points, not for the code quality
per se., which is still being worked on.

-Ilyes Gouta

>  Please,
>
>  Matěj
>
>  --
>  http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
>  GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
>
>  SCSI is *not* magic. There are *fundamental* *technical*
>  reasons why you have to sacrifice a young goat to your SCSI
>  chain every now and then.
>     -- John F. Woods (jfw(a)funhouse.com)
>
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Javascript JIT in web browsers

[Ilyes Gouta]

Hi,

What about the WebKit SIG that Jaroslav Reznik wants to setup?

http://lists.fedoraproject.org/pipermail/devel/2010-August/140497.html

-Ilyes Gouta

On Sat, Aug 21, 2010 at 1:28 PM, Ilyes Gouta <ilyes.gouta(a)gmail.com&gt; wrote:
>  Matej,
>
> >> and WebKit2 (http://trac.webkit.org/wiki/WebKit2), as a
> >
> > well-maintained piece of pre-Alpha unreleased code.
>
>  I brought this one because of the architecture redesign, that tries to
>  address some security and performance points, not for the code quality
>  per se., which is still being worked on.
>
>  -Ilyes Gouta
>
> > Please,
> >
> > Matěj
> >
> > --
> > http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
> > GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
> >
> > SCSI is *not* magic. There are *fundamental* *technical*
> > reasons why you have to sacrifice a young goat to your SCSI
> > chain every now and then.
> >    -- John F. Woods (jfw(a)funhouse.com)
> >
> >
> > --
> > devel mailing list
> > devel(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
>

Javascript JIT in web browsers

[Adam Jackson]

On Fri, 1994-08-19 at 16:22 +0200, Kevin Kofler wrote:

>  I want none of that useless crap, thank you very much! Applications
> should 
>  be written as applications, delivered through our package repository, in a 
>  compiled language. Web sites should just be web sites and have as little 
>  code as possible (ideally none). The web is a medium for information, not 
>  code. 
- ajax

Javascript JIT in web browsers

[drago01]

On Mon, Aug 16, 2010 at 1:15 AM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  drago01 wrote:
> > The times where javascript is only used for some fancy effects are
> > long over ... welcome to 2010 ;)
>
>  Some web sites are indeed abusing JavaScript. Why should we promote this
>  behavior? It is a vehicle for proprietary software, where people often
>  aren't even aware they're using non-Free code, or just ignore the issue.
>  See also http://www.gnu.org/philosophy/javascript-trap.html . A web site is
>  not and should not be an application, an application is not and should not
>  be a web site. 
There is a difference between a website and web *application*.
Besides who is stopping me (or anyone else) from writing a free
software web app that uses Javascript? People have been and are doing
that all the time.
By your logic we should ban gcc, java, mono, python, perl, bash ... as
one can use them to create and/or run non free software.

Also you may be aware that javascript has its uses *outside* of the
web too (just like you can write apps in python you can do it in JS;
and having a JIT that speeds them up is definitely a plus).

> > The "problem" is fixable there is a patch that is being
> discussed
> > upstream to fix the issue and allow selinux memory protection it is
> > just not merged yet.
> >
> > Using a JIT is not a security risk by itself.
>
>  Workarounds which make SELinux happy are still not as secure as sticking to
>  a pure bytecode interpreter. Exploit code can still write to the memory to
>  be executed, with ANY JIT, as this is how a JIT works. It's just that the
>  writing has to happen through a different address space window as the
>  execution, making the JIT harder, but not impossible, to exploit.
>
>  So IMHO the right fix is to disable the JIT altogether. 
This is *not* a fix. You can't solve problems by disabling features
and pretending they do not exists.

>  But the proposed patch would still be better than the crappy
> solution
>  implemented now just to "stick to upstream" 
Yeah because forking a web browser which would end up with a more
secure experience than joining forces with upstream with the expertize
there and can deliver security fixes on time (which also apply to our
version).

Javascript JIT in web browsers

[Brandon Lozza]

I've already seen websites exploit firefox tabs and they made use of my
gmail account to send spam.

Why should we make firefox easier to exploit?

On Mon, Aug 16, 2010 at 5:07 AM, drago01 <drago01(a)gmail.com&gt; wrote:

>  On Mon, Aug 16, 2010 at 1:15 AM, Kevin Kofler
> <kevin.kofler(a)chello.at&gt;
>  wrote:
>  > drago01 wrote:
>  >> The times where javascript is only used for some fancy effects are
>  >> long over ... welcome to 2010 ;)
>  >
>  > Some web sites are indeed abusing JavaScript. Why should we promote this
>  > behavior? It is a vehicle for proprietary software, where people often
>  > aren't even aware they're using non-Free code, or just ignore the issue.
>  > See also http://www.gnu.org/philosophy/javascript-trap.html . A web site
>  is
>  > not and should not be an application, an application is not and should
>  not
>  > be a web site.
>
>  There is a difference between a website and web *application*.
>  Besides who is stopping me (or anyone else) from writing a free
>  software web app that uses Javascript? People have been and are doing
>  that all the time.
>  By your logic we should ban gcc, java, mono, python, perl, bash ... as
>  one can use them to create and/or run non free software.
>
>  Also you may be aware that javascript has its uses *outside* of the
>  web too (just like you can write apps in python you can do it in JS;
>  and having a JIT that speeds them up is definitely a plus).
>
>  >> The "problem" is fixable there is a patch that is being discussed
>  >> upstream to fix the issue and allow selinux memory protection it is
>  >> just not merged yet.
>  >>
>  >> Using a JIT is not a security risk by itself.
>  >
>  > Workarounds which make SELinux happy are still not as secure as sticking
>  to
>  > a pure bytecode interpreter. Exploit code can still write to the memory
>  to
>  > be executed, with ANY JIT, as this is how a JIT works. It's just that the
>  > writing has to happen through a different address space window as the
>  > execution, making the JIT harder, but not impossible, to exploit.
>  >
>  > So IMHO the right fix is to disable the JIT altogether.
>
>  This is *not* a fix. You can't solve problems by disabling features
>  and pretending they do not exists.
>
>  > But the proposed patch would still be better than the crappy solution
>  > implemented now just to "stick to upstream"
>
>  Yeah because forking a web browser which would end up with a more
>  secure experience than joining forces with upstream with the expertize
>  there and can deliver security fixes on time (which also apply to our
>  version).
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>

Javascript JIT in web browsers

[Brandon Lozza]

>  By your logic we should ban gcc, java, mono, python, perl, bash ... as
>  one can use them to create and/or run non free software.
>
>  Also you may be aware that javascript has its uses *outside* of the
>  web too (just like you can write apps in python you can do it in JS;
>  and having a JIT that speeds them up is definitely a plus).
>
>  
I'm up for banning mono, and perhaps java now that Oracle is suing everyone

Javascript JIT in web browsers

[Dariusz J. Garbowski]

On 16/08/10 08:10 AM, Brandon Lozza wrote:
>  
>      By your logic we should ban gcc, java, mono, python, perl, bash ... as
>      one can use them to create and/or run non free software.
>  
>      Also you may be aware that javascript has its uses *outside* of the
>      web too (just like you can write apps in python you can do it in JS;
>      and having a JIT that speeds them up is definitely a plus).
>  
>  
>  I'm up for banning mono, and perhaps java now that Oracle is suing everyone  
Java != JavaScript

[Kevin Kofler]

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

[Chris Adams]

Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at&gt; 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?  They have enough patches to sort through every release as
it is, and they don't want to add more.

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Kevin Kofler]

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 had to remove useful packages due to size constraints, 
improving the compression would allow us to ship more software while still 
keeping the ISOs CD-sized.

        Kevin Kofler

[Matthew Garrett]

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 make all our live images better. Both the GNOME and the 
>  KDE live image had to remove useful packages due to size constraints, 
>  improving the compression would allow us to ship more software while still 
>  keeping the ISOs CD-sized. 
Then those impacted should do the work necessary to ensure that there's 
a supportable version of the code available to use in the Fedora kernel, 
or alternatively take over enough of the existing kernel work that 
someone else gains enough time to take responsibility.

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

[Chris Adams]

Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at&gt; 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
shouldn't be able to set an update policy for KDE packages.

Why don't you give the kernel maintainers the same courtesy?

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Kevin Kofler]

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 desktop 
SIGs. (And FWIW, GNOME really needs a community-oriented SIG instead of the 
current "RH Desktop Team == Fedora GNOME maintainers" practice.)

        Kevin Kofler

[Rahul Sundaram]

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 should be the ones making the decision.
>  
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.  If non upstream patches is needed,
it requires someone to take ownership of keeping the patches updated for the
kernel updates.  If you are volunteering to do that work,  please talk to
the kernel developers.  Otherwise,  let them do their job without micro
management.

Rahul

[Kevin Kofler]

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 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.

>  If non upstream patches is needed, it requires someone to take
> ownership
>  of keeping the patches updated for the kernel updates.  If you are
>  volunteering to do that work,  please talk to the kernel developers. 
I would, but my experience is that they'll probably say "no" anyway. I know

it has been offered in the past, for various out-of-tree patches and kernel 
modules, they only accepted it in very few cases (e.g. for Hans de Goede's 
webcam driver stuff because he also worked on getting the stuff merged 
upstream, not just into Fedora; 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, cosmetic (i.e. code 
formatting rules), and social) you have to learn over the time, and the 
kernel is also a hard codebase to work with in the first place; it's a lot 
easier to regularly rebase a patch than to make it palatable to upstream, 
that's why there are so many out-of-tree patchsets).

        Kevin Kofler

[Chris Adams]

Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at&gt; 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, cosmetic (i.e. code 
>  formatting rules), and social) you have to learn over the time, 
I've heard this before, but I didn't find it to be that much different
than any other project where I've contributed changes.  I think the
biggest annoyance was that, because the kernel project is so big and
hierarchical, you don't always get a lot of feedback (even when one of
the maintainers picks up your patch in their tree to go upstream).

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Adam Williamson]

On Fri, 2010-08-13 at 10:52 -0500, Chris Adams wrote:
>  Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at&gt; 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, cosmetic (i.e. code 
>  > formatting rules), and social) you have to learn over the time,
>  
>  I've heard this before, but I didn't find it to be that much different
>  than any other project where I've contributed changes.  I think the
>  biggest annoyance was that, because the kernel project is so big and
>  hierarchical, you don't always get a lot of feedback (even when one of
>  the maintainers picks up your patch in their tree to go upstream). 
Me either. I'm not a coder, I don't really know anyone involved in
kernel development. Yet I have a bona fide kernel commit to my name -
f71cf2a2181aef25513272991f54148799ddc1f0 .

I notice multiple cases of Kevin complaining how political certain
projects are, and how much they hate outsiders, and how difficult it is
to get stuff committed to them. I note that the common link between all
these cases appears to be Kevin. Perhaps the problem isn't the projects,
after all?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Ryan Rix]

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/ if you need a word         ==

[Adam Williamson]

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 are to get upstream and
how 'political' Mozilla is, though.

(It would help if Kevin would provide the details people have repeatedly
asked for - how exactly has anyone tried to get these patches upstream,
and what was the Mozilla project's reason for not taking them yet? I
haven't seen answers to those questions.)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Rahul Sundaram]

 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 requires requests and collaboration
and not demands.  You will have to change your approach. 

> > If non upstream patches is needed, it requires someone to take
> ownership
> > of keeping the patches updated for the kernel updates.  If you are
> > volunteering to do that work,  please talk to the kernel developers.
>  I would, but my experience is that they'll probably say "no" anyway. I know
>
>  it has been offered in the past, for various out-of-tree patches and kernel 
>  modules, they only accepted it in very few cases (e.g. for Hans de Goede's 
>  webcam driver stuff because he also worked on getting the stuff merged 
>  upstream, not just into Fedora; 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, cosmetic (i.e. code 
>  formatting rules), and social) you have to learn over the time, and the 
>  kernel is also a hard codebase to work with in the first place; it's a lot 
>  easier to regularly rebase a patch than to make it palatable to upstream, 
>  that's why there are so many out-of-tree patchsets). 
That is also why so many out of tree patchsets do not have the quality
of what is in upstream.  They have not gone through the feedback cycle
to get them fixed.  Similar to packages in the repo vs not.    Noone
wants to take on more patches and carry them forward without ownership
and a timeline to get those patches merged.  If you are not willing to
do that work and yes it is tough, then you don't get to demand anything
either. 

Rahul

[Chris Adams]

Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at&gt; 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 the
distribution (or all packages that tangentially affect them).
-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Kevin Kofler]

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

[Chris Adams]

Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at&gt; 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 your opinion, and (many) others disagree.  Please stop stating
your opinion as fact.
-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Adam Williamson]

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. 
So, your proposal is that FESCo (and possibly the Board) - which you
excoriate for not being sufficiently elected for your tastes - be
replaced by the SIGs, entirely informal and entirely unelected groups
with no formal place in Fedora's governance structure at all?

Oh, yes, that's going to work well.

How do we decide which SIGs trump which other SIGs if they disagree? How
are SIGs - groups which are by their very definition based around
certain specific interests - supposed to set distro-wide policies for
packaging? Why are groups which anyone can join (or, alternatively,
which can choose their membership based on any criteria at all) better
qualified to run the project than a board, and committees, to which
people are elected by vote of project members?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Kevin Kofler]

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), just what SIG gets to 
decide. One useful rule of thumb is that global integration concerns should 
trump individual packager preferences.

>  How are SIGs - groups which are by their very definition based
> around
>  certain specific interests - supposed to set distro-wide policies for
>  packaging? 
FPC would be considered a SIG in such a SIG-driven world, they'd be the SIG 
responsible for distro-wide packaging policies (and they'd decide them on 
their own, without FESCo ratification).

>  Why are groups which anyone can join (or, alternatively, which can
> choose
>  their membership based on any criteria at all) better qualified to run the
>  project than a board, and committees, to which people are elected by vote
>  of project members? 
Because those are groups where people know each other (at least through the 
net, but sometimes also in person) and are used to working together on the 
same things, and which are composed of experts in the subject matter. It's 
up to the SIGs to ensure that the people who get to make the decisions are 
also the ones doing the work (the meritocratic principle), but that's really 
the individual SIG's problem, and existing SIGs already have well-working 
ways to ensure that.

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 candidates (I know I did and 
I also know I'm not the only one).

        Kevin Kofler

[Kevin Kofler]

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 candidates
>  (I know I did and I also know I'm not the only one). 
PS: The election system is also incompatible with meritocracy, as a new 
contributor who maintains 1 package has the same rights as an experienced 
Fedora packager maintaining dozens of packages and comaintaining hundreds 
for years.

        Kevin Kofler

[Bruno Wolff III]

On Fri, Aug 13, 2010 at 16:54:22 +0200,
  Kevin Kofler <kevin.kofler(a)chello.at&gt; 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 should be the ones making the decision. This means the 4 desktop 
>  SIGs. (And FWIW, GNOME really needs a community-oriented SIG instead of the 
>  current "RH Desktop Team == Fedora GNOME maintainers" practice.) 
In this case I think waiting is better, even though I proposed the feature.
I was planning on requesting a back port if a patch for it gets accepted
for 2.6.36, but it seems unlikely to happen as the merge window will
be closing shortly.

The issue is that if we apply the patch that was submitted for an earlier
kernel (2.6.33 I think), and it had a problem due to some other change in
the kernel, we don't have a practical way to support it. (While Lougher
was VERY helpful recently with tracking down a squashfs-tools bug, we can't
always count on having a few days of his time to provide us with support.)

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.

[Kevin Kofler]

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 compression rate makes to 
our live images! For KDE, we have to fight for every single MB, often making 
tough decisions (e.g. size constraints are why we no longer ship Amarok on 
the live image). Better compression would allow us quite some headroom to 
work with.

        Kevin Kofler

[Dave Jones]

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, apparently) don't seem to 
>  realize what big difference a 10% improvement in compression rate makes to 
>  our live images! 
We realize. We just don't care.
(for reasons already given)

	Dave

[Bruno Wolff III]

On Fri, Aug 13, 2010 at 18:20:29 +0200,
  Kevin Kofler <kevin.kofler(a)chello.at&gt; 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, apparently) don't seem to 
>  realize what big difference a 10% improvement in compression rate makes to 
>  our live images! For KDE, we have to fight for every single MB, often making 
>  tough decisions (e.g. size constraints are why we no longer ship Amarok on 
>  the live image). Better compression would allow us quite some headroom to 
>  work with. 
I think I do realize that a 10% size improvement is very nice. Unfortunately
I don't have the ability to maintain Lougher's previously posted patches
(and have other work important to Fedora that would greatly suffer if I
took time out to learn how to do it). I have similar issues with the Games
Spin. That's why I have been pushing for this. But I don't have the money to
pay Lougher to do a new implementation now, nor do i have time to learn how
do an implementation myself.

Also note, that all of the infrastructure is in place except kernel support.
So that if say 2.6.37 gains LZMA support for squashfs, you'll be able to
use it in F14 to do builds taking advantage of it. You won't necessarily need
to wait for F15 to start taking advantage of it. (Though it will end up being
too late for the GA Release images unless something unexpected happens in the
next few days.)

[Matthew Garrett]

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 kernels then we're either stuck with whatever version of the 
patchset happened to apply to the kernel version that we're shipping or 
we have to backport the upstream code. The former means that someone has 
to spend time backporting upstream fixes, the latter means that someone 
has to spend time backporting the entire code. Couple that with 
Squashfs's traditionally pretty dreadful userspace compatibility and 
you've got a large quantity of work that would be the responsibility of 
the kernel team.

If there's someone with extensive experience in maintaining a Linux 
filesystem who wants to maintain this code in Fedora then it's worth 
having a discussion about it, but otherwise there simply isn't enough 
manpower available to do a proper job of looking after the code. That's 
not politics.

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org