Hi,
Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released recently and I am wondering if we can go with it if it fits into the schedule. There are dozens of new features including WebM support that would be nice to have.
Rahul
On 07/27/2010 10:53 PM, Rahul Sundaram wrote:
Hi,
Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released recently and I am wondering if we can go with it if it fits into the schedule. There are dozens of new features including WebM support that would be nice to have.
Rahul
The final version of FF4 is scheduled at oct-nov 2010 and Fedora 14 at 26 Oct 2010
I think, it's OK to have ff4 in F14, and better is IMHO is to have a parallel installation, something like:
firefox3-3.x.x firefox-4.x.x
Sources:
[1] https://wiki.mozilla.org/Releases [2] http://fedoraproject.org/wiki/Releases/14/Schedule
On Tue, 27 Jul 2010, Athmane Madjoudj wrote:
On 07/27/2010 10:53 PM, Rahul Sundaram wrote:
Hi,
Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released recently and I am wondering if we can go with it if it fits into the schedule. There are dozens of new features including WebM support that would be nice to have.
Rahul
The final version of FF4 is scheduled at oct-nov 2010 and Fedora 14 at 26 Oct 2010
I think, it's OK to have ff4 in F14, and better is IMHO is to have a parallel installation, something like:
firefox3-3.x.x firefox-4.x.x
Sources:
[1] https://wiki.mozilla.org/Releases [2] http://fedoraproject.org/wiki/Releases/14/Schedule
-1 didn't the last time we started using a pre-release from Mozilla turn out pretty bad for us?
-Mike
On 07/27/2010 11:08 PM, Mike McGrath wrote:
On Tue, 27 Jul 2010, Athmane Madjoudj wrote:
On 07/27/2010 10:53 PM, Rahul Sundaram wrote:
Hi,
Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released recently and I am wondering if we can go with it if it fits into the schedule. There are dozens of new features including WebM support that would be nice to have.
Rahul
The final version of FF4 is scheduled at oct-nov 2010 and Fedora 14 at 26 Oct 2010
I think, it's OK to have ff4 in F14, and better is IMHO is to have a parallel installation, something like:
firefox3-3.x.x firefox-4.x.x
Sources:
[1] https://wiki.mozilla.org/Releases [2] http://fedoraproject.org/wiki/Releases/14/Schedule
-1 didn't the last time we started using a pre-release from Mozilla turn out pretty bad for us?
-Mike
This remind me Thunderbird 3 beta in F11
F11 or F12 had a beta version of firefox
spot's chromium builds do support webm, it works great :)
On Tue, Jul 27, 2010 at 6:11 PM, Athmane Madjoudj athmanem@gmail.com wrote:
On 07/27/2010 11:08 PM, Mike McGrath wrote:
On Tue, 27 Jul 2010, Athmane Madjoudj wrote:
On 07/27/2010 10:53 PM, Rahul Sundaram wrote:
Hi,
Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released recently and I am wondering if we can go with it if it fits into the schedule. There are dozens of new features including WebM support that would be nice to have.
Rahul
The final version of FF4 is scheduled at oct-nov 2010 and Fedora 14 at 26 Oct 2010
I think, it's OK to have ff4 in F14, and better is IMHO is to have a parallel installation, something like:
firefox3-3.x.x firefox-4.x.x
Sources:
[1] https://wiki.mozilla.org/Releases [2] http://fedoraproject.org/wiki/Releases/14/Schedule
-1 didn't the last time we started using a pre-release from Mozilla turn out pretty bad for us?
-Mike
This remind me Thunderbird 3 beta in F11
-- Athmane Madjoudj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 28/07/2010 00:24, Brandon Lozza wrote:
F11 or F12 had a beta version of firefox
spot's chromium builds do support webm, it works great :)
It's still not included in fedora's repositories, so it doesn't change anything. Firefox 4 in F14 is, in my opinion, a MUST HAVE for a distribution "leading the way".
Florent
On Wed, 28 Jul 2010, Florent Le Coz wrote:
On 28/07/2010 00:24, Brandon Lozza wrote:
F11 or F12 had a beta version of firefox
spot's chromium builds do support webm, it works great :)
It's still not included in fedora's repositories, so it doesn't change anything. Firefox 4 in F14 is, in my opinion, a MUST HAVE for a distribution "leading the way".
In my opinion including software that even upstream says is not ready is for a distribution that's "lost their way". We can still be a leading distribution and not include pre-release software. Especially pre-release software that's not only in our critical path, but also something that almost all of us use every day. Maybe as firefox4 available in updates-testing, but certainly not a core default package.
I think what people are missing is that even though our release is scheduled for late October. The feature freeze was _yesterday_. meaning that firefox would need to have been ready for use yesterday. Not in October when it might maybe be ready.
There's a difference between making people use new software and making them use half-baked software. Lets not be the half-baked distro.
-Mike
On Wed, Jul 28, 2010 at 8:57 AM, Frank Murphy frankly3d@gmail.com wrote:
On 28/07/10 13:52, Mike McGrath wrote:
<snip> Maybe as firefox4 available in > updates-testing, but certainly not a core default package.
+1
-- Regards,
Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
+1
It should be in updates-testing
2010/7/28 Frank Murphy frankly3d@gmail.com:
On 28/07/10 13:52, Mike McGrath wrote:
<snip> Maybe as firefox4 available in > updates-testing, but certainly not a core default package.
+1
-- Regards,
This is extremely complicated which means we can't push any xulrunner related packages to stable for a long time even for a security issue.
Regard, Chen Lei
On Wed, Jul 28, 2010 at 9:28 AM, Chen Lei wrote:
2010/7/28 Frank Murphy :
On 28/07/10 13:52, Mike McGrath wrote:
<snip> Maybe as firefox4 available in > updates-testing, but certainly not a core default package.
+1
-- Regards,
This is extremely complicated which means we can't push any xulrunner related packages to stable for a long time even for a security issue.
...and we come back to my suggestion of enabling having multiple versions of the same package in updates-testing.
Orcan
On Wed, 2010-07-28 at 09:41 -0400, Orcan Ogetbil wrote:
On Wed, Jul 28, 2010 at 9:28 AM, Chen Lei wrote:
2010/7/28 Frank Murphy :
On 28/07/10 13:52, Mike McGrath wrote:
<snip> Maybe as firefox4 available in > updates-testing, but certainly not a core default package.
+1
-- Regards,
This is extremely complicated which means we can't push any xulrunner related packages to stable for a long time even for a security issue.
...and we come back to my suggestion of enabling having multiple versions of the same package in updates-testing.
...or we come back to how updates-testing is not a backports repo, and if we want to have a backports repo, we should make a backports repo. =)
On 28/07/2010 14:52, Mike McGrath wrote:
In my opinion including software that even upstream says is not ready is for a distribution that's "lost their way". We can still be a leading distribution and not include pre-release software. Especially pre-release software that's not only in our critical path, but also something that almost all of us use every day.
I agree, but doesn't that mean that Firefox 4.0 won't be available in F14 at all and will only be in F15? I think it would be a huge drawback for Fedora 14.
Florent
On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote:
On 28/07/2010 14:52, Mike McGrath wrote:
In my opinion including software that even upstream says is not ready is for a distribution that's "lost their way". We can still be a leading distribution and not include pre-release software. Especially pre-release software that's not only in our critical path, but also something that almost all of us use every day.
I agree, but doesn't that mean that Firefox 4.0 won't be available in F14 at all and will only be in F15? I think it would be a huge drawback for Fedora 14.
It would be huge if there people who can't live without it didn't have any other way of getting it than having it pre-packaged. I think Firefox 4 looks to be fantastic, but the truth is that people only have to wait a few months for a release with it pre-packaged, if they're not able to add it on their own.
On Wed, 2010-07-28 at 11:37 -0400, Paul W. Frields wrote:
On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote:
On 28/07/2010 14:52, Mike McGrath wrote:
In my opinion including software that even upstream says is not ready is for a distribution that's "lost their way". We can still be a leading distribution and not include pre-release software. Especially pre-release software that's not only in our critical path, but also something that almost all of us use every day.
I agree, but doesn't that mean that Firefox 4.0 won't be available in F14 at all and will only be in F15? I think it would be a huge drawback for Fedora 14.
It would be huge if there people who can't live without it didn't have any other way of getting it than having it pre-packaged. I think Firefox 4 looks to be fantastic, but the truth is that people only have to wait a few months for a release with it pre-packaged, if they're not able to add it on their own.
I'd rather we provide them a package than have people going out and installing software from third-party sources (yes, mozilla.org is hardly Evil, but it sets a bad precedent). I really don't see much of a reason we can't ship it as a post-release update. We'd probably want to do that in the end anyway, because Mozilla tends to stop security supporting old branches anyway; it's certainly plausible that they stop supporting 3.x during F14's support lifetime.
Again, I never know where to reply in these long threads. ;)
Personally, I would suggest we let people who are involved with upstream and follow development and handle bugs for firefox decide this.
We could call them our "firefox package maintainers". ;)
So, this thread serves as a way to let them know some people are interested in 4.0 and would love to see it, but some think it shouldn't be at the cost of too much loss of stability.
So, is there any further information we can gain/provide from continuing this thread?
kevin
On 07/28/2010 01:10 PM, Adam Williamson wrote:
On Wed, 2010-07-28 at 11:37 -0400, Paul W. Frields wrote:
On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote:
On 28/07/2010 14:52, Mike McGrath wrote:
In my opinion including software that even upstream says is not ready is for a distribution that's "lost their way". We can still be a leading distribution and not include pre-release software. Especially pre-release software that's not only in our critical path, but also something that almost all of us use every day.
I agree, but doesn't that mean that Firefox 4.0 won't be available in F14 at all and will only be in F15? I think it would be a huge drawback for Fedora 14.
It would be huge if there people who can't live without it didn't have any other way of getting it than having it pre-packaged. I think Firefox 4 looks to be fantastic, but the truth is that people only have to wait a few months for a release with it pre-packaged, if they're not able to add it on their own.
I'd rather we provide them a package than have people going out and installing software from third-party sources (yes, mozilla.org is hardly Evil, but it sets a bad precedent). I really don't see much of a reason we can't ship it as a post-release update. We'd probably want to do that in the end anyway, because Mozilla tends to stop security supporting old branches anyway; it's certainly plausible that they stop supporting 3.x during F14's support lifetime.
Just because it isn't in the F14 repo doesn't mean it won't be available to people who really want a packaged version earlier - look at spot's chromium packages, for example. And I really expect the F14-F15 time frame to be a very similar situation with Firefox - just because it's released doesn't mean there isn't some time to wait before it's really shippable. 6 months won't be the end of the world, especially if it's added to an add-on repo someplace so people can get it if they really want something other than ff3.
On Wed, 28 Jul 2010, Peter Jones wrote:
On 07/28/2010 01:10 PM, Adam Williamson wrote:
On Wed, 2010-07-28 at 11:37 -0400, Paul W. Frields wrote:
On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote:
On 28/07/2010 14:52, Mike McGrath wrote:
In my opinion including software that even upstream says is not ready is for a distribution that's "lost their way". We can still be a leading distribution and not include pre-release software. Especially pre-release software that's not only in our critical path, but also something that almost all of us use every day.
I agree, but doesn't that mean that Firefox 4.0 won't be available in F14 at all and will only be in F15? I think it would be a huge drawback for Fedora 14.
It would be huge if there people who can't live without it didn't have any other way of getting it than having it pre-packaged. I think Firefox 4 looks to be fantastic, but the truth is that people only have to wait a few months for a release with it pre-packaged, if they're not able to add it on their own.
I'd rather we provide them a package than have people going out and installing software from third-party sources (yes, mozilla.org is hardly Evil, but it sets a bad precedent). I really don't see much of a reason we can't ship it as a post-release update. We'd probably want to do that in the end anyway, because Mozilla tends to stop security supporting old branches anyway; it's certainly plausible that they stop supporting 3.x during F14's support lifetime.
Just because it isn't in the F14 repo doesn't mean it won't be available to people who really want a packaged version earlier - look at spot's chromium packages, for example. And I really expect the F14-F15 time frame to be a very similar situation with Firefox - just because it's released doesn't mean there isn't some time to wait before it's really shippable. 6 months won't be the end of the world, especially if it's added to an add-on repo someplace so people can get it if they really want something other than ff3.
Perhaps it's time to figure out how to make things like Tom's chromium more official. Find actual hosting/mirroring for that stuff, make a clear path to get people to it but also letting them know "hey, your milage may vary".
-Mike
On 07/28/2010 02:25 PM, Mike McGrath wrote:
On Wed, 28 Jul 2010, Peter Jones wrote:
On 07/28/2010 01:10 PM, Adam Williamson wrote:
On Wed, 2010-07-28 at 11:37 -0400, Paul W. Frields wrote:
On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote:
On 28/07/2010 14:52, Mike McGrath wrote:
In my opinion including software that even upstream says is not ready is for a distribution that's "lost their way". We can still be a leading distribution and not include pre-release software. Especially pre-release software that's not only in our critical path, but also something that almost all of us use every day.
I agree, but doesn't that mean that Firefox 4.0 won't be available in F14 at all and will only be in F15? I think it would be a huge drawback for Fedora 14.
It would be huge if there people who can't live without it didn't have any other way of getting it than having it pre-packaged. I think Firefox 4 looks to be fantastic, but the truth is that people only have to wait a few months for a release with it pre-packaged, if they're not able to add it on their own.
I'd rather we provide them a package than have people going out and installing software from third-party sources (yes, mozilla.org is hardly Evil, but it sets a bad precedent). I really don't see much of a reason we can't ship it as a post-release update. We'd probably want to do that in the end anyway, because Mozilla tends to stop security supporting old branches anyway; it's certainly plausible that they stop supporting 3.x during F14's support lifetime.
Just because it isn't in the F14 repo doesn't mean it won't be available to people who really want a packaged version earlier - look at spot's chromium packages, for example. And I really expect the F14-F15 time frame to be a very similar situation with Firefox - just because it's released doesn't mean there isn't some time to wait before it's really shippable. 6 months won't be the end of the world, especially if it's added to an add-on repo someplace so people can get it if they really want something other than ff3.
Perhaps it's time to figure out how to make things like Tom's chromium more official. Find actual hosting/mirroring for that stuff, make a clear path to get people to it but also letting them know "hey, your milage may vary".
I would really like to see kopers happen, yes. That'd be great.
On Wed, 28 Jul 2010, Peter Jones wrote:
On 07/28/2010 02:25 PM, Mike McGrath wrote:
On Wed, 28 Jul 2010, Peter Jones wrote:
On 07/28/2010 01:10 PM, Adam Williamson wrote:
On Wed, 2010-07-28 at 11:37 -0400, Paul W. Frields wrote:
On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote:
On 28/07/2010 14:52, Mike McGrath wrote: > In my opinion including software that even upstream says is not ready is > for a distribution that's "lost their way". We can still be a leading > distribution and not include pre-release software. Especially pre-release > software that's not only in our critical path, but also something that > almost all of us use every day. I agree, but doesn't that mean that Firefox 4.0 won't be available in F14 at all and will only be in F15? I think it would be a huge drawback for Fedora 14.
It would be huge if there people who can't live without it didn't have any other way of getting it than having it pre-packaged. I think Firefox 4 looks to be fantastic, but the truth is that people only have to wait a few months for a release with it pre-packaged, if they're not able to add it on their own.
I'd rather we provide them a package than have people going out and installing software from third-party sources (yes, mozilla.org is hardly Evil, but it sets a bad precedent). I really don't see much of a reason we can't ship it as a post-release update. We'd probably want to do that in the end anyway, because Mozilla tends to stop security supporting old branches anyway; it's certainly plausible that they stop supporting 3.x during F14's support lifetime.
Just because it isn't in the F14 repo doesn't mean it won't be available to people who really want a packaged version earlier - look at spot's chromium packages, for example. And I really expect the F14-F15 time frame to be a very similar situation with Firefox - just because it's released doesn't mean there isn't some time to wait before it's really shippable. 6 months won't be the end of the world, especially if it's added to an add-on repo someplace so people can get it if they really want something other than ff3.
Perhaps it's time to figure out how to make things like Tom's chromium more official. Find actual hosting/mirroring for that stuff, make a clear path to get people to it but also letting them know "hey, your milage may vary".
I would really like to see kopers happen, yes. That'd be great.
Maybe I'm mistaken, I thought kopers was just for building. Does it encompass hosting, distribution and such?
-Mike
On Wed, Jul 28, 2010 at 8:42 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Wed, 28 Jul 2010, Peter Jones wrote:
On 07/28/2010 02:25 PM, Mike McGrath wrote:
On Wed, 28 Jul 2010, Peter Jones wrote:
On 07/28/2010 01:10 PM, Adam Williamson wrote:
On Wed, 2010-07-28 at 11:37 -0400, Paul W. Frields wrote:
On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote: > On 28/07/2010 14:52, Mike McGrath wrote: >> In my opinion including software that even upstream says is not ready is >> for a distribution that's "lost their way". We can still be a leading >> distribution and not include pre-release software. Especially pre-release >> software that's not only in our critical path, but also something that >> almost all of us use every day. > I agree, but doesn't that mean that Firefox 4.0 won't be available in > F14 at all and will only be in F15? > I think it would be a huge drawback for Fedora 14.
It would be huge if there people who can't live without it didn't have any other way of getting it than having it pre-packaged. I think Firefox 4 looks to be fantastic, but the truth is that people only have to wait a few months for a release with it pre-packaged, if they're not able to add it on their own.
I'd rather we provide them a package than have people going out and installing software from third-party sources (yes, mozilla.org is hardly Evil, but it sets a bad precedent). I really don't see much of a reason we can't ship it as a post-release update. We'd probably want to do that in the end anyway, because Mozilla tends to stop security supporting old branches anyway; it's certainly plausible that they stop supporting 3.x during F14's support lifetime.
Just because it isn't in the F14 repo doesn't mean it won't be available to people who really want a packaged version earlier - look at spot's chromium packages, for example. And I really expect the F14-F15 time frame to be a very similar situation with Firefox - just because it's released doesn't mean there isn't some time to wait before it's really shippable. 6 months won't be the end of the world, especially if it's added to an add-on repo someplace so people can get it if they really want something other than ff3.
Perhaps it's time to figure out how to make things like Tom's chromium more official. Find actual hosting/mirroring for that stuff, make a clear path to get people to it but also letting them know "hey, your milage may vary".
I would really like to see kopers happen, yes. That'd be great.
Maybe I'm mistaken, I thought kopers was just for building. Does it encompass hosting, distribution and such?
IIRC yes, it just needs to happen .... someday ;)
On Wed, 28 Jul 2010, drago01 wrote:
On Wed, Jul 28, 2010 at 8:42 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Wed, 28 Jul 2010, Peter Jones wrote:
On 07/28/2010 02:25 PM, Mike McGrath wrote:
On Wed, 28 Jul 2010, Peter Jones wrote:
On 07/28/2010 01:10 PM, Adam Williamson wrote:
On Wed, 2010-07-28 at 11:37 -0400, Paul W. Frields wrote: > On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote: >> On 28/07/2010 14:52, Mike McGrath wrote: >>> In my opinion including software that even upstream says is not ready is >>> for a distribution that's "lost their way". We can still be a leading >>> distribution and not include pre-release software. Especially pre-release >>> software that's not only in our critical path, but also something that >>> almost all of us use every day. >> I agree, but doesn't that mean that Firefox 4.0 won't be available in >> F14 at all and will only be in F15? >> I think it would be a huge drawback for Fedora 14. > > It would be huge if there people who can't live without it didn't have > any other way of getting it than having it pre-packaged. I think > Firefox 4 looks to be fantastic, but the truth is that people only > have to wait a few months for a release with it pre-packaged, if > they're not able to add it on their own.
I'd rather we provide them a package than have people going out and installing software from third-party sources (yes, mozilla.org is hardly Evil, but it sets a bad precedent). I really don't see much of a reason we can't ship it as a post-release update. We'd probably want to do that in the end anyway, because Mozilla tends to stop security supporting old branches anyway; it's certainly plausible that they stop supporting 3.x during F14's support lifetime.
Just because it isn't in the F14 repo doesn't mean it won't be available to people who really want a packaged version earlier - look at spot's chromium packages, for example. And I really expect the F14-F15 time frame to be a very similar situation with Firefox - just because it's released doesn't mean there isn't some time to wait before it's really shippable. 6 months won't be the end of the world, especially if it's added to an add-on repo someplace so people can get it if they really want something other than ff3.
Perhaps it's time to figure out how to make things like Tom's chromium more official. Find actual hosting/mirroring for that stuff, make a clear path to get people to it but also letting them know "hey, your milage may vary".
I would really like to see kopers happen, yes. That'd be great.
Maybe I'm mistaken, I thought kopers was just for building. Does it encompass hosting, distribution and such?
IIRC yes, it just needs to happen .... someday ;)
Maybe baby steps? Small incremental changes. Sure some features will be missing that kopers will provide. But perhaps we could just create a Fedora-13-devel tag in koji, push it to it's own repo or to individual fedora-13-spot / fedora-13-mmcgrath repos. One that doesn't migrate to updates-testing or updates. It just sits there.
We're going to need something like this when kopers comes out anyway right? I figure smaller steps towards that goal is better then one big one.
-Mike
On Wed, Jul 28, 2010 at 9:12 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Wed, 28 Jul 2010, drago01 wrote:
On Wed, Jul 28, 2010 at 8:42 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Wed, 28 Jul 2010, Peter Jones wrote:
On 07/28/2010 02:25 PM, Mike McGrath wrote:
On Wed, 28 Jul 2010, Peter Jones wrote:
On 07/28/2010 01:10 PM, Adam Williamson wrote: > On Wed, 2010-07-28 at 11:37 -0400, Paul W. Frields wrote: >> On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote: >>> On 28/07/2010 14:52, Mike McGrath wrote: >>>> In my opinion including software that even upstream says is not ready is >>>> for a distribution that's "lost their way". We can still be a leading >>>> distribution and not include pre-release software. Especially pre-release >>>> software that's not only in our critical path, but also something that >>>> almost all of us use every day. >>> I agree, but doesn't that mean that Firefox 4.0 won't be available in >>> F14 at all and will only be in F15? >>> I think it would be a huge drawback for Fedora 14. >> >> It would be huge if there people who can't live without it didn't have >> any other way of getting it than having it pre-packaged. I think >> Firefox 4 looks to be fantastic, but the truth is that people only >> have to wait a few months for a release with it pre-packaged, if >> they're not able to add it on their own. > > I'd rather we provide them a package than have people going out and > installing software from third-party sources (yes, mozilla.org is hardly > Evil, but it sets a bad precedent). I really don't see much of a reason > we can't ship it as a post-release update. We'd probably want to do that > in the end anyway, because Mozilla tends to stop security supporting old > branches anyway; it's certainly plausible that they stop supporting 3.x > during F14's support lifetime.
Just because it isn't in the F14 repo doesn't mean it won't be available to people who really want a packaged version earlier - look at spot's chromium packages, for example. And I really expect the F14-F15 time frame to be a very similar situation with Firefox - just because it's released doesn't mean there isn't some time to wait before it's really shippable. 6 months won't be the end of the world, especially if it's added to an add-on repo someplace so people can get it if they really want something other than ff3.
Perhaps it's time to figure out how to make things like Tom's chromium more official. Find actual hosting/mirroring for that stuff, make a clear path to get people to it but also letting them know "hey, your milage may vary".
I would really like to see kopers happen, yes. That'd be great.
Maybe I'm mistaken, I thought kopers was just for building. Does it encompass hosting, distribution and such?
IIRC yes, it just needs to happen .... someday ;)
Maybe baby steps? Small incremental changes. Sure some features will be missing that kopers will provide. But perhaps we could just create a Fedora-13-devel tag in koji, push it to it's own repo or to individual fedora-13-spot / fedora-13-mmcgrath repos. One that doesn't migrate to updates-testing or updates. It just sits there.
We're going to need something like this when kopers comes out anyway right? I figure smaller steps towards that goal is better then one big one.
No disagreement here ... in fact this is a not really a "baby step" but "have something usable and start from there" which makes a lot of sense.
On Wed, Jul 28, 2010 at 2:16 PM, drago01 drago01@gmail.com wrote:
No disagreement here ... in fact this is a not really a "baby step" but "have something usable and start from there" which makes a lot of sense.
As much as I want Chromium to be in Fedora, I don't want it in the repository if it is going to have crippled HTML5 support. It will make Fedora look even worse than it already does for multimedia support. As for Firefox 4, I'd rather have a beta included in Fedora than an older version. However, Firefox 4 is tracked for an October 15 release. As far as I'm aware, Fedora 14 is still tracked for an October 26. Even if Fedora 14's release schedule doesn't slip (and we know it will, there's not been a release in a long time that Fedora hasn't slipped), the final version of Firefox 4 should be ready in time for final release of Fedora 14.
On 07/28/2010 04:47 PM, Conan Kudo (ニール・ゴンパ) wrote:
On Wed, Jul 28, 2010 at 2:16 PM, drago01 <drago01@gmail.com mailto:drago01@gmail.com> wrote:
No disagreement here ... in fact this is a not really a "baby step" but "have something usable and start from there" which makes a lot of sense.As much as I want Chromium to be in Fedora, I don't want it in the repository if it is going to have crippled HTML5 support.
To be fair, Chromium uses ffmpeg for its HTML5. If you have ffmpeg installed (with my Chromium builds), then you get HTML5 support. If you don't, well, you don't. Chromium isn't "crippled". Fedora just can't include ffmpeg for obvious reasons, and Chromium has chosen not to use the native libv8 code.
~spot
On Wed, 2010-07-28 at 16:58 -0400, Tom "spot" Callaway wrote:
On 07/28/2010 04:47 PM, Conan Kudo (ニール・ゴンパ) wrote:
On Wed, Jul 28, 2010 at 2:16 PM, drago01 <drago01@gmail.com mailto:drago01@gmail.com> wrote:
No disagreement here ... in fact this is a not really a "baby step" but "have something usable and start from there" which makes a lot of sense.As much as I want Chromium to be in Fedora, I don't want it in the repository if it is going to have crippled HTML5 support.
To be fair, Chromium uses ffmpeg for its HTML5. If you have ffmpeg installed (with my Chromium builds), then you get HTML5 support. If you don't, well, you don't. Chromium isn't "crippled". Fedora just can't include ffmpeg for obvious reasons, and Chromium has chosen not to use the native libv8 code.
Speaking of which, is there any chance to split ffmpeg into free (which could be included in fedora) and nonfree part? IIRC we've done something like that with xine-lib-extras and gst-plugins-bad in the past...
Martin
On Wed, 2010-07-28 at 23:28 +0200, Martin Sourada wrote:
Speaking of which, is there any chance to split ffmpeg into free (which could be included in fedora) and nonfree part? IIRC we've done something like that with xine-lib-extras and gst-plugins-bad in the past...
ffmpeg, unfortunately, isn't set up to be modularised like this; you can't build an ffmpeg-free with the free codecs and an ffmpeg-patented with the patented ones and have them co-exist nicely. So an ffmpeg build with almost all the codecs ripped out in the Fedora repos would 'compete' with the full build in That Other Repo, not complement it, and the way the two repos are set up, it would be tricky to have a handicapped build in the Fedora repo and a full build in That Other One and have it easy for people to pick the one from That Other Repo (since Other Repo packages use the same disttag as Fedora ones).
On Wed, Jul 28, 2010 at 4:38 PM, Adam Williamson awilliam@redhat.comwrote:
On Wed, 2010-07-28 at 23:28 +0200, Martin Sourada wrote:
Speaking of which, is there any chance to split ffmpeg into free (which could be included in fedora) and nonfree part? IIRC we've done something like that with xine-lib-extras and gst-plugins-bad in the past...
ffmpeg, unfortunately, isn't set up to be modularised like this; you can't build an ffmpeg-free with the free codecs and an ffmpeg-patented with the patented ones and have them co-exist nicely. So an ffmpeg build with almost all the codecs ripped out in the Fedora repos would 'compete' with the full build in That Other Repo, not complement it, and the way the two repos are set up, it would be tricky to have a handicapped build in the Fedora repo and a full build in That Other One and have it easy for people to pick the one from That Other Repo (since Other Repo packages use the same disttag as Fedora ones). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
That is assuming that "the other repo" uses the same name as Fedora's. Fedora could call it ffmpeg-free, and "the other repo" could call it ffmpeg-nonfree, and have the nonfree one obsolete the free one. Simple fix, I think.
On Wed, Jul 28, 2010 at 17:00:01 -0500, "Conan Kudo (ニール・ゴンパ)" ngompa13@gmail.com wrote:
On Wed, Jul 28, 2010 at 4:38 PM, Adam Williamson awilliam@redhat.comwrote:
That is assuming that "the other repo" uses the same name as Fedora's. Fedora could call it ffmpeg-free, and "the other repo" could call it ffmpeg-nonfree, and have the nonfree one obsolete the free one. Simple fix, I think.
"conflicts" would probably be more appropriate than "obsoletes".
On 07/28/2010 11:13 PM, Bruno Wolff III wrote:
On Wed, Jul 28, 2010 at 17:00:01 -0500, "Conan Kudo (ニール・ゴンパ)"ngompa13@gmail.com wrote:
On Wed, Jul 28, 2010 at 4:38 PM, Adam Williamsonawilliam@redhat.comwrote:
That is assuming that "the other repo" uses the same name as Fedora's. Fedora could call it ffmpeg-free, and "the other repo" could call it ffmpeg-nonfree, and have the nonfree one obsolete the free one. Simple fix, I think.
"conflicts" would probably be more appropriate than "obsoletes".
You could also relocate and rename the fedora one and use alternatives.
This is probably slightly cleaner, and means that The Other Repo(s) don't need to change their packages at all for it to work.
But, as others have noted, this is the easy part.
Splitting out the free parts and maintaining them is the hard bit.
2010/7/29 Conan Kudo (ニール・ゴンパ) ngompa13@gmail.com:
On Wed, Jul 28, 2010 at 4:38 PM, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2010-07-28 at 23:28 +0200, Martin Sourada wrote:
Speaking of which, is there any chance to split ffmpeg into free (which could be included in fedora) and nonfree part? IIRC we've done something like that with xine-lib-extras and gst-plugins-bad in the past...
ffmpeg, unfortunately, isn't set up to be modularised like this; you can't build an ffmpeg-free with the free codecs and an ffmpeg-patented with the patented ones and have them co-exist nicely. So an ffmpeg build with almost all the codecs ripped out in the Fedora repos would 'compete' with the full build in That Other Repo, not complement it, and the way the two repos are set up, it would be tricky to have a handicapped build in the Fedora repo and a full build in That Other One and have it easy for people to pick the one from That Other Repo (since Other Repo packages use the same disttag as Fedora ones). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
That is assuming that "the other repo" uses the same name as Fedora's. Fedora could call it ffmpeg-free, and "the other repo" could call it ffmpeg-nonfree, and have the nonfree one obsolete the free one. Simple fix, I think. --
The issue is who can split the patent free codecs from ffmepg? Obviously, ffmpeg upstream don't like this idea, maintaining a fedora specfic ffmepg isn't a easy job.
Regards, Chen Lei
On Wed, Jul 28, 2010 at 4:58 PM, Tom "spot" Callaway wrote:
Fedora just can't include ffmpeg for obvious reasons,
How many more years are we talking about for ffmpeg?
Speaking of which, when can we include a mp3 decoder library in Fedora? I heard that all mp3 decoding patents will expire in 2012. There are a few encoding patents that will expire in 2015-16.
Are we going to wait until all mp3 encoders become patent-free to include decoders in Fedora? (Same question applies to video codecs.)
Orcan
Orcan Ogetbil (oget.fedora@gmail.com) said:
On Wed, Jul 28, 2010 at 4:58 PM, Tom "spot" Callaway wrote:
Fedora just can't include ffmpeg for obvious reasons,
How many more years are we talking about for ffmpeg?
Given that ffmpeg continues to add new codecs (AFAIK), approximately MAXINT?
Bill
On 07/28/2010 06:11 PM, Orcan Ogetbil wrote:
On Wed, Jul 28, 2010 at 4:58 PM, Tom "spot" Callaway wrote:
Fedora just can't include ffmpeg for obvious reasons,
How many more years are we talking about for ffmpeg?
Speaking of which, when can we include a mp3 decoder library in Fedora? I heard that all mp3 decoding patents will expire in 2012. There are a few encoding patents that will expire in 2015-16.
Are we going to wait until all mp3 encoders become patent-free to include decoders in Fedora? (Same question applies to video codecs.)
Video is much much harder to discuss. At least for mp3, the plan is to revisit the space in 2012 and see what the possibilities are.
~spot
So will Chromium get into the third-party repos like RPM Fusion? RPM Fusion has ffmpeg packages.
The problem is that RPM Fusion needs much more time and more resources to build such a big package.
On Thu, Jul 29, 2010 at 4:58 AM, Tom "spot" Callaway tcallawa@redhat.comwrote:
On 07/28/2010 04:47 PM, Conan Kudo (ニール・ゴンパ) wrote:
On Wed, Jul 28, 2010 at 2:16 PM, drago01 <drago01@gmail.com mailto:drago01@gmail.com> wrote:
No disagreement here ... in fact this is a not really a "baby step" but "have something usable and start from there" which makes a lot of sense.As much as I want Chromium to be in Fedora, I don't want it in the repository if it is going to have crippled HTML5 support.
To be fair, Chromium uses ffmpeg for its HTML5. If you have ffmpeg installed (with my Chromium builds), then you get HTML5 support. If you don't, well, you don't. Chromium isn't "crippled". Fedora just can't include ffmpeg for obvious reasons, and Chromium has chosen not to use the native libv8 code.
~spot
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 07/29/2010 12:01 PM, Liang Suilong wrote:
So will Chromium get into the third-party repos like RPM Fusion? RPM Fusion has ffmpeg packages.
The problem is that RPM Fusion needs much more time and more resources to build such a big package.
Since ffmpeg can be runtime detected by Chromium, that is not a reason to put it in a third party repo. There are other reasons why Chromium is not in the repo. Details at
http://fedoraproject.org/wiki/Chromium
Rahul
On Wed, 2010-07-28 at 14:12 -0500, Mike McGrath wrote:
Maybe baby steps? Small incremental changes. Sure some features will be missing that kopers will provide. But perhaps we could just create a Fedora-13-devel tag in koji, push it to it's own repo or to individual fedora-13-spot / fedora-13-mmcgrath repos. One that doesn't migrate to updates-testing or updates. It just sits there.
We're going to need something like this when kopers comes out anyway right? I figure smaller steps towards that goal is better then one big one.
Toshio and I have talked about the targets of coprs and what the problems are we're trying to solve. Here are the problems:
1. I want to build these pkgs which have small patches to what's in fedora but I don't have the archs to build them on :solved by scratch builds in koji
2. I want to build these pkgs which have patches/changes to what's in fedora but I don't have the machines to build them on :solved by scratch builds in koji
3. I want to build these pkgs which have patches/changes to what's in fedora but I don't have a place to host them :provided, but not explicitly encouraged or endorsed by fedorapeople.org
4. I want to build these pkgs and they have new deps on pkgs which are not in fedora and I need to chain-build them from arbitrary :not provided by anything currently since you cannot build pkgs in koji with arbitrary deps from arbitrary repos.
Item 4 is the main point that has been the big ticket item that things like Canonical's PPAs have hit.
Since the other 3 had some relatively-possible solution Toshio and I started down the path of solving #4 since that was the only explicitly unsolved problem.
Now - I think it would be perfectly reasonable for us to come up with a better/more official solution for #3. It's pretty simple to implement. We could setup a: http://repos.fedoraproject.org/$username/reponame/
it would be as simple as a subdir/path on the current fedorapeople (but using the repos hostname so we could move it later if needs demanded it)
so - in theory we could have repos like:
http://repos.fp.o/skvidal/func-future/ or http://repos.fp.o/func-group/func-future/
and extend out from there.
then when item #4 is fully solved we could move this hierarchy to be used by coprs.
It's a good place to start.
-sv
On Wed, Jul 28, 2010 at 9:37 PM, seth vidal skvidal@fedoraproject.org wrote:
On Wed, 2010-07-28 at 14:12 -0500, Mike McGrath wrote:
Maybe baby steps? Small incremental changes. Sure some features will be missing that kopers will provide. But perhaps we could just create a Fedora-13-devel tag in koji, push it to it's own repo or to individual fedora-13-spot / fedora-13-mmcgrath repos. One that doesn't migrate to updates-testing or updates. It just sits there.
We're going to need something like this when kopers comes out anyway right? I figure smaller steps towards that goal is better then one big one.
Toshio and I have talked about the targets of coprs and what the problems are we're trying to solve. Here are the problems:
- I want to build these pkgs which have small patches to what's in
fedora but I don't have the archs to build them on :solved by scratch builds in koji
- I want to build these pkgs which have patches/changes to what's in
fedora but I don't have the machines to build them on :solved by scratch builds in koji
- I want to build these pkgs which have patches/changes to what's in
fedora but I don't have a place to host them :provided, but not explicitly encouraged or endorsed by fedorapeople.org
- I want to build these pkgs and they have new deps on pkgs which are
not in fedora and I need to chain-build them from arbitrary :not provided by anything currently since you cannot build pkgs in koji with arbitrary deps from arbitrary repos.
5. Some easy way to enable/disable such repos other than messing with config files?
On Wed, 2010-07-28 at 21:49 +0200, drago01 wrote:
On Wed, Jul 28, 2010 at 9:37 PM, seth vidal skvidal@fedoraproject.org wrote:
On Wed, 2010-07-28 at 14:12 -0500, Mike McGrath wrote:
Maybe baby steps? Small incremental changes. Sure some features will be missing that kopers will provide. But perhaps we could just create a Fedora-13-devel tag in koji, push it to it's own repo or to individual fedora-13-spot / fedora-13-mmcgrath repos. One that doesn't migrate to updates-testing or updates. It just sits there.
We're going to need something like this when kopers comes out anyway right? I figure smaller steps towards that goal is better then one big one.
Toshio and I have talked about the targets of coprs and what the problems are we're trying to solve. Here are the problems:
- I want to build these pkgs which have small patches to what's in
fedora but I don't have the archs to build them on :solved by scratch builds in koji
- I want to build these pkgs which have patches/changes to what's in
fedora but I don't have the machines to build them on :solved by scratch builds in koji
- I want to build these pkgs which have patches/changes to what's in
fedora but I don't have a place to host them :provided, but not explicitly encouraged or endorsed by fedorapeople.org
- I want to build these pkgs and they have new deps on pkgs which are
not in fedora and I need to chain-build them from arbitrary :not provided by anything currently since you cannot build pkgs in koji with arbitrary deps from arbitrary repos.
- Some easy way to enable/disable such repos other than messing with
config files?
yum-config-manager --enable repo1 repo2 repo3
-sv
On Wed, Jul 28, 2010 at 9:51 PM, seth vidal skvidal@fedoraproject.org wrote:
On Wed, 2010-07-28 at 21:49 +0200, drago01 wrote:
On Wed, Jul 28, 2010 at 9:37 PM, seth vidal skvidal@fedoraproject.org wrote:
On Wed, 2010-07-28 at 14:12 -0500, Mike McGrath wrote:
Maybe baby steps? Small incremental changes. Sure some features will be missing that kopers will provide. But perhaps we could just create a Fedora-13-devel tag in koji, push it to it's own repo or to individual fedora-13-spot / fedora-13-mmcgrath repos. One that doesn't migrate to updates-testing or updates. It just sits there.
We're going to need something like this when kopers comes out anyway right? I figure smaller steps towards that goal is better then one big one.
Toshio and I have talked about the targets of coprs and what the problems are we're trying to solve. Here are the problems:
- I want to build these pkgs which have small patches to what's in
fedora but I don't have the archs to build them on :solved by scratch builds in koji
- I want to build these pkgs which have patches/changes to what's in
fedora but I don't have the machines to build them on :solved by scratch builds in koji
- I want to build these pkgs which have patches/changes to what's in
fedora but I don't have a place to host them :provided, but not explicitly encouraged or endorsed by fedorapeople.org
- I want to build these pkgs and they have new deps on pkgs which are
not in fedora and I need to chain-build them from arbitrary :not provided by anything currently since you cannot build pkgs in koji with arbitrary deps from arbitrary repos.
- Some easy way to enable/disable such repos other than messing with
config files?
yum-config-manager --enable repo1 repo2 repo3
My wording might not have been the best with enable I actually meant install.
something like copers --enable foo copers --disable foo
which would download and set up the repo.
(Shouldn't be really hard to do though)
On 28/07/10 20:49, drago01 wrote:
- Some easy way to enable/disable such repos other than messing with
config files?
gnome-packagekit-extra tick what you need.
On Wed, 2010-07-28 at 15:37 -0400, seth vidal wrote:
On Wed, 2010-07-28 at 14:12 -0500, Mike McGrath wrote:
Maybe baby steps? Small incremental changes. Sure some features will be missing that kopers will provide. But perhaps we could just create a Fedora-13-devel tag in koji, push it to it's own repo or to individual fedora-13-spot / fedora-13-mmcgrath repos. One that doesn't migrate to updates-testing or updates. It just sits there.
We're going to need something like this when kopers comes out anyway right? I figure smaller steps towards that goal is better then one big one.
Toshio and I have talked about the targets of coprs and what the problems are we're trying to solve. Here are the problems:
- I want to build these pkgs which have small patches to what's in
fedora but I don't have the archs to build them on :solved by scratch builds in koji
- I want to build these pkgs which have patches/changes to what's in
fedora but I don't have the machines to build them on :solved by scratch builds in koji
- I want to build these pkgs which have patches/changes to what's in
fedora but I don't have a place to host them :provided, but not explicitly encouraged or endorsed by fedorapeople.org
- I want to build these pkgs and they have new deps on pkgs which are
not in fedora and I need to chain-build them from arbitrary :not provided by anything currently since you cannot build pkgs in koji with arbitrary deps from arbitrary repos.
Item 4 is the main point that has been the big ticket item that things like Canonical's PPAs have hit.
They also hit the Staples Easy Button about 1000 times. If there's a case to be made that this should be easy to do, then we should add tolling to common/Makefile to:
1) make an srpm 2) build it as a scratch build in koji 3) automatically download the built packages 4) scp them to your fedorapeople account 5) run createrepo remotely on the fp account 6) generate a yum .repo file for the repo and print out a link to it or something
ie, enable doing this with *one* command in the dist-cvs/git checkout, like 'make ppa' or 'fedpkg ppa' that will do all these steps for you.
Dan
Since the other 3 had some relatively-possible solution Toshio and I started down the path of solving #4 since that was the only explicitly unsolved problem.
Now - I think it would be perfectly reasonable for us to come up with a better/more official solution for #3. It's pretty simple to implement. We could setup a: http://repos.fedoraproject.org/$username/reponame/
it would be as simple as a subdir/path on the current fedorapeople (but using the repos hostname so we could move it later if needs demanded it)
so - in theory we could have repos like:
http://repos.fp.o/skvidal/func-future/ or http://repos.fp.o/func-group/func-future/
and extend out from there.
then when item #4 is fully solved we could move this hierarchy to be used by coprs.
It's a good place to start.
-sv
On Wed, 2010-07-28 at 15:10 -0700, Dan Williams wrote:
Item 4 is the main point that has been the big ticket item that things like Canonical's PPAs have hit.
They also hit the Staples Easy Button about 1000 times. If there's a case to be made that this should be easy to do, then we should add tolling to common/Makefile to:
- make an srpm
check
- build it as a scratch build in koji
check
- automatically download the built packages
check
3.5) Sign the pkgs with your (or someone's) gpg key not-so-check
- scp them to your fedorapeople account
unchecked
- run createrepo remotely on the fp account
createrepo is not fp, on purpose, this could be changed - but it's better to run it locally, if only b/c of whatever arbitrary arguments you may want to add to it - not to mention the memory constraints.
- generate a yum .repo file for the repo and print out a link to it or
something
sure. - though we'd be better off generating an rpm which contains the .repo file - so people could 'install' the repositories in the strictest sense.
-sv
It looks that copr will come soon. I have a question about it.
Could we add some dependencies from other copr repo? Fedora official repo sometimes could not offer the latest one but some packages need them.
On Thu, Jul 29, 2010 at 4:14 AM, seth vidal skvidal@fedoraproject.orgwrote:
On Wed, 2010-07-28 at 15:10 -0700, Dan Williams wrote:
Item 4 is the main point that has been the big ticket item that things like Canonical's PPAs have hit.
They also hit the Staples Easy Button about 1000 times. If there's a case to be made that this should be easy to do, then we should add tolling to common/Makefile to:
- make an srpm
check
- build it as a scratch build in koji
check
- automatically download the built packages
check3.5) Sign the pkgs with your (or someone's) gpg key not-so-check
- scp them to your fedorapeople account
unchecked
- run createrepo remotely on the fp account
createrepo is not fp, on purpose, this could be changed - but it's better to run it locally, if only b/c of whatever arbitrary arguments you may want to add to it - not to mention the memory constraints.
- generate a yum .repo file for the repo and print out a link to it or
something
sure. - though we'd be better off generating an rpm which contains the .repo file - so people could 'install' the repositories in the strictest sense.
-sv
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Jul 29, 2010 at 03:21:51PM +0800, Liang Suilong wrote:
It looks that copr will come soon. I have a question about it.
Could we add some dependencies from other copr repo? Fedora official repo sometimes could not offer the latest one but some packages need them.
yes. The idea is that when you create a copr repo you'll specify what other repositories to target. The minimum would likely be Fedora-VER + Fedora-VER-updates. In addition you will be able to specify other copr repositories that target the same Fedora-VER and possibly Fedora-VER-updates-testing (not precisely sure about that last one yet.)
-Toshio
On Thu, Jul 29, 2010 at 4:14 AM, seth vidal skvidal@fedoraproject.org wrote:
On Wed, 2010-07-28 at 15:10 -0700, Dan Williams wrote: > > Item 4 is the main point that has been the big ticket item that things > > like Canonical's PPAs have hit. > > They also hit the Staples Easy Button about 1000 times. If there's a > case to be made that this should be easy to do, then we should add > tolling to common/Makefile to: > > 1) make an srpm check > 2) build it as a scratch build in koji check > 3) automatically download the built packages check 3.5) Sign the pkgs with your (or someone's) gpg key not-so-check > 4) scp them to your fedorapeople account unchecked > 5) run createrepo remotely on the fp account createrepo is not fp, on purpose, this could be changed - but it's better to run it locally, if only b/c of whatever arbitrary arguments you may want to add to it - not to mention the memory constraints. > 6) generate a yum .repo file for the repo and print out a link to it or > something sure. - though we'd be better off generating an rpm which contains the .repo file - so people could 'install' the repositories in the strictest sense. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-- Fedora && Debian User, former Ubuntu User My Page: http://www.liangsuilong.info Fedora Project Contributor -- Packager && Ambassador https://fedoraproject.org/wiki/User:Liangsuilong
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, 28 Jul 2010, Mike McGrath wrote:
Maybe baby steps? Small incremental changes. Sure some features will be missing that kopers will provide. But perhaps we could just create a Fedora-13-devel tag in koji, push it to it's own repo or to individual fedora-13-spot / fedora-13-mmcgrath repos. One that doesn't migrate to updates-testing or updates. It just sits there.
We're going to need something like this when kopers comes out anyway right? I figure smaller steps towards that goal is better then one big one.
So I just created:
http://repos.fedorapeople.org/
Anyone want to help me test the steps and process before we announce and deploy it? Anyone already got Firefox 4 built for F13 for example? Let me know or stop by #fedora-admin on irc.freenode.net
-Mike
On 07/29/2010 05:46 PM, Mike McGrath wrote:
On Wed, 28 Jul 2010, Mike McGrath wrote:
Maybe baby steps? Small incremental changes. Sure some features will be missing that kopers will provide. But perhaps we could just create a Fedora-13-devel tag in koji, push it to it's own repo or to individual fedora-13-spot / fedora-13-mmcgrath repos. One that doesn't migrate to updates-testing or updates. It just sits there.
We're going to need something like this when kopers comes out anyway right? I figure smaller steps towards that goal is better then one big one.
So I just created:
http://repos.fedorapeople.org/
Anyone want to help me test the steps and process before we announce and deploy it? Anyone already got Firefox 4 built for F13 for example? Let me know or stop by #fedora-admin on irc.freenode.net
Mike, I'll help, since I already have chromium repos on my fedorapeople space. Let me know what I need to do to be added to the list there.
~spot
On 07/30/2010 03:16 AM, Mike McGrath wrote:
So I just created:
http://repos.fedorapeople.org/
Anyone want to help me test the steps and process before we announce and deploy it? Anyone already got Firefox 4 built for F13 for example? Let me know or stop by #fedora-admin on irc.freenode.net
Remi,
Would be nice to have Firefox 4 in there.
Rahul
Le 30/07/2010 17:10, Rahul Sundaram a écrit :
On 07/30/2010 03:16 AM, Mike McGrath wrote:
So I just created:
http://repos.fedorapeople.org/
Anyone want to help me test the steps and process before we announce and deploy it? Anyone already got Firefox 4 built for F13 for example? Let me know or stop by #fedora-admin on irc.freenode.net
Remi,
Would be nice to have Firefox 4 in there.
Of course I could push my "firefox4" build on fedorapeople.org, but my backport repository is about 12Gio (mainly mozilla stuff, lamp stack and some experimental rpm like mysql-workbench)
Could I just added something to be (a link) on the list ?
Remi
P.S. for those who don't know it, to see the content of my repo: http://rpms.famillecollet.com/
Rahul
On 07/30/2010 08:55 PM, Remi Collet wrote:
Of course I could push my "firefox4" build on fedorapeople.org, but my backport repository is about 12Gio (mainly mozilla stuff, lamp stack and some experimental rpm like mysql-workbench)
Could I just added something to be (a link) on the list ?
I don't know if you want to move the entire set of packages in there. I would recommend focusing on a few popular ones for now.
Rahul
On 07/30/2010 11:10 AM, Rahul Sundaram wrote:
On 07/30/2010 03:16 AM, Mike McGrath wrote:
So I just created:
http://repos.fedorapeople.org/
Anyone want to help me test the steps and process before we announce and deploy it? Anyone already got Firefox 4 built for F13 for example? Let me know or stop by #fedora-admin on irc.freenode.net
Remi,
Would be nice to have Firefox 4 in there.
I'm also working on a set of Firefox 4 packages (split between firefox4 and xulrunner) that more closely match the Fedora firefox packages, but are able to be installed without conflicts.
At the moment, I'm just targeting F-14.
~spot
On 07/30/2010 08:58 PM, Tom "spot" Callaway wrote:
I'm also working on a set of Firefox 4 packages (split between firefox4 and xulrunner) that more closely match the Fedora firefox packages, but are able to be installed without conflicts.
At the moment, I'm just targeting F-14.
That's really nice but I noticed that three people have their own set of repo files and different directory structure. I would prefer more standardization and a standard command by default to grab new repos like:
yum-repo-add fp:spot/chromium
Rahul
On 07/30/2010 11:33 AM, Rahul Sundaram wrote:
On 07/30/2010 08:58 PM, Tom "spot" Callaway wrote:
I'm also working on a set of Firefox 4 packages (split between firefox4 and xulrunner) that more closely match the Fedora firefox packages, but are able to be installed without conflicts.
At the moment, I'm just targeting F-14.
That's really nice but I noticed that three people have their own set of repo files and different directory structure. I would prefer more standardization and a standard command by default to grab new repos like:
yum-repo-add fp:spot/chromium
To be fair, I just moved to the format that Mike McGrath set up for repos.fedoraproject.org, so, please don't accuse me of not backing standardization. ;)
~spot
On 07/30/2010 09:06 PM, Tom "spot" Callaway wrote:
To be fair, I just moved to the format that Mike McGrath set up for repos.fedoraproject.org, so, please don't accuse me of not backing standardization. ;)
The point is not to accuse anyone of course. Merely was providing a suggestion on how we can standardize early on and used your package and repo as an example since it is likely to be more relevant.
Rahul
On Fri, 2010-07-30 at 21:03 +0530, Rahul Sundaram wrote:
On 07/30/2010 08:58 PM, Tom "spot" Callaway wrote:
I'm also working on a set of Firefox 4 packages (split between firefox4 and xulrunner) that more closely match the Fedora firefox packages, but are able to be installed without conflicts.
At the moment, I'm just targeting F-14.
That's really nice but I noticed that three people have their own set of repo files and different directory structure. I would prefer more standardization and a standard command by default to grab new repos like:
yum-repo-add fp:spot/chromium
in yum-utils upstream you can do:
yum-config-manager --add-repo=http://baseurl/some/place
or yum-config-manager --add-repo=http://path/to/some/foo.repo
either will add the repo you want.
-sv
On 07/30/2010 09:08 PM, seth vidal wrote:
in yum-utils upstream you can do:
yum-config-manager --add-repo=http://baseurl/some/place
or yum-config-manager --add-repo=http://path/to/some/foo.repo
either will add the repo you want.
That's almost what I want. Can we add a default shortcut for repos.fedorapeople.org? So perhaps it can be
yum-config-manager --add-repo fp:spot/chromium
Rahul
On Fri, 2010-07-30 at 21:11 +0530, Rahul Sundaram wrote:
On 07/30/2010 09:08 PM, seth vidal wrote:
in yum-utils upstream you can do:
yum-config-manager --add-repo=http://baseurl/some/place
or yum-config-manager --add-repo=http://path/to/some/foo.repo
either will add the repo you want.
That's almost what I want. Can we add a default shortcut for repos.fedorapeople.org? So perhaps it can be
yum-config-manager --add-repo fp:spot/chromium
umm. I dunno. I'll have to think about that one. That feels awfully dodgy to be in an upstream project's code.
-sv
On 07/30/2010 11:49 AM, seth vidal wrote:
On Fri, 2010-07-30 at 21:11 +0530, Rahul Sundaram wrote:
On 07/30/2010 09:08 PM, seth vidal wrote:
in yum-utils upstream you can do:
yum-config-manager --add-repo=http://baseurl/some/place
or yum-config-manager --add-repo=http://path/to/some/foo.repo
either will add the repo you want.
That's almost what I want. Can we add a default shortcut for repos.fedorapeople.org? So perhaps it can be
yum-config-manager --add-repo fp:spot/chromium
umm. I dunno. I'll have to think about that one. That feels awfully dodgy to be in an upstream project's code.
Perhaps a standard config file for "repo aliases" could be used, then Fedora could provide that config file with aliases for "fp", "remi", and other known third party repos. (Note: I don't think we would ever be able to include "rpmfusion" in that list, sadly.)
~spot
On Fri, 2010-07-30 at 11:51 -0400, Tom "spot" Callaway wrote:
On 07/30/2010 11:49 AM, seth vidal wrote:
On Fri, 2010-07-30 at 21:11 +0530, Rahul Sundaram wrote:
On 07/30/2010 09:08 PM, seth vidal wrote:
in yum-utils upstream you can do:
yum-config-manager --add-repo=http://baseurl/some/place
or yum-config-manager --add-repo=http://path/to/some/foo.repo
either will add the repo you want.
That's almost what I want. Can we add a default shortcut for repos.fedorapeople.org? So perhaps it can be
yum-config-manager --add-repo fp:spot/chromium
umm. I dunno. I'll have to think about that one. That feels awfully dodgy to be in an upstream project's code.
Perhaps a standard config file for "repo aliases" could be used, then Fedora could provide that config file with aliases for "fp", "remi", and other known third party repos. (Note: I don't think we would ever be able to include "rpmfusion" in that list, sadly.)
That's what I was thinking - just not sure how much use it will be.
-sv
On Fri, 2010-07-30 at 11:52 -0400, seth vidal wrote:
On Fri, 2010-07-30 at 11:51 -0400, Tom "spot" Callaway wrote:
On 07/30/2010 11:49 AM, seth vidal wrote:
On Fri, 2010-07-30 at 21:11 +0530, Rahul Sundaram wrote:
On 07/30/2010 09:08 PM, seth vidal wrote:
in yum-utils upstream you can do:
yum-config-manager --add-repo=http://baseurl/some/place
or yum-config-manager --add-repo=http://path/to/some/foo.repo
either will add the repo you want.
That's almost what I want. Can we add a default shortcut for repos.fedorapeople.org? So perhaps it can be
yum-config-manager --add-repo fp:spot/chromium
umm. I dunno. I'll have to think about that one. That feels awfully dodgy to be in an upstream project's code.
Perhaps a standard config file for "repo aliases" could be used, then Fedora could provide that config file with aliases for "fp", "remi", and other known third party repos. (Note: I don't think we would ever be able to include "rpmfusion" in that list, sadly.)
That's what I was thinking - just not sure how much use it will be.
So here's the question:
will someone often be doing: yum-config-manager --add-repo=fp:spot/chromium
or will they more likely do: yum-config-manager --add-repo=<paste-url-to-repofile-from-web-browser>
b/c it sure feels like the latter is more common.
-sv
On Fri, Jul 30, 2010 at 2:11 PM, seth vidal skvidal@fedoraproject.orgwrote:
On Fri, 2010-07-30 at 11:52 -0400, seth vidal wrote:
On Fri, 2010-07-30 at 11:51 -0400, Tom "spot" Callaway wrote:
On 07/30/2010 11:49 AM, seth vidal wrote:
On Fri, 2010-07-30 at 21:11 +0530, Rahul Sundaram wrote:
On 07/30/2010 09:08 PM, seth vidal wrote:
in yum-utils upstream you can do:
yum-config-manager --add-repo=http://baseurl/some/place
or yum-config-manager --add-repo=http://path/to/some/foo.repo
either will add the repo you want.
That's almost what I want. Can we add a default shortcut for repos.fedorapeople.org? So perhaps it can be
yum-config-manager --add-repo fp:spot/chromium
umm. I dunno. I'll have to think about that one. That feels awfully dodgy to be in an upstream project's code.
Perhaps a standard config file for "repo aliases" could be used, then Fedora could provide that config file with aliases for "fp", "remi",
and
other known third party repos. (Note: I don't think we would ever be able to include "rpmfusion" in that list, sadly.)
That's what I was thinking - just not sure how much use it will be.
So here's the question:
will someone often be doing: yum-config-manager --add-repo=fp:spot/chromium
or will they more likely do: yum-config-manager --add-repo=<paste-url-to-repofile-from-web-browser>
b/c it sure feels like the latter is more common.
-sv
Out of convenience, the former will be more common.
On Fri, 2010-07-30 at 14:12 -0500, Conan Kudo (ニール・ゴンパ) wrote:
So here's the question: will someone often be doing: yum-config-manager --add-repo=fp:spot/chromium or will they more likely do: yum-config-manager --add-repo=<paste-url-to-repofile-from-web-browser> b/c it sure feels like the latter is more common. -svOut of convenience, the former will be more common.
Out of convenience of what? You'd have to know: 1. the repo is on repos.fedorapeople.org 2. that the username is 'spot' 3. that the reponame is 'chromium'
and then you'd have to type all of it
instead of just pasting from your webbrowser directly from the website.
-sv
On Fri, Jul 30, 2010 at 2:13 PM, seth vidal skvidal@fedoraproject.orgwrote:
On Fri, 2010-07-30 at 14:12 -0500, Conan Kudo (ニール・ゴンパ) wrote:
So here's the question: will someone often be doing: yum-config-manager --add-repo=fp:spot/chromium or will they more likely do: yum-config-manager --add-repo=<paste-url-to-repofile-from-web-browser> b/c it sure feels like the latter is more common. -svOut of convenience, the former will be more common.
Out of convenience of what? You'd have to know:
- the repo is on repos.fedorapeople.org
- that the username is 'spot'
- that the reponame is 'chromium'
and then you'd have to type all of it
instead of just pasting from your webbrowser directly from the website.
-sv
Tutorials, printed manuals, etc.
In that case, copying and pasting is rather difficult, don't you think?
And also, fp:spot/chromium doesn't preclude copying and pasting that into the terminal.
Then there are cases when people are working in the terminal with no GUI available. Copying and pasting is almost impossible in that case.
It is easier for humans to remember "fp:spot/chromium" than a long string that is the repo URL.
On Fri, 2010-07-30 at 14:18 -0500, Conan Kudo (ニール・ゴンパ) wrote:
Tutorials, printed manuals, etc.
In that case, copying and pasting is rather difficult, don't you think?
And also, fp:spot/chromium doesn't preclude copying and pasting that into the terminal.
Then there are cases when people are working in the terminal with no GUI available. Copying and pasting is almost impossible in that case.
It is easier for humans to remember "fp:spot/chromium" than a long string that is the repo URL.
I guess I just don't think you're correct.
I think the claim that it's easier to remember is fairly made up.
I may still do the aliases, it's just not clear that they are much of a win.
-sv
On 30/07/10 20:18, Conan Kudo (ニール・ゴンパ) wrote:
Tutorials, printed manuals, etc.
In that case, copying and pasting is rather difficult, don't you think?
Not with an eReader or pdf.
And also, fp:spot/chromium doesn't preclude copying and pasting that into the terminal.
Then there are cases when people are working in the terminal with no GUI available. Copying and pasting is almost impossible in that case.
No the majority I would hazard.
It is easier for humans to remember "fp:spot/chromium" than a long string that is the repo URL.
Easier still to c&p from address bar. No need to remember, PCs' have memory.
On 07/31/2010 12:43 AM, seth vidal wrote:
Out of convenience of what? You'd have to know:
- the repo is on repos.fedorapeople.org
- that the username is 'spot'
- that the reponame is 'chromium'
and then you'd have to type all of it
instead of just pasting from your webbrowser directly from the website.
It is easier to remember and tell others I think. The command line tool could be extended to search and list repositories to make this even more useful
yum-config-manager search chromium / yum-config-manager list fp:
Rahul
On Sat, 2010-07-31 at 00:51 +0530, Rahul Sundaram wrote:
On 07/31/2010 12:43 AM, seth vidal wrote:
Out of convenience of what? You'd have to know:
- the repo is on repos.fedorapeople.org
- that the username is 'spot'
- that the reponame is 'chromium'
and then you'd have to type all of it
instead of just pasting from your webbrowser directly from the website.
It is easier to remember and tell others I think. The command line tool could be extended to search and list repositories to make this even more useful
yum-config-manager search chromium / yum-config-manager list fp:
no.
WAY out of scope.
not the least of which b/c we have no index and no way of traversing the list of repos there.
-sv
On Fri, Jul 30, 2010 at 5:51 PM, Tom "spot" Callaway tcallawa@redhat.com wrote:
On 07/30/2010 11:49 AM, seth vidal wrote:
On Fri, 2010-07-30 at 21:11 +0530, Rahul Sundaram wrote:
On 07/30/2010 09:08 PM, seth vidal wrote:
in yum-utils upstream you can do:
yum-config-manager --add-repo=http://baseurl/some/place
or yum-config-manager --add-repo=http://path/to/some/foo.repo
either will add the repo you want.
That's almost what I want. Can we add a default shortcut for repos.fedorapeople.org? So perhaps it can be
yum-config-manager --add-repo fp:spot/chromium
umm. I dunno. I'll have to think about that one. That feels awfully dodgy to be in an upstream project's code.
Perhaps a standard config file for "repo aliases" could be used, then Fedora could provide that config file with aliases for "fp", "remi", and other known third party repos. (Note: I don't think we would ever be able to include "rpmfusion" in that list, sadly.)
Not even with a note like
"The fedora project has no control about this repos use at your own risk etc. pp" ?
On 07/30/2010 09:40 PM, Tom "spot" Callaway wrote:
On 07/30/2010 11:53 AM, drago01 wrote:
Not even with a note like
"The fedora project has no control about this repos use at your own risk etc. pp" ?
No. Not even with a note like that.
Instead of a static list of preincluded repos, would it be possible to discover repos automatically from a neutral domain and therefore avoid liability?
Rahul
On Fri, Jul 30, 2010 at 6:33 PM, Rahul Sundaram metherid@gmail.com wrote:
On 07/30/2010 09:40 PM, Tom "spot" Callaway wrote:
On 07/30/2010 11:53 AM, drago01 wrote:
Not even with a note like
"The fedora project has no control about this repos use at your own risk etc. pp" ?
No. Not even with a note like that.
Instead of a static list of preincluded repos, would it be possible to discover repos automatically from a neutral domain and therefore avoid liability?
How is pointing to a domain that points to rpmfusion any different than pointing to rpmfusion? IANAL but if we can't do the later we can't do the former either ...
On 07/30/2010 10:05 PM, drago01 wrot
How is pointing to a domain that points to rpmfusion any different than pointing to rpmfusion? IANAL but if we can't do the later we can't do the former either ...
There is a precedent in some sense. A level of indirection can make a difference. It avoids liability as long as you don't describe in detail what you find in the neutral domain. openSUSE has done something similar as well.
Rahul
Rahul Sundaram (metherid@gmail.com) said:
"The fedora project has no control about this repos use at your own risk etc. pp" ?
No. Not even with a note like that.
Instead of a static list of preincluded repos, would it be possible to discover repos automatically from a neutral domain and therefore avoid liability?
Well, there's a massive trojan waiting to happen.
More seriously, can you please stop these constant pleas of 'how can I make Fedora do contributory infringement'? It's getting tiresome to have new 'can we do this? how about this? maybe this?' ideas every couple of weeks.
Bill
On 07/30/2010 10:09 PM, Bill Nottingham wrote:
Well, there's a massive trojan waiting to happen.
More seriously, can you please stop these constant pleas of 'how can I make Fedora do contributory infringement'? It's getting tiresome to have new 'can we do this? how about this? maybe this?' ideas every couple of weeks.
That's just twisting what I am asking. I rather you stop putting words in my mouth. I am understanding what the constraints are and how do you expect me to know without asking?
Rahul
Rahul Sundaram (metherid@gmail.com) said:
More seriously, can you please stop these constant pleas of 'how can I make Fedora do contributory infringement'? It's getting tiresome to have new 'can we do this? how about this? maybe this?' ideas every couple of weeks.
That's just twisting what I am asking. I rather you stop putting words in my mouth. I am understanding what the constraints are and how do you expect me to know without asking?
Everything I've seen you ask about repos stems from an apparent end goal of 'get rpmfusion onto Fedora systems as much as possible', and consists of attempting to either have Fedora make changes to accomplish that, or to language lawyer around the existing guidelines. It's tiring.
Bill
On Fri, Jul 30, 2010 at 10:50 PM, Bill Nottingham wrote:
Everything I've seen you ask about repos stems from an apparent end goal of 'get rpmfusion onto Fedora systems as much as possible', and consists of attempting to either have Fedora make changes to accomplish that, or to language lawyer around the existing guidelines. It's tiring
You have to be in engaging in very selective reading or exaggerating dramatically. Even in this thread, I have talked about a standard way of accessing repositories to make it easier for users, asking remi to make Firefox 4 available in repo etc which has nothing to do with RPM Fusion. When i have asked questions about legal constraints, you make it sound sneaky or whatever but these are plain and simple questions and I have written down this knowledge in many places including
http://fedoraproject.org/wiki/Software_Patents
I am hardly the only person asking and I was directing it at Spot. Why are you attacking it?
Rahul
Rahul Sundaram (metherid@gmail.com) said:
dramatically. Even in this thread, I have talked about a standard way of accessing repositories to make it easier for users, asking remi to make Firefox 4 available in repo etc which has nothing to do with RPM Fusion.
Example 1:
Warning - paraphrasing:
<spot> We can't have an rpmfusion alias. <drago01> Not even with a disclaimer? <spot> No. <you> Well, how about if we do this other thing?
Implication: your goal is to get more people on rpmfusion, and you want to take any legal loopholes you can find to get there
Example 2:
<you> "To be direct, if [a] fedoracommunity.org [site] wiki documents the steps to use RPM Fusion, is that ok according to Red Hat Legal?"
Implication: your goal is to get more people on rpmfusion, and you want to take any legal loopholes you can find to get there
And in followup, (paraphrased):
<stickster> As long as the fedoracomunity.org subdomain points to space not managed by the Fedora Project, we cannot control it. <you> can I then have a mediawiki connected to FAS so I can do this?
Implication: your goal is to get more people on rpmfusion, and you want to take any legal loopholes you can find to get there, or get Fedora to help with this. (And you persisted in arguing with spot after he said no to this, too.)
I don't deny that you do a lot of good for the project, or even that you do good work in documenting patented restrictions, etc. But in *this particular point* (enabling easier/automated/semi-automated access to forbidden items), the constant pushing reminds me of nothing more than a 9-year old attempting to come up with ways they can have more cookies for dessert after they've been told no. Saying no to each particular variant is tiring.
Bill
On 07/30/2010 11:28 PM, Bill Nottingham wrote:
Implication: your goal is to get more people on rpmfusion, and you want to take any legal loopholes you can find to get there
The wording here makes it seem twisted and I don't think it is. There are legal constrains in doing certain things and there are certain things that are allowed. Are things that are allowed loopholes? I suppose that is a matter of perspective. I could give you more detailed examples but I am sure you are aware of a few yourself. One quick example is that we are not allowed to directly link to a third party repository and describe what is there but we are allowed to link to a domain which in turn describes a third party repository. That is permitted and we do that. Is that a exploitation of a loophole or helping end users? I think it is helping end users within our constraints. Making it easier to access repositories other than default is a useful thing and we are taking steps forward with that. When we are making that capability available, it is important to think about how to make it easier and whether important third party repositories can be made accessible and if there is a level of indirection that makes it possible, we should. I view it as helping our users, not exploiting some hole. You would notice in this thread, I wasn't the first person to ask even.
If I ask, I bother to document the details and refer it to the next person asking about it and since I engage with the user communities in the forums and mailing lists, I can tell you that such questions do come up quite often. If it is already answered and documented already, I could simply refer to it and move on. Otherwise we end up in the debates for a prolonged manner. It is a pragmatic question and I making sure we have thought about the possibilities. Yes, it might be tiring but it is done in good faith and while you might consider it childish, my goal is to help end users. I am persistent about it on occasions but I am not obsessed with RPM Fusion or anything like that.
Rahul
On Fri, Jul 30, 2010 at 1:30 PM, Rahul Sundaram metherid@gmail.com wrote:
On Fri, Jul 30, 2010 at 10:50 PM, Bill Nottingham wrote:
Everything I've seen you ask about repos stems from an apparent end goal of 'get rpmfusion onto Fedora systems as much as possible', and consists of attempting to either have Fedora make changes to accomplish that, or to language lawyer around the existing guidelines. It's tiring
You have to be in engaging in very selective reading or exaggerating dramatically. Even in this thread, I have talked about a standard way of
Rahul, Bill's characterization of your responses seems more than fair to me.
Many months back I began drafting a letter intended for RedHat legal folks raising a concern that your activities were a potential liability. ... but I ended up not finishing it because it made me feel like a tattle-tale.
Regardless, — you have frequently come off as presenting a wink-wink-nod-nod kind of approach towards these issues, and I think it reflects poorly on the fedora project. I hope you'll discontinue it.
On 07/30/2010 11:52 PM, Gregory Maxwell wrote:
Regardless, — you have frequently come off as presenting a wink-wink-nod-nod kind of approach towards these issues, and I think it reflects poorly on the fedora project. I hope you'll discontinue it.
Again, I have to disagree. My questions are clear and direct, how it is "wink-wink-nod-nod" approach? Can you explain how merely asking these questions reflects poorly on Fedora Project? is is better for end users to be asking the same questions and left without clear answers? I wouldn't think so but I am willing to hear other opinions. If you feel anything I do is a liability, please feel free to explain it to me offlist or via Red Hat Legal even. I am not doing anything sneaky here.
Rahul
On Fri, 2010-07-30 at 11:49 -0400, seth vidal wrote:
On Fri, 2010-07-30 at 21:11 +0530, Rahul Sundaram wrote:
On 07/30/2010 09:08 PM, seth vidal wrote:
in yum-utils upstream you can do:
yum-config-manager --add-repo=http://baseurl/some/place
or yum-config-manager --add-repo=http://path/to/some/foo.repo
either will add the repo you want.
That's almost what I want. Can we add a default shortcut for repos.fedorapeople.org? So perhaps it can be
yum-config-manager --add-repo fp:spot/chromium
umm. I dunno. I'll have to think about that one. That feels awfully dodgy to be in an upstream project's code.
A precedent for having site specific code in software: bzr (package bazaar) has special code for handling launchpad hosted repositories.
On Fri, 2010-07-30 at 18:50 +0200, Hans Ulrich Niedermann wrote:
On Fri, 2010-07-30 at 11:49 -0400, seth vidal wrote:
On Fri, 2010-07-30 at 21:11 +0530, Rahul Sundaram wrote:
On 07/30/2010 09:08 PM, seth vidal wrote:
in yum-utils upstream you can do:
yum-config-manager --add-repo=http://baseurl/some/place
or yum-config-manager --add-repo=http://path/to/some/foo.repo
either will add the repo you want.
That's almost what I want. Can we add a default shortcut for repos.fedorapeople.org? So perhaps it can be
yum-config-manager --add-repo fp:spot/chromium
umm. I dunno. I'll have to think about that one. That feels awfully dodgy to be in an upstream project's code.
A precedent for having site specific code in software: bzr (package bazaar) has special code for handling launchpad hosted repositories.
Yah - and if you ask me that's a dick-move. :)
-sv
On 07/30/2010 08:58 PM, Tom "spot" Callaway wrote:
I'm also working on a set of Firefox 4 packages (split between firefox4 and xulrunner) that more closely match the Fedora firefox packages, but are able to be installed without conflicts.
At the moment, I'm just targeting F-14.
Thanks. https://fedoraproject.org/wiki/Firefox_4
Rahul
On Fri, Jul 30, 2010 at 2:01 PM, Rahul Sundaram metherid@gmail.com wrote:
On 07/30/2010 08:58 PM, Tom "spot" Callaway wrote:
I'm also working on a set of Firefox 4 packages (split between firefox4 and xulrunner) that more closely match the Fedora firefox packages, but are able to be installed without conflicts.
At the moment, I'm just targeting F-14.
Thanks. https://fedoraproject.org/wiki/Firefox_4
Rahul
Uhh... Firefox 4 GA is before F14 even goes into GA stage. So, that isn't true. Firefox 4 could be included in Fedora 14, and it should be.
On 07/31/2010 12:41 AM, Conan Kudo (ニール・ゴンパ) wrote:
Uhh... Firefox 4 GA is before F14 even goes into GA stage. So, that isn't true. Firefox 4 could be included in Fedora 14, and it should be.
Provide a reference for that. Fedora 14 release schedule is
http://fedoraproject.org/wiki/Releases/14/Schedule
Rahul
On Fri, Jul 30, 2010 at 2:17 PM, Rahul Sundaram metherid@gmail.com wrote:
On 07/31/2010 12:41 AM, Conan Kudo (ニール・ゴンパ) wrote:
Uhh... Firefox 4 GA is before F14 even goes into GA stage. So, that isn't true. Firefox 4 could be included in Fedora 14, and it should be.
Provide a reference for that. Fedora 14 release schedule is
http://fedoraproject.org/wiki/Releases/14/Schedule
Rahul
Hmm, okay.
I was only aware of the October 26 release date before now.
Anyway, here's the Firefox 4 milestone list: https://wiki.mozilla.org/Firefox/4/Beta#Milestones
October 15 is when they go into total freeze and produce release candidates and then the final release.
Fedora composes the Final on October 12, but that assumes that we're not going to slip one or two weeks as we have for every release of Fedora for the last couple years. If we slip, and Mozilla pushes out the GA before Final is composed, that could be slipped in.
Either way, we could still squeeze in a Firefox 4 Beta and push out the final or an RC as a post install update. Then later Fedora Unity will generate a spin that will include Firefox 4 GA.
We've never had problems with including Firefox betas before, so why now? Fedora is the premier distro for getting the latest and greatest software, not just the stuff that everyone else has. It is why I use Fedora over Ubuntu or some other distro.
On 07/31/2010 12:56 AM, Conan Kudo (ニール・ゴンパ) wrote:
I was only aware of the October 26 release date before now.
Anyway, here's the Firefox 4 milestone list: https://wiki.mozilla.org/Firefox/4/Beta#Milestones
October 15 is when they go into total freeze and produce release candidates and then the final release.
Fedora 14 feature freeze has already passed. Upto the maintainers and FESCo at this point if they want exceptions. I am just documenting the current option. No need to jump at me.
Rahul
On Fri, 30 Jul 2010, Conan Kudo (ニール・ゴンパ) wrote:
On Fri, Jul 30, 2010 at 2:17 PM, Rahul Sundaram metherid@gmail.com wrote: On 07/31/2010 12:41 AM, Conan Kudo (ニール・ゴンパ) wrote: > > Uhh... Firefox 4 GA is before F14 even goes into GA stage. So, that > isn't true. Firefox 4 could be included in Fedora 14, and it should be. >
Provide a reference for that. Fedora 14 release schedule is
http://fedoraproject.org/wiki/Releases/14/Schedule
Rahul
Hmm, okay.
I was only aware of the October 26 release date before now.
Anyway, here's the Firefox 4 milestone list: https://wiki.mozilla.org/Firefox/4/Beta#Milestones
October 15 is when they go into total freeze and produce release candidates and then the final release.
Fedora composes the Final on October 12, but that assumes that we're not going to slip one or two weeks as we have for every release of Fedora for the last couple years. If we slip, and Mozilla pushes out the GA before Final is composed, that could be slipped in.
Either way, we could still squeeze in a Firefox 4 Beta and push out the final or an RC as a post install update. Then later Fedora Unity will generate a spin that will include Firefox 4 GA.
We've never had problems with including Firefox betas before, so why now? Fedora is the premier distro for getting the latest and greatest software, not just the stuff that everyone else has. It is why I use Fedora over Ubuntu or some other distro.
This is foolish, I'm sorry but it just is. If we treated all of our software this way, we wouldn't need an alpha or beta because everything'd be changing at the last minute. If upstream doesn't think it's ready by our own alpha, why on earth would we try to squeeze it in later in the game where it will go GA to our users with little or no testing with itself and other applications?
-Mike
On Fri, 2010-07-30 at 14:26 -0500, Conan Kudo (ニール・ゴンパ) wrote:
Fedora composes the Final on October 12, but that assumes that we're not going to slip one or two weeks as we have for every release of Fedora for the last couple years. If we slip, and Mozilla pushes out the GA before Final is composed, that could be slipped in.
The Mozilla timeline assumes that *Mozilla* don't slip, and historically they've slipped a lot, just like we have.
W dniu 30.07.2010 17:28, Tom "spot" Callaway pisze:
On 07/30/2010 11:10 AM, Rahul Sundaram wrote:
On 07/30/2010 03:16 AM, Mike McGrath wrote:
So I just created:
http://repos.fedorapeople.org/
Anyone want to help me test the steps and process before we announce and deploy it? Anyone already got Firefox 4 built for F13 for example? Let me know or stop by #fedora-admin on irc.freenode.net
Remi,
Would be nice to have Firefox 4 in there.
I'm also working on a set of Firefox 4 packages (split between firefox4 and xulrunner) that more closely match the Fedora firefox packages, but are able to be installed without conflicts.
At the moment, I'm just targeting F-14.
~spot
Would it be a problem for you to make packages for F-13 as well?
Julian
On 08/01/2010 12:55 PM, Julian Sikorski wrote:
W dniu 30.07.2010 17:28, Tom "spot" Callaway pisze:
On 07/30/2010 11:10 AM, Rahul Sundaram wrote:
On 07/30/2010 03:16 AM, Mike McGrath wrote:
So I just created:
http://repos.fedorapeople.org/
Anyone want to help me test the steps and process before we announce and deploy it? Anyone already got Firefox 4 built for F13 for example? Let me know or stop by #fedora-admin on irc.freenode.net
Remi,
Would be nice to have Firefox 4 in there.
I'm also working on a set of Firefox 4 packages (split between firefox4 and xulrunner) that more closely match the Fedora firefox packages, but are able to be installed without conflicts.
At the moment, I'm just targeting F-14.
~spot
Would it be a problem for you to make packages for F-13 as well?
Eventually, yes. Its at the bottom of my list though.
~spot
On Wed, Jul 28, 2010 at 4:37 PM, Paul W. Frields stickster@gmail.com wrote:
On Wed, Jul 28, 2010 at 03:04:46PM +0200, Florent Le Coz wrote:
On 28/07/2010 14:52, Mike McGrath wrote:
In my opinion including software that even upstream says is not ready is for a distribution that's "lost their way". We can still be a leading distribution and not include pre-release software. Especially pre-release software that's not only in our critical path, but also something that almost all of us use every day.
I agree, but doesn't that mean that Firefox 4.0 won't be available in F14 at all and will only be in F15? I think it would be a huge drawback for Fedora 14.
It would be huge if there people who can't live without it didn't have any other way of getting it than having it pre-packaged. I think Firefox 4 looks to be fantastic, but the truth is that people only have to wait a few months for a release with it pre-packaged, if they're not able to add it on their own.
Well if the mozilla maintainers would get it into rawhide shortly after the F-14 branch it would mean that people could get it from the F-15 repos. For years I've used or recompiled srpm rawhide packages that I've wanted/needed in a stable release. This has included firefox and even evolution.
Peter
On Wed, 2010-07-28 at 07:52 -0500, Mike McGrath wrote:
I think what people are missing is that even though our release is scheduled for late October. The feature freeze was _yesterday_. meaning that firefox would need to have been ready for use yesterday. Not in October when it might maybe be ready.
Nope. That's only for things that are declared as features. If you don't declare your version update to be a feature, you can happily do it right up to the release freeze.
(This is one thing I find absurd about the feature process, but don't get me started.)
The work done by Remi, providing a parallel install Firefox 4 for Fedora 13, could be reused to provide the same parallel install in Fedora 14.
http://rpms.famillecollet.com/fedora/13/remi/i386/repoview/firefox4.html
http://blog.famillecollet.com/pages/Config-en
kai
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/28/2010 09:59 AM, Adam Williamson wrote:
Nope. That's only for things that are declared as features. If you don't declare your version update to be a feature, you can happily do it right up to the release freeze.
I'd like to apply it to all packages, but I tend to get severe push back whenever I suggest that.
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
On Tue, Jul 27, 2010 at 11:08 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Tue, 27 Jul 2010, Athmane Madjoudj wrote:
On 07/27/2010 10:53 PM, Rahul Sundaram wrote:
Hi,
Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released recently and I am wondering if we can go with it if it fits into the schedule. There are dozens of new features including WebM support that would be nice to have.
Rahul
The final version of FF4 is scheduled at oct-nov 2010 and Fedora 14 at 26 Oct 2010
I think, it's OK to have ff4 in F14, and better is IMHO is to have a parallel installation, something like:
firefox3-3.x.x firefox-4.x.x
Sources:
[1] https://wiki.mozilla.org/Releases [2] http://fedoraproject.org/wiki/Releases/14/Schedule
-1 didn't the last time we started using a pre-release from Mozilla turn out pretty bad for us?
well the last beta I presume your talking about is a certain mail client. The last time we shipped a beta firefox for release I think was for firefox 3 and it was something like beta6 with the official release coming out shortly after and from my memory the beta was relatively stable and a reasonable win in terms of performance. There was some discussion about it but I don't remember anything to the tune of thunderbird. The xulrunner dependents are obviously an issue but with gnome 3 and the move to webkit it rules out the vast majority of them and I'm not even sure thunderbird uses the offset xulrunner (but its likely there are others that do need review).
Peter
Peter
On 07/28/2010 01:08 AM, Mike McGrath wrote:
On 07/27/2010 10:53 PM, Rahul Sundaram wrote:
Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released recently and I am wondering if we can go with it if it fits into the schedule. There are dozens of new features including WebM support that would be nice to have.
-1 didn't the last time we started using a pre-release from Mozilla turn out pretty bad for us?
That was Firefox 3.0 included as RC in Fedora 9, from an user perspective my memories about it are sweet... it was worse with Thunderbird 3, which was included in a release (F11) in Beta stage, and not even a late beta, it was something like Beta2, but AFAIK Firefox is expected to be RC around F14.
And while Thunderbird 3 was included due to the slow development pace of the upstream (we used to have a very old Tb 2), Firefox 4 comes with at least a killer feature, WebM (IIRC, another killer feature is the new js engine)
On Wed, Jul 28, 2010 at 2:57 AM, Nicu Buculei nicu_fedora@nicubunu.ro wrote:
On 07/28/2010 01:08 AM, Mike McGrath wrote:
On 07/27/2010 10:53 PM, Rahul Sundaram wrote:
Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released recently and I am wondering if we can go with it if it fits into the schedule. There are dozens of new features including WebM support that would be nice to have.
-1 didn't the last time we started using a pre-release from Mozilla turn out pretty bad for us?
That was Firefox 3.0 included as RC in Fedora 9, from an user perspective my memories about it are sweet... it was worse with Thunderbird 3, which was included in a release (F11) in Beta stage, and not even a late beta, it was something like Beta2, but AFAIK Firefox is expected to be RC around F14.
And while Thunderbird 3 was included due to the slow development pace of the upstream (we used to have a very old Tb 2), Firefox 4 comes with at least a killer feature, WebM (IIRC, another killer feature is the new js engine)
-- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Quite the contrary.
The Linux kernel is trademarked. Linus isn't a jerk and doesn't prevent distros from patching it.
Mozilla's trademark requirements violate Freedom #2 The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this.
We're NOT allowed to make changes (patches) without their permission. This is defacto non-free. I understand we work with upstream but that shouldn't prevent us from maintaining it.
On 07/28/2010 04:15 PM, Brandon Lozza wrote:
We're NOT allowed to make changes (patches) without their permission. This is defacto non-free. I understand we work with upstream but that shouldn't prevent us from maintaining it.
We are maintaining it just fine. Licensing is offtopic for this thread and I recommend you talk to FSF and understand the view points on the issue of trademark guidelines.
Rahul
On Wed, Jul 28, 2010 at 6:49 AM, Rahul Sundaram metherid@gmail.com wrote:
On 07/28/2010 04:15 PM, Brandon Lozza wrote:
We're NOT allowed to make changes (patches) without their permission. This is defacto non-free. I understand we work with upstream but that shouldn't prevent us from maintaining it.
We are maintaining it just fine. Licensing is offtopic for this thread and I recommend you talk to FSF and understand the view points on the issue of trademark guidelines.
Rahul
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
The FSF drafted up the four freedoms and it's not offtopic, we're discussing Firefox4 and the fact that we won't be able to make changes to it to fix it without their permission.
On 07/28/2010 04:22 PM, Brandon Lozza wrote
The FSF drafted up the four freedoms and it's not offtopic, we're discussing Firefox4 and the fact that we won't be able to make changes to it to fix it without their permission.
There is no specific non-upstream change that Firefox maintainers in Fedora want to do and hence it is irrelevant to this thread which is merely about integration of Firefox in Fedora 14 which requires no patches.
Rahul
On Wed, Jul 28, 2010 at 6:55 AM, Rahul Sundaram metherid@gmail.com wrote:
On 07/28/2010 04:22 PM, Brandon Lozza wrote
The FSF drafted up the four freedoms and it's not offtopic, we're discussing Firefox4 and the fact that we won't be able to make changes to it to fix it without their permission.
There is no specific non-upstream change that Firefox maintainers in Fedora want to do and hence it is irrelevant to this thread which is merely about integration of Firefox in Fedora 14 which requires no patches.
Wrong, users of the KDE spin would LOVE to have OpenSUSE's patches to integrate it _better_ with KDE.
On 07/28/2010 05:47 PM, Brandon Lozza wrote:
On Wed, Jul 28, 2010 at 6:55 AM, Rahul Sundaram metherid@gmail.com wrote:
On 07/28/2010 04:22 PM, Brandon Lozza wrote
The FSF drafted up the four freedoms and it's not offtopic, we're discussing Firefox4 and the fact that we won't be able to make changes to it to fix it without their permission.
There is no specific non-upstream change that Firefox maintainers in Fedora want to do and hence it is irrelevant to this thread which is merely about integration of Firefox in Fedora 14 which requires no patches.
Wrong, users of the KDE spin would LOVE to have OpenSUSE's patches to integrate it _better_ with KDE.
What does that have to do with this thread? As long as the patches are not upstream, Firefox in Fedora won't have it. Period.
Rahul
On Wed, Jul 28, 2010 at 8:27 AM, Rahul Sundaram metherid@gmail.com wrote:
On 07/28/2010 05:47 PM, Brandon Lozza wrote:
On Wed, Jul 28, 2010 at 6:55 AM, Rahul Sundaram metherid@gmail.com wrote:
On 07/28/2010 04:22 PM, Brandon Lozza wrote
The FSF drafted up the four freedoms and it's not offtopic, we're discussing Firefox4 and the fact that we won't be able to make changes to it to fix it without their permission.
There is no specific non-upstream change that Firefox maintainers in Fedora want to do and hence it is irrelevant to this thread which is merely about integration of Firefox in Fedora 14 which requires no patches.
Wrong, users of the KDE spin would LOVE to have OpenSUSE's patches to integrate it _better_ with KDE.
What does that have to do with this thread? As long as the patches are not upstream, Firefox in Fedora won't have it. Period.
Rahul
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
It does have to do with the thread; stop saying it doesn't.
The point is, if we rely on upstream to fix the software then we SHOULD NOT ship BETA. There are technical (security, stability) reasons for this.
On Wed, 28 Jul 2010 17:57:39 +0530, Rahul Sundaram wrote:
On 07/28/2010 05:47 PM, Brandon Lozza wrote:
On Wed, Jul 28, 2010 at 6:55 AM, Rahul Sundaram metherid@gmail.com wrote:
On 07/28/2010 04:22 PM, Brandon Lozza wrote
The FSF drafted up the four freedoms and it's not offtopic, we're discussing Firefox4 and the fact that we won't be able to make changes to it to fix it without their permission.
There is no specific non-upstream change that Firefox maintainers in Fedora want to do and hence it is irrelevant to this thread which is merely about integration of Firefox in Fedora 14 which requires no patches.
Wrong, users of the KDE spin would LOVE to have OpenSUSE's patches to integrate it _better_ with KDE.
What does that have to do with this thread? As long as the patches are not upstream, Firefox in Fedora won't have it. Period.
Is Red Hat Legal just more careful than Novell's legal department? Otherwise, how is it that they ship Firefox with custom patches (and call it Firefox) and we don't..
Regards,
On 07/28/2010 07:23 PM, Michel Alexandre Salim wrote:
Is Red Hat Legal just more careful than Novell's legal department? Otherwise, how is it that they ship Firefox with custom patches (and call it Firefox) and we don't..
Firefox can be shipped with custom patches and the trademark intact as long as Mozilla agrees to it. Alternatively, you can implement additional functionality via a add-on and include that by default.
Rahul
On Wed, Jul 28, 2010 at 12:52 PM, Brandon Lozza brandon@pwnage.ca wrote:
The FSF drafted up the four freedoms and it's not offtopic, we're discussing Firefox4 and the fact that we won't be able to make changes to it to fix it without their permission.
You know that Fedora isn't any different or even worse right? So complaining on how others protect their trademark while we do essentially the same is kind of BS.
And btw. the four freedoms defined by the FSF do not require you to be able to use a trademark without permission.
Le 28/07/2010 12:45, Brandon Lozza a écrit :
Mozilla's trademark requirements violate Freedom #2 The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this.
We're NOT allowed to make changes (patches) without their permission. This is defacto non-free. I understand we work with upstream but that shouldn't prevent us from maintaining it.
That's just the same with most distro trademarks (fedora, debian, etc ...)
Mozilla does not forbid you to study/modify/distribute their work but as fedora to distribute a modified version under their trademark. That's why we have generic-* packages in our repositories.
Best regards, H.
On Wed, 2010-07-28 at 09:57 +0300, Nicu Buculei wrote:
On 07/28/2010 01:08 AM, Mike McGrath wrote:
On 07/27/2010 10:53 PM, Rahul Sundaram wrote:
Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released recently and I am wondering if we can go with it if it fits into the schedule. There are dozens of new features including WebM support that would be nice to have.
-1 didn't the last time we started using a pre-release from Mozilla turn out pretty bad for us?
That was Firefox 3.0 included as RC in Fedora 9, from an user perspective my memories about it are sweet... it was worse with Thunderbird 3, which was included in a release (F11) in Beta stage, and not even a late beta, it was something like Beta2, but AFAIK Firefox is expected to be RC around F14.
And while Thunderbird 3 was included due to the slow development pace of the upstream (we used to have a very old Tb 2), Firefox 4 comes with at least a killer feature, WebM (IIRC, another killer feature is the new js engine)
...which is already present in all currently maintained fedora releases via webkitgtk (midori, epiphany, kazehakase, ...). Now, that is a *real killer feature*... I'm not sure about the js engine but something tells me it's still slower than webkit's or chromium's or opera's...
Sorry, I'm -1 for FF4 in F14. It's second beta now and scheduled release is around F14 release, which is too late (not counting in account that they'll most likely slip with their release...).
Martin
On Wed, Jul 28, 2010 at 10:40 AM, Martin Sourada martin.sourada@gmail.com wrote:
On Wed, 2010-07-28 at 09:57 +0300, Nicu Buculei wrote:
On 07/28/2010 01:08 AM, Mike McGrath wrote:
On 07/27/2010 10:53 PM, Rahul Sundaram wrote:
Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released recently and I am wondering if we can go with it if it fits into the schedule. There are dozens of new features including WebM support that would be nice to have.
-1 didn't the last time we started using a pre-release from Mozilla turn out pretty bad for us?
That was Firefox 3.0 included as RC in Fedora 9, from an user perspective my memories about it are sweet... it was worse with Thunderbird 3, which was included in a release (F11) in Beta stage, and not even a late beta, it was something like Beta2, but AFAIK Firefox is expected to be RC around F14.
And while Thunderbird 3 was included due to the slow development pace of the upstream (we used to have a very old Tb 2), Firefox 4 comes with at least a killer feature, WebM (IIRC, another killer feature is the new js engine)
...which is already present in all currently maintained fedora releases via webkitgtk (midori, epiphany, kazehakase, ...). Now, that is a *real killer feature*... I'm not sure about the js engine but something tells me it's still slower than webkit's or chromium's or opera's...
Sorry, I'm -1 for FF4 in F14. It's second beta now and scheduled release is around F14 release, which is too late (not counting in account that they'll most likely slip with their release...).
Martin
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
There is also plugin compatibility . Newer != better
On Wed, Jul 28, 2010 at 09:57:56AM +0300, Nicu Buculei wrote:
On 07/28/2010 01:08 AM, Mike McGrath wrote:
On 07/27/2010 10:53 PM, Rahul Sundaram wrote:
Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released recently and I am wondering if we can go with it if it fits into the schedule. There are dozens of new features including WebM support that would be nice to have.
-1 didn't the last time we started using a pre-release from Mozilla turn out pretty bad for us?
That was Firefox 3.0 included as RC in Fedora 9, from an user perspective my memories about it are sweet... it was worse with Thunderbird 3, which was included in a release (F11) in Beta stage, and not even a late beta, it was something like Beta2, but AFAIK Firefox is expected to be RC around F14.
And while Thunderbird 3 was included due to the slow development pace of the upstream (we used to have a very old Tb 2), Firefox 4 comes with at least a killer feature, WebM (IIRC, another killer feature is the new js engine)
WebM? That's hardly a killer feature for me. I don't even know what does it mean...
D.
On Thu, 2010-07-29 at 07:03 +0200, David Tardon wrote:
And while Thunderbird 3 was included due to the slow development pace of the upstream (we used to have a very old Tb 2), Firefox 4 comes with at least a killer feature, WebM (IIRC, another killer feature is the new js engine)
WebM? That's hardly a killer feature for me. I don't even know what does it mean...
Uh, have you been under a rock for the last two months? :) It's only been all over the news ever since May. It's (allegedly) patent-unencumbered modern video, it's the VP8 format bought out and open sourced by Google. It's really kind of a big deal. I'd give links, but honestly, just google it.
On Wed, 2010-07-28 at 23:20 -0700, Adam Williamson wrote:
On Thu, 2010-07-29 at 07:03 +0200, David Tardon wrote:
And while Thunderbird 3 was included due to the slow development pace of the upstream (we used to have a very old Tb 2), Firefox 4 comes with at least a killer feature, WebM (IIRC, another killer feature is the new js engine)
WebM? That's hardly a killer feature for me. I don't even know what does it mean...
Uh, have you been under a rock for the last two months? :) It's only been all over the news ever since May. It's (allegedly) patent-unencumbered modern video, it's the VP8 format bought out and open sourced by Google. It's really kind of a big deal. I'd give links, but honestly, just google it.
Actually, it's a combination of the VP8 video format, vorbis audio and modified matroska container (AFAIK you can mux it correctly with F14's version of mkvtoolnix).
Martin
Doesn't our version already support WebM?
On Tue, Jul 27, 2010 at 5:53 PM, Rahul Sundaram metherid@gmail.com wrote:
Hi,
Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released recently and I am wondering if we can go with it if it fits into the schedule. There are dozens of new features including WebM support that would be nice to have.
Rahul
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 07/28/2010 03:33 AM, Brandon Lozza wrote:
Doesn't our version already support WebM?
Nope. We have updated Gstreamer and WebKit-Gtk in Fedora 13 and 12 for WebM support bringing it to Epiphany and Midori users and I assume Spot's Chromium repo users also have support for it but Firefox 4 will be the first stable version with WebM support built-in.
Rahul
Rahul Sundaram writes:
On 07/28/2010 03:33 AM, Brandon Lozza wrote:
Doesn't our version already support WebM?
Nope. We have updated Gstreamer and WebKit-Gtk in Fedora 13 and 12 for WebM support bringing it to Epiphany and Midori users and I assume Spot's Chromium repo users also have support for it but Firefox 4 will be the first stable version with WebM support built-in.
According to this two year-old post, it's possible to build Firefox with gstreamer support:
http://www.bluishcoder.co.nz/2008/04/firefox-html5-video-with-gstreamer.html
Dunno if any of that is true today.
There's precedent for Firefox using system components instead of bundled ones. Firefox already uses hunspell instead of its own bundled dictionary, for spell checking. It makes sense for Firefox to use gstreamer, instead of any bundled codecs.
On 07/28/2010 04:06 AM, Sam Varshavchik wrote:
According to this two year-old post, it's possible to build Firefox with gstreamer support:
http://www.bluishcoder.co.nz/2008/04/firefox-html5-video-with-gstreamer.html
Dunno if any of that is true today.
There's precedent for Firefox using system components instead of bundled ones. Firefox already uses hunspell instead of its own bundled dictionary, for spell checking. It makes sense for Firefox to use gstreamer, instead of any bundled codecs.
The blog post talks about a non upstreamed patch and Firefox doesn't use Gstreamer at all now. It isn't just a matter of a bundled vs system components at this point. Non upstreamed patches are not a option for Firefox for trademark reasons as well.
Rahul
On 7/27/10, Rahul Sundaram metherid@gmail.com wrote:
On 07/28/2010 04:06 AM, Sam Varshavchik wrote:
According to this two year-old post, it's possible to build Firefox with gstreamer support:
http://www.bluishcoder.co.nz/2008/04/firefox-html5-video-with-gstreamer.html
Dunno if any of that is true today.
There's precedent for Firefox using system components instead of bundled ones. Firefox already uses hunspell instead of its own bundled dictionary, for spell checking. It makes sense for Firefox to use gstreamer, instead of any bundled codecs.
The blog post talks about a non upstreamed patch and Firefox doesn't use Gstreamer at all now. It isn't just a matter of a bundled vs system components at this point. Non upstreamed patches are not a option for Firefox for trademark reasons as well.
Rahul
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
what about iceweasel or icefox instead
the trademark problem makes it non free
On Tue, Jul 27, 2010 at 6:31 PM, Brandon Lozza brandon@pwnage.ca wrote:
On 7/27/10, Rahul Sundaram metherid@gmail.com wrote:
On 07/28/2010 04:06 AM, Sam Varshavchik wrote:
According to this two year-old post, it's possible to build Firefox with gstreamer support:
http://www.bluishcoder.co.nz/2008/04/firefox-html5-video-with-gstreamer.html
Dunno if any of that is true today.
There's precedent for Firefox using system components instead of bundled ones. Firefox already uses hunspell instead of its own bundled dictionary, for spell checking. It makes sense for Firefox to use gstreamer, instead of any bundled codecs.
The blog post talks about a non upstreamed patch and Firefox doesn't use Gstreamer at all now. It isn't just a matter of a bundled vs system components at this point. Non upstreamed patches are not a option for Firefox for trademark reasons as well.
Rahul
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
what about iceweasel or icefox instead
the trademark problem makes it non free
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Then that would make most Linux distributions non-free, including Fedora. So, meh. Fedora also has a policy of trying not to add patches to their own packages, so it jives just fine with Mozilla's trademark policy.
Plus, those names suck, keep the Mozilla Firefox name.
On 07/28/2010 05:01 AM, Brandon Lozza wrote:
what about iceweasel or icefox instead
the trademark problem makes it non free
Fedora has a policy of not patching upstream software as much as possible and trademark is only partially the reason and no, trademark requirements do not make anything non-free.
Rahul
On 07/28/2010 12:49 AM, Rahul Sundaram wrote:
Non upstreamed patches are not a option for Firefox for trademark reasons as well.
Non upstreamed patches are not an option because it's a pain in the to have to update patches every few weeks for a new FF release. We either can do patches or take new releases, doing both is just a maintenance nightmare. Since Fedora is all about doing stuff upstream, it sorts itself out better that way.
On 07/28/2010 05:09 AM, Christopher Aillon wrote:
On 07/28/2010 12:49 AM, Rahul Sundaram wrote:
Non upstreamed patches are not a option for Firefox for trademark reasons as well.
Non upstreamed patches are not an option because it's a pain in the to have to update patches every few weeks for a new FF release. We either can do patches or take new releases, doing both is just a maintenance nightmare. Since Fedora is all about doing stuff upstream, it sorts itself out better that way.
Well yes. Trademark is not the only reason obviously but I don't want to deviate the discussion more. Is Firefox 4 being considered for Fedora 14 or not?
Rahul
On Tue 27 July 2010 16:46:29 Rahul Sundaram wrote:
On 07/28/2010 05:09 AM, Christopher Aillon wrote:
On 07/28/2010 12:49 AM, Rahul Sundaram wrote:
Non upstreamed patches are not a option for
Firefox for trademark reasons as well.
Non upstreamed patches are not an option because it's a pain in the to have to update patches every few weeks for a new FF release. We either can do patches or take new releases, doing both is just a maintenance nightmare. Since Fedora is all about doing stuff upstream, it sorts itself out better that way.
Well yes. Trademark is not the only reason obviously but I don't want to deviate the discussion more. Is Firefox 4 being considered for Fedora 14 or not?
I'd be really bothered with shipping (beta) software where we are more or less at the mercy of our upstream wrt possible issues, bugs, etc. Yes, yes, yes, I'm probably going to get flamed for that, it's mozilla, we need to work with upstream, etc, etc, but would we put other (arguably) crit-path in this position, especially at GA? I'm all for Firefox 4, but shipping a Beta in which we are limited in what patches we can ship, this late in the release cycle, it just really bothers me.
Rahul
Ryan
2010/7/28 Rahul Sundaram metherid@gmail.com:
On 07/28/2010 03:33 AM, Brandon Lozza wrote:
Doesn't our version already support WebM?
Nope. We have updated Gstreamer and WebKit-Gtk in Fedora 13 and 12 for WebM support bringing it to Epiphany and Midori users and I assume Spot's Chromium repo users also have support for it but Firefox 4 will be the first stable version with WebM support built-in.
Epiphany is basically uselessin F13, see Bug 603358.
/Andreas
Rahul
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
I'm sure there'd be enough time to squeeze in FF4.0. Assuming there's no development delays with Mozilla.
Regards
-- http://home.comcen.com.au/foxmulder881/signature/details.html
Em 27-07-2010 18:53, Rahul Sundaram escreveu:
Hi,
Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released recently and I am wondering if we can go with it if it fits into the schedule. There are dozens of new features including WebM support that would be nice to have.
We was delayed in F-12 (two weeks) and in F-13 (two weeks), probably we'll have a final version for Firefox 4 before or a bit after we release F-14. Another thing, we can test a lot and assist in upstream during our testing phase. It's +1 for me.
On Tue, 27 Jul 2010, Filipe Rosset wrote:
Em 27-07-2010 18:53, Rahul Sundaram escreveu:
Hi,
Are we skipping Firefox 4 for Fedora 14? Beta 2 has been released recently and I am wondering if we can go with it if it fits into the schedule. There are dozens of new features including WebM support that would be nice to have.
We was delayed in F-12 (two weeks) and in F-13 (two weeks), probably we'll have a final version for Firefox 4 before or a bit after we release F-14. Another thing, we can test a lot and assist in upstream during our testing phase. It's +1 for me.
If Fedora didn't have stability issues I'd be all for it, but we do. And part of it is because we shoot from the hip with stuff like this. If Mozilla doesn't think it's ready yet, I don't know why we would think it is.
-Mike
On Tue, 2010-07-27 at 19:16 -0500, Mike McGrath wrote:
We was delayed in F-12 (two weeks) and in F-13 (two weeks), probably we'll have a final version for Firefox 4 before or a bit after we release F-14. Another thing, we can test a lot and assist in upstream during our testing phase. It's +1 for me.
If Fedora didn't have stability issues I'd be all for it, but we do. And part of it is because we shoot from the hip with stuff like this. If Mozilla doesn't think it's ready yet, I don't know why we would think it is.
I don't see why we can't just ship with 3.x and ship 4.0 as an update when it comes out (assuming it doesn't suck). Yes, Board stable updates vision and blah blah, but Firefox is something that people *will* go out and download the latest version of if you don't provide it for them. So I'd probably be happiest going that way.
(Having said that, I'm running 4.0b1 from upstream on one of my systems and it works absolutely fine...)
Mike McGrath wrote:
If Fedora didn't have stability issues I'd be all for it, but we do.
No we don't. Shipping almost-final releases and upgrading them to final ASAP is something we have successfully done for ages (including for Firefox). It has always worked out great.
And part of it is because we shoot from the hip with stuff like this.
Citation needed…
I don't see a problem in the first place, and even less how that particular practice would be causing one.
If Mozilla doesn't think it's ready yet, I don't know why we would think it is.
Because we're Fedora, not Ubuntu. Our very objectives are to ship the latest and greatest, and we shouldn't give that up just because of a few days of difference in schedules.
Why all this trend to destroy what Fedora is all about? If people want old, "tried" (but with bugs which are already fixed upstream and missing features which are already implemented upstream!) stuff, there are (and have always been) plenty of other distributions for them to choose from. Fedora should be different!
Kevin Kofler
2010/7/28 Filipe Rosset rosset.filipe@gmail.com:
We was delayed in F-12 (two weeks) and in F-13 (two weeks), probably we'll have a final version for Firefox 4 before or a bit after we release F-14. Another thing, we can test a lot and assist in upstream during our testing phase. It's +1 for me.
-- Filipe Rio Grande do Sul, Brazil --
Agree, shipping a RC version Firefox 4 for F14 is acceptable for me, F11 already shipped Firefox 3.5 beta4, it worked without any serious issues. I suggest to build Firefox 4 Beta for F15 shortly after F14 branched from Rawhide, if it works without any serious issues, then we can backport it to F14 Beta. Firefox 4 is definitely an amazing feature for Fedora 14.
Regard, Chen Lei
-
Adam Williamson -
Andreas Tunek -
Athmane Madjoudj -
Bill Nottingham -
Brandon Lozza -
Bruno Wolff III -
Chen Lei -
Chris Jones -
Christopher Aillon -
Dan Williams -
David Tardon -
drago01 -
Filipe Rosset -
Florent Le Coz -
Frank Murphy -
Gregory Maxwell -
Hans Ulrich Niedermann -
Haïkel Guémar -
James Findley -
Jesse Keating -
Julian Sikorski -
Kai Engert -
Kevin Fenzi -
Kevin Kofler -
Liang Suilong -
Martin Sourada -
Michel Alexandre Salim -
Mike McGrath -
Neal Gompa -
Nicu Buculei -
Orcan Ogetbil -
Paul W. Frields -
Peter Jones -
Peter Robinson -
Rahul Sundaram -
Remi Collet -
Ryan Rix -
Sam Varshavchik -
Seth Vidal -
Tom Callaway -
Toshio Kuratomi