4:53 p.m.
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
5:02 p.m.
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
--
Athmane Madjoudj
5:03 p.m.
Doesn't our version already support WebM?
On Tue, Jul 27, 2010 at 5:53 PM, Rahul Sundaram <metherid(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
5:08 p.m.
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
5:08 p.m.
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
5:09 p.m.
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
5:11 p.m.
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
5:24 p.m.
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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
5:34 p.m.
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.
--
Filipe
Rio Grande do Sul, Brazil
5:36 p.m.
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.
5:49 p.m.
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
6:29 p.m.
On Tue, Jul 27, 2010 at 11:08 PM, Mike McGrath <mmcgrath(a)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
6:31 p.m.
On 7/27/10, Rahul Sundaram <metherid(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
what about iceweasel or icefox instead
the trademark problem makes it non free
6:33 p.m.
On Tue, Jul 27, 2010 at 6:31 PM, Brandon Lozza <brandon(a)pwnage.ca> wrote:
On 7/27/10, Rahul Sundaram <metherid(a)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(a)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(a)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.
6:39 p.m.
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.
6:45 p.m.
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
6:46 p.m.
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
7:16 p.m.
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
10:09 p.m.
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
--
Ryan Rix
== http://hackersramblings.wordpress.com | http://rix.si/ ==
== http://rix.si/page/contact/ if you need a word ==
12:05 a.m.
2010/7/28 Filipe Rosset <rosset.filipe(a)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
1:57 a.m.
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/
5:45 a.m.
On Wed, Jul 28, 2010 at 2:57 AM, Nicu Buculei <nicu_fedora(a)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(a)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.
5:49 a.m.
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
5:52 a.m.
On Wed, Jul 28, 2010 at 6:49 AM, Rahul Sundaram <metherid(a)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(a)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.
5:55 a.m.
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
5:59 a.m.
On Wed, Jul 28, 2010 at 12:52 PM, Brandon Lozza <brandon(a)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.
6:01 a.m.
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.
6:53 a.m.
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
7:17 a.m.
On Wed, Jul 28, 2010 at 6:55 AM, Rahul Sundaram <metherid(a)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.
7:27 a.m.
On 07/28/2010 05:47 PM, Brandon Lozza wrote:
On Wed, Jul 28, 2010 at 6:55 AM, Rahul Sundaram
<metherid(a)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
7:50 a.m.
On Wed, Jul 28, 2010 at 8:27 AM, Rahul Sundaram <metherid(a)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(a)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(a)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.
7:52 a.m.
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
8:04 a.m.
On Wed, Jul 28, 2010 at 8:57 AM, Frank Murphy <frankly3d(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
+1
It should be in updates-testing
8:04 a.m.
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
8:28 a.m.
2010/7/28 Frank Murphy <frankly3d(a)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
8:41 a.m.
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
8:53 a.m.
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(a)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,
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: 78884778
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
8:55 a.m.
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
9:20 a.m.
2010/7/28 Rahul Sundaram <metherid(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
9:40 a.m.
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
9:51 a.m.
On Wed, Jul 28, 2010 at 10:40 AM, Martin Sourada
<martin.sourada(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
There is also plugin compatibility . Newer != better
10:37 a.m.
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.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
Where open source multiplies: http://opensource.com
11:44 a.m.
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...)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:59 a.m.
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.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:06 p.m.
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. =)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:10 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:13 p.m.
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
12:17 p.m.
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxQZhkACgkQ4v2HLvE71NWaqgCfaUhloxcOP16OEMtmi3IpQLl8
ZqcAnRdP3q/DUQW0N/deazJw4JjyKjl1
=3cND
-----END PGP SIGNATURE-----
12:20 p.m.
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
1:10 p.m.
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.
--
Peter
Old MacDonald had an agricultural real-estate tax abatement.
01234567890123456789012345678901234567890123456789012345678901234567890123456789
1:25 p.m.
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
1:42 p.m.
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.
--
Peter
I number the Linux folks among my personal heroes.
-- Donald Knuth
01234567890123456789012345678901234567890123456789012345678901234567890123456789
1:42 p.m.
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
1:48 p.m.
On Wed, Jul 28, 2010 at 8:42 PM, Mike McGrath <mmcgrath(a)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 ;)
2:12 p.m.
On Wed, 28 Jul 2010, drago01 wrote:
On Wed, Jul 28, 2010 at 8:42 PM, Mike McGrath
<mmcgrath(a)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
2:16 p.m.
On Wed, Jul 28, 2010 at 9:12 PM, Mike McGrath <mmcgrath(a)redhat.com> wrote:
On Wed, 28 Jul 2010, drago01 wrote:
> On Wed, Jul 28, 2010 at 8:42 PM, Mike McGrath <mmcgrath(a)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.
2:37 p.m.
New subject: coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]
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
2:49 p.m.
New subject: coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]
On Wed, Jul 28, 2010 at 9:37 PM, seth vidal <skvidal(a)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:
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.
5. Some easy way to enable/disable such repos other than messing with
config files?
2:51 p.m.
New subject: coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]
On Wed, 2010-07-28 at 21:49 +0200, drago01 wrote:
On Wed, Jul 28, 2010 at 9:37 PM, seth vidal
<skvidal(a)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:
>
> 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.
5. Some easy way to enable/disable such repos other than messing with
config files?
yum-config-manager --enable repo1 repo2 repo3
-sv
2:57 p.m.
New subject: coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]
On 28/07/10 20:49, drago01 wrote:
5. Some easy way to enable/disable such repos other than messing with
config files?
gnome-packagekit-extra
tick what you need.
--
Regards,
Frank Murphy
UTF_8 Encoded
Friend of Fedora
3:12 p.m.
New subject: coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]
On Wed, Jul 28, 2010 at 9:51 PM, seth vidal <skvidal(a)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(a)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:
> >
> > 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.
>
> 5. 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)
3:14 p.m.
New subject: coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]
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
3:47 p.m.
On Wed, Jul 28, 2010 at 2:16 PM, drago01 <drago01(a)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.
3:58 p.m.
On 07/28/2010 04:47 PM, Conan Kudo (ニール・ゴンパ) wrote:
On Wed, Jul 28, 2010 at 2:16 PM, drago01 <drago01(a)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
4:28 p.m.
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(a)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
4:38 p.m.
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
5 p.m.
On Wed, Jul 28, 2010 at 4:38 PM, Adam Williamson <awilliam(a)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.
5:10 p.m.
New subject: coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]
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:
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.
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
5:11 p.m.
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
5:13 p.m.
On Wed, Jul 28, 2010 at 17:00:01 -0500,
"Conan Kudo (ニール・ゴンパ)" <ngompa13(a)gmail.com> wrote:
On Wed, Jul 28, 2010 at 4:38 PM, Adam Williamson
<awilliam(a)redhat.com>wrote:
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".
5:15 p.m.
Orcan Ogetbil (oget.fedora(a)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
9:24 p.m.
2010/7/29 Conan Kudo (ニール・ゴンパ) <ngompa13(a)gmail.com>:
On Wed, Jul 28, 2010 at 4:38 PM, Adam Williamson
<awilliam(a)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
12:03 a.m.
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.
1:20 a.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:31 a.m.
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(a)redhat.com>wrote:
On 07/28/2010 04:47 PM, Conan Kudo (ニール・ゴンパ) wrote:
> On Wed, Jul 28, 2010 at 2:16 PM, drago01 <drago01(a)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(a)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
1:41 a.m.
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
1:57 a.m.
On Wed, Jul 28, 2010 at 4:37 PM, Paul W. Frields <stickster(a)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
2:21 a.m.
New subject: coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]
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(a)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(a)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
4:23 a.m.
On 07/28/2010 11:13 PM, Bruno Wolff III wrote:
On Wed, Jul 28, 2010 at 17:00:01 -0500,
"Conan Kudo (ニール・ゴンパ)"<ngompa13(a)gmail.com> wrote:
> On Wed, Jul 28, 2010 at 4:38 PM, Adam Williamson<awilliam(a)redhat.com>wrote:
>
> 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.
10 a.m.
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
4:46 p.m.
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
7:20 p.m.
New subject: coprs and personal repos: [Was: Re: Firefox 4 for Fedora 14?]
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(a)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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
4:48 a.m.
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
8:17 a.m.
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
10:10 a.m.
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
10:25 a.m.
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
10:28 a.m.
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
10:30 a.m.
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
10:33 a.m.
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
10:36 a.m.
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
10:37 a.m.
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
10:38 a.m.
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
10:41 a.m.
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
10:49 a.m.
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
10:51 a.m.
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
10:52 a.m.
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
10:53 a.m.
On Fri, Jul 30, 2010 at 5:51 PM, Tom "spot" Callaway
<tcallawa(a)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" ?
11:33 a.m.
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
11:35 a.m.
On Fri, Jul 30, 2010 at 6:33 PM, Rahul Sundaram <metherid(a)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 ...
11:39 a.m.
Rahul Sundaram (metherid(a)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
11:49 a.m.
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
11:50 a.m.
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.
11:51 a.m.
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
11:54 a.m.
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
12:20 p.m.
Rahul Sundaram (metherid(a)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
12:30 p.m.
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
12:58 p.m.
Rahul Sundaram (metherid(a)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
1:15 p.m.
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
1:22 p.m.
On Fri, Jul 30, 2010 at 1:30 PM, Rahul Sundaram <metherid(a)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.
1:26 p.m.
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
2:01 p.m.
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
2:11 p.m.
On Fri, Jul 30, 2010 at 2:01 PM, Rahul Sundaram <metherid(a)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.
2:11 p.m.
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
2:12 p.m.
On Fri, Jul 30, 2010 at 2:11 PM, seth vidal <skvidal(a)fedoraproject.org>wrote:
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.
2:13 p.m.
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
2:13 p.m.
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.
-sv
Out 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
2:17 p.m.
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
2:18 p.m.
On Fri, Jul 30, 2010 at 2:13 PM, seth vidal <skvidal(a)fedoraproject.org>wrote:
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.
>
> -sv
>
>
>
>
>
>
> Out 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
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.
2:19 p.m.
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
2:21 p.m.
On 07/31/2010 12:43 AM, seth vidal wrote:
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.
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
2:22 p.m.
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.
--
Regards,
Frank Murphy
UTF_8 Encoded
Friend of Fedora
2:24 p.m.
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:
> 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.
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
2:26 p.m.
On Fri, Jul 30, 2010 at 2:17 PM, Rahul Sundaram <metherid(a)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.
2:28 p.m.
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
2:30 p.m.
On Fri, 30 Jul 2010, Conan Kudo (ニール・ゴンパ) wrote:
On Fri, Jul 30, 2010 at 2:17 PM, Rahul Sundaram
<metherid(a)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
4:51 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:55 a.m.
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
1:37 p.m.
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
5020
days inactive
5026
days old
134 comments
41 participants
participants (41)
-
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