7:46 p.m.
Hi,
I would like to start hosting omega as part of rpmfusion
infrastructure. A subdomain like omega.rpmfusion.org would be a good
space. Thoughts? Anyone testing the rawhide snapshots?
Rahul
11:35 p.m.
On Wed, Oct 8, 2008 at 9:46 PM, Rahul Sundaram <metherid(a)gmail.com> wrote:
Hi,
I would like to start hosting omega as part of rpmfusion infrastructure. A
subdomain like omega.rpmfusion.org would be a good space. Thoughts? Anyone
testing the rawhide snapshots?
I really appreciate the effort and the work done for this spin but
I'd really see a _clear_ discussion about that project before start
host anything (including the name of the future Official RPMFusion
spin).
--
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB
5:07 a.m.
Xavier Lamien wrote:
I really appreciate the effort and the work done for this spin but
I'd really see a _clear_ discussion about that project before start
host anything (including the name of the future Official RPMFusion
spin).
We have already been discussing the details including the name for a
while in this list. I am not sure who is equipped to make a final
decision but do that and let me know.
Rahul
3:50 p.m.
2008/10/9 Rahul Sundaram <metherid(a)gmail.com>:
Xavier Lamien wrote:
>
> I really appreciate the effort and the work done for this spin but
> I'd really see a _clear_ discussion about that project before start
> host anything (including the name of the future Official RPMFusion
> spin).
>
We have already been discussing the details including the name for a while
in this list. I am not sure who is equipped to make a final decision but do
that and let me know.
I think we could handle that like anything else:
submitting a review for this content, leading the ks for somehow
beeing imported in the cvs.
And this doesn't prevent the "feature" to be discussed (or even rejected).
But on the other side there are others case (mythdora, etc) it would
be valuable to have a sources repository for content where rpmfusion
is upstream. And then we can distribute a set of LiveMedia related .ks
files packaged with rpm.
This would split the question of the .ks distribution from the .iso
distribution.
What I don't like much with Omega, hosted here is that:
RPMFusion is defined as an additional repository for Fedora.
This means RPMFusion is not another distribution based on Fedora.
As a RPMFusion contributor. I still want to think I'm contributing to
Fedora via an additional repository, not a derived distro.
Knowing that, the only official iso from RPMFusion would be (IMO) an
additional set of packages composed as a local repository aimed for
post installation.
(which remains untested/unworked until then).
That would be the solution I would see to get pushed.
Why I see Omega as uneeded is that:
When using an official Fedora LiveCD iso, you can still transfert it
on a USB disk/key and activate persistence.
That way you can add some packages from rpmfusion suitable for codec etc.
But everything else fall under a customization process where there are
million of possibilities.
At this time Omega doesn't sort out why some packages are choosen and
not others.
That been said. I see also some interest in Omega.
- When end-users want to make customized livecd from either
rpmfusion_nonfree or rpmfusion_free,
the default will be to use fedora as the name for the distro which
will lead the redistribution of their media to be illegal.(IANAL).
it would be valuable to document how to create an Omega "like" LiveCD
knowing that it will contains package from RPMFusion.
I would prefer to have this kind of QA done here, with the help of
each RPMFusion owner of package (and coordinators); than from
downstream integrator.
- There is a full world of options to make a LiveCD... But we can have
a common set of packages that will fit the needs for most usage.
That way, unexperienced users can experience mp3 support out of the LiveCD.
Maybe the side effect for this feature would be to deactivate the
install to disk. So we don't ends with systems installed on harddisk
as Omega. And Omega will stay a Live system (only).
In my mind, I see Omega as a demonstration purpose and not a everyday
life distro. that's why I see the distribution of the resulting ISO as
an optional thing (but indeed, sometime needed, mostly for beginner).
So, maybe the iso can be made available via bittorrent eventually.
And I would like to see a page somewhere that describe the Omega
LiveCD (goals, and howto re-create).
Something like http://omega.rpmfusion.org/ or else ...
Nicolas (kwizart)
Rahul
5:24 p.m.
KH KH wrote:
What I don't like much with Omega, hosted here is that:RPMFusion
is
defined as an additional repository for Fedora.This means RPMFusion is
not another distribution based on Fedora.
As a RPMFusion contributor. I still want to think I'm contributing to
Fedora via an additional repository, not a derived distro.
If you are not
interested in Omega, you can continue to contribute to just RPMFusion packaging. Omega
would just be a sub project that you are not involved in, which is just fine. A rpmfusion
spin was discussed in this list before and my efforts are directly in response to that.
Although, if the consensus now is that you don't want a live cd at all, I can host it
elsewhere. I would like to hear other's opinions on this.
Knowing that, the only official iso from RPMFusion would be (IMO) an
additional set of packages composed as a local repository aimed for
post installation.
(which remains untested/unworked until then).
That would be the solution I would see to get pushed.
These two different solutions cannot be done in parallel. There are
different use cases for both.
Why I see Omega as uneeded is that:
When using an official Fedora LiveCD iso, you can still transfert it
on a USB disk/key and activate persistence.
That way you can add some packages from rpmfusion suitable for codec etc.
But everything else fall under a customization process where there are
million of possibilities.
There are many reasons where a distributable live cd (especially
combined with regular updated revisions) could be more convenient. That
is validated by the amount of downloads and positive feedback I have
been getting overall. Not everybody has the bandwidth, expertise or
interest to do additional customizations. Even if they do, this can
still be a better starting point for them.
At this time Omega doesn't sort out why some packages are choosen
and
not others.
From the discussions in this list, the consensus was that only
packages from the free repository should be included. I posted a
kickstart file with the typical set of packages that a end user would
install and then proceeded to create a image based on that. If there is
a different set of packages that needs to be installed, that is very
open for discussions. I have been asking for feedback often.
In my mind, I see Omega as a demonstration purpose and not a
everyday
life distro. that's why I see the distribution of the resulting ISO as
an optional thing (but indeed, sometime needed, mostly for beginner).
So, maybe the iso can be made available via bittorrent eventually.
Without the resulting ISO being widely distributed and tested, we
wouldn't know whether it worked or not. As I started using the tools to
generate the Live CD, I have run into several issues which are being
resolved iteratively. The result is useful for other derivative
distributions that are going to consume bits from Fedora as well as
RPMFusion.
And I would like to see a page somewhere that describe the Omega
LiveCD (goals, and howto re-create).
Something like http://omega.rpmfusion.org/ or else ...
Sure.
Rahul
10:52 a.m.
On 09.10.2008 07:07, Rahul Sundaram wrote:
Xavier Lamien wrote:
> I really appreciate the effort and the work done for this spin but
> I'd really see a _clear_ discussion about that project before start
> host anything (including the name of the future Official RPMFusion
> spin).
+1
One other important things for example was not discussed properly iirc:
Do we want one or two official spins? I'd say (at least in the long
term) two: one with only free packages and one that also includes
nonfree packages.
That of course will complicated the naming again. Same name with suffix
or different names for the spins?
We have already been discussing the details including the name for a
while in this list.
Please point me to that discussion. As far as I remember and from
searching "omega site:lists.rpmfusion.org" it was you who came up with
the name; there was not even a proper discussion (and thus no consensus).
I am not sure who is equipped to make a final
decision but do that and let me know.
There was the idea of a steering committee (see wiki), but most of the
time in the past weeks we afaics (round about) worked simply discussed
things in public on the list and simply realized them a bit later if
there was a consensus (e.g. if nobody yelled loudly). That way everybody
can influence the decisions.
Cu
knurd
8:22 p.m.
Thorsten Leemhuis wrote:
Please point me to that discussion. As far as I remember and from
searching "omega site:lists.rpmfusion.org" it was you who came up with
the name; there was not even a proper discussion (and thus no consensus).
I posted
to the list earlier, asking for naming suggestions (suggested
freefusion earlier but that name ran into potential trademark issues)
and didn't get much of it and went ahead with a name I picked. It is
always a open possibility if you want to insist on another name. Feel
free to suggestion alternatives and find consensus. Meanwhile the
feedback from the images I have put out (outside this list) already has
helped improved things quite a bit.
> I am not sure who is equipped to make a final decision but do
that
> and let me know.
There was the idea of a steering committee (see wiki), but most of the
time in the past weeks we afaics (round about) worked simply discussed
things in public on the list and simply realized them a bit later if
there was a consensus (e.g. if nobody yelled loudly). That way
everybody can influence the decisions.
Question is: How do we progress now since
there doesn't seem to be a
committee doing decisions at the moment? I would ask you or anyone else
to make a decision and be done with it. If you want to form a committee
and make such decisions in the future, that's probably a good thing
since consensus on the list isn't always going to work especially if the
amount of discussions in low.
Rahul
7:32 a.m.
On 11.10.2008 22:22, Rahul Sundaram wrote:
Thorsten Leemhuis wrote:
> Please point me to that discussion. As far as I remember and from
> searching "omega site:lists.rpmfusion.org" it was you who came up with
> the name; there was not even a proper discussion (and thus no consensus).
I posted to the list earlier, asking for naming suggestions (suggested
freefusion earlier but that name ran into potential trademark issues)
and didn't get much of it and went ahead with a name I picked.
And exactly that "I" in "went ahead with a name I picked" IMHO is
totally unacceptable in a *community* project when it comes to important
issues (like releasing and branding a new spin; just imagine what had
happened if "I" (me in this context) would have simply imported all
kmods from livna months ago without asking somebody else ahead of
time!). If that is done to often then sooner or later we will be forced
to route all the important decisions through the steering committee.
That is what I (and likely others from what I see) really want to avoid
as that quickly results in a lot of bureaucracy overhead and slows
things down.
You could have had a way easier life and wouldn't have made some people
upset if you would have announced on the list "okay, we didn't come up a
name in the last decisions; I chose omega now and I'm preparing a beta;
if you dislike that name then please yell over the next weeks, then I'll
just use that name in public". That would have given people a chance to
speak up and stop or adjust things before they are set in stone. And
that's one of the most important factors in a community project IMHO:
Give people a chance to influence before it's to late, otherwise some
members of the community will be unhappy.
[...]
>> I am not sure who is equipped to make a final decision but do that
>> and let me know.
> There was the idea of a steering committee (see wiki), but most of the
> time in the past weeks we afaics (round about) worked simply discussed
> things in public on the list and simply realized them a bit later if
> there was a consensus (e.g. if nobody yelled loudly). That way
> everybody can influence the decisions.
Question is: How do we progress now since there doesn't seem to be a
committee doing decisions at the moment?
There is one (it's a bit rough and loose and we need to work out
something better soon) -- we just try hard to avoid using it. It's even
linked right on the first page in the wiki:
http://rpmfusion.org/SteeringCommittee
But I really prefer a "those who invested the most work in the project
make the decisions" approach. That for example includes Xavier (who did
a lot of work on the infra), hence he was involved in the kmod decision.
I also consider Dominik and some others that own crucial packages kind
of members of a "core contributor group"; if one of them would had said
"no, kmods are bad, let's do this and that" then I would have said
"let's wait with the kmods for now and discuss this further to find an
agreement before moving on".
I would ask you or anyone else
to make a decision and be done with it.
Parts of my mind think: Omega is well known by now so just use that.
Other parts say: Why can't we simply use the name RPM Fusion together
with the Free and Nonfree suffixes? That will make it obvious what this
is about.
Which of the two wins depends on the answers to question that were in
the mail you replied to. But you for some reasons avoided to answer
them. So here it is again:
> One other important thing that was not discussed properly iirc:
> Do we want one or two official spins? I'd say (at least in the long
> term) two: one with only free packages and one that also includes
> nonfree packages.
Just a addition note: even if we do one spin now (e.g. only with free
packages) I'll bet we'll soon face the situation where someone wants to
do a nonfree spin. Hence I think we should prepare for that:
> That of course will complicated the naming again. Same name with
suffix
> or different names for the spins?
Cu
knurd
8:37 a.m.
Thorsten Leemhuis wrote:
And exactly that "I" in "went ahead with a name I
picked" IMHO is
totally unacceptable in a *community* project
I can't force people to give me
feedback. I did ask for suggestions
before picking one. I did post the kickstart file as well for people to
give input on the content and got zero feedback. Since you seem to be in
agreement for the general idea of letting people doing the work making
the decisions, in this case, that would be me. I don't really see the
name choices as a big deal. I got work done and there was many things
fixed for the benefit of everybody. Again, feel free to suggest
alternative names (if there are strong opinions on that) or any content
changes. I have carefully considered all the comments on those. If there
is general consensus on anything such as not making even small
configuration changes, I have went along with that.
Which of the two wins depends on the answers to question that were in
the mail you replied to. But you for some reasons avoided to answer
them. So here it is again:
>> One other important thing that was not discussed properly iirc: Do
>> we want one or two official spins? I'd say (at least in the long
>> term) two: one with only free packages and one that also includes
>> nonfree packages
The reason why I picked a different name (I have mentioned
this in the
list before) is because longer names as RPMFusion - free repository spin
is unlikely to catch on. You really need something short and unique. I
skipped the other question before because I didn't realize this question
was directed at me and assumed you were asking for general opinion from
others. I am personally uninterested in working on even more variants.
It takes a lot of time to compose and test packages especially when it
has to be done against a moving target like rawhide especially since I
am following the Fedora release schedule aggressively - beta, snapshots
et all. More importantly, the only common things people want from the
non-free repository would be kernel drivers which are hardware specific
and cannot be bundled together or installed by default (no package
selection possible in live cd) without running into legal as well as
technical issues.
Distributions which tried to do that in the past have backed off for
good reasons.
http://en.wikipedia.org/wiki/Kororaa#Kororaa_XGL_Live_CD_and_the_GPL
http://news.softpedia.com/news/Ubuntu-7-04-Will-Not-Include-Proprietary-V...
(The second article is about default configuration. Not what is
available in the repository)
As I mentioned here before, the right solution IMO would be to use
something like Jockey (https://launchpad.net/jockey). It is a better
because it is opt-in and generic, lets the user pick and avoids the
issues mentioned above. If it works well, it should be part of the
rpmfusion repository and installed by default in Omega potentially. Is
anyone willing to look into that?
Rahul
9:35 a.m.
On 12.10.2008 10:37, Rahul Sundaram wrote:
Thorsten Leemhuis wrote:
> And exactly that "I" in "went ahead with a name I picked" IMHO is
> totally unacceptable in a *community* project
I can't force people to give me feedback. I did ask for suggestions
before picking one.
You imho definitely should have asked for feedback again *after* picking
a name and *before* using it in public.
I did post the kickstart file as well for people to
give input on the content and got zero feedback.
That doesn't mean that nobody is interested. Especially as some people
are quite busy getting RPM Fusion running first.
Since you seem to be in
agreement for the general idea of letting people doing the work making
the decisions, in this case, that would be me.
Then you spin is imho your spin and is no community or RPM Fusion
effort. But you, I and some other people afaics want your work to be a
RPM Fusion effort; so all I'm asking you (and that's why I'm investing
time in this discussion): Please be a bit more careful in the future and
give people a chance to influence things before you start putting them
in stone (which you imho did).
I don't really see the
name choices as a big deal. I got work done and there was many things
fixed for the benefit of everybody.
Someone that "got work done [...] for the benefit of everybody" was
round about the argument in the early livna days afaik. If that someone
back then would have been a bit more careful then freshrpms and livna
could have been one right from the start (that how I got the story told
by people I trust).
[...]
> Which of the two wins depends on the answers to question that were in
> the mail you replied to. But you for some reasons avoided to answer
> them. So here it is again:
>>> One other important thing that was not discussed properly iirc: Do
>>> we want one or two official spins? I'd say (at least in the long
>>> term) two: one with only free packages and one that also includes
>>> nonfree packages
The reason why I picked a different name (I have mentioned this in the
list before) is because longer names as RPMFusion - free repository spin
is unlikely to catch on.
Not sure if I agree or not.
You really need something short and unique.
Sounds like a definite fact, but that's just your option. Other might
disagree with it. Please give those a chance to express their option
next time. That all I'm asking you.
I skipped the other question before because I didn't realize this
question
was directed at me and assumed you were asking for general opinion from
others. I am personally uninterested in working on even more variants.
I'm quite sure other will.
It takes a lot of time to compose and test packages especially when
it
has to be done against a moving target like rawhide especially since I
am following the Fedora release schedule aggressively - beta, snapshots
et all. More importantly, the only common things people want from the
non-free repository would be
There are lots of other interesting packages in nonfree (and hopefully
even more in the future). If someone for example wants to do a "RPM
Fusion Games Spin", then he likely want to include games from the
nonfree repo.
BTW, I'm quite sure some people will actually say that
ftp://ftp.infradead.org/pub/spins/omega-livecd-desktop-rawhide.ks
is a nonfree spin, as has one package from the nonfree repo:
rpmfusion-nonfree-release. That makes the nonfree packages available and
thus that spin is likely not a "free" spin in some peoples eyes (even if
it doesn't directly use any nonfree packages).
kernel drivers which are hardware specific
and cannot be bundled together or installed by default (no package
selection possible in live cd) without running into legal as well as
technical issues.
Distributions which tried to do that in the past have backed off for
good reasons. [...]
But the most well known linux distribution that gets a lot of public
attention gets away with it, so with similar tricks it might be possible
for us as well. But that would need closer evaluation and is a
complicated different topic we should ignore for now.
As I mentioned here before, the right solution IMO would be to use
something like Jockey (https://launchpad.net/jockey). It is a better
because it is opt-in and generic, lets the user pick and avoids the
issues mentioned above. If it works well, it should be part of the
rpmfusion repository and installed by default in Omega potentially. Is
anyone willing to look into that?
Steward afaics is looking into something similar; both of us afaics
pointed him to Jockey. But if it's wise to use Jockey or something else
afaics still needs closer evaluation.
Anyway, we should stop this discussion and do something productive. So
here are my suggestions:
(a) use "RPM Fusion" and prefix for all official spins (Just like Fedora
project uses the name Fedora for its spins) ; a "RPM Fusion Spin" (using
the kickstart file from omega as base) will be the first and official
spin that has both the free and nonfree repos enabled; this naming
scheme leaves room for other spins under the hood of RPM Fusion:
* "RPM Fusion Free" (only free; nonfree repo not even enabled);
* "RPM Fusion Games" (games from Fedora, RPM Fusion free/nonfree)
* "RPM Fusion foo" (whatever people want to do)
(b) just like "(a)", but only that we use "Omega" as the name for the
"official spin"; all others use "RPM Fusion" and prefix
(c) Just like "(a)", but use Omega as prefix everywhere
(d) your suggestion here
BTW, you at the start of this thread said:
I would like to start hosting omega as part of rpmfusion
infrastructure. A subdomain like omega.rpmfusion.org would be a good
space.
I more and more think we should not so that. A spins.rpmfusion.org
should do the trick in the long term and could provide informations for
all active spins (and not only one).
And BTW, the directory layout for RPM Fusion closely replicates the one
from Fedora. Thus the proper place for the official RPM Fusion spin iso
imho would be something like that:
http://download1.rpmfusion.org/nonfree/fedora/releases/9/Live/i686/RPMFus...
(to compare, the official Fedora spin can be found at:
http://download.fedora.redhat.com/pub/fedora/linux/releases/9/Live/i686/F...
)
Cu
knurd
10:29 a.m.
Thorsten Leemhuis wrote:
But the most well known linux distribution that gets a lot of public
attention gets away with it, so with similar tricks it might be
possible for us as well. But that would need closer evaluation and is
a complicated different topic we should ignore for now.
No distribution ships
proprietary drivers bundled and linked by default
(like a live cd would) to the best of my knowledge. If you let the user
make the final step, then it is different. I am not sure which
distribution you are referring to here. I suspect you are talking about
Ubuntu. In that case, you should look more closely at what they are
doing. I don't want to play dirty tricks on a already troublesome legal
grey area even if we can get away with it.
Anyway, we should stop this discussion and do something productive.
Sounds like a good idea to me :-)
So here are my suggestions:
(a) use "RPM Fusion" and prefix for all official spins (Just like
Fedora project uses the name Fedora for its spins) ; a "RPM Fusion
Spin" (using the kickstart file from omega as base) will be the first
and official spin that has both the free and nonfree repos enabled;
this naming scheme leaves room for other spins under the hood of RPM
Fusion:
* "RPM Fusion Free" (only free; nonfree repo not even enabled);
* "RPM Fusion Games" (games from Fedora, RPM Fusion free/nonfree)
* "RPM Fusion foo" (whatever people want to do)
(b) just like "(a)", but only that we use "Omega" as the name for the
"official spin"; all others use "RPM Fusion" and prefix
(c) Just like "(a)", but use Omega as prefix everywhere
(d) your suggestion here
I don't think using the "spin" naming
convention is a good idea for
trademark reasons. The new trademark guidelines for Fedora proposed at
https://fedoraproject.org/wiki/User:Pfrields/NewTrademarkGuidelines
differentiates between a spin and a remix. If you believe, that other
variants are going to be made available and they need to be in the same
space (separate sub domains are a possibility), instead of a omega
subdomain, you could setup a remix subdomain instead. RPMFusion is
going to be providing packages for EL distributions as well. Someone
might have an interest in creating a remix around that. So to be
specific, you will get a name like - RPMFusion spin - free repository
for Fedora (GNOME edition) or something like that which tends to be
clumsy. I am also in favour of associating Omega with the Fedora brand
since it is the primary project after all. So in the future, we can do
something like
* Omega - Fedora multimedia remix
The proposed more liberal rules around the secondary mark for Fedora
remixes which I am keeping a close eye on will likely allow this
possibility. This is the reason I suggested the word "remix" in the
conversation which has been accepted by Red Hat Legal. It seems we are
close to getting the above guidelines finalized - certainly before the
Fedora 10 GA release. I will apply for approval if necessary and go
through the due process to get this done.
Rahul
11:19 a.m.
On 12.10.2008 12:29, Rahul Sundaram wrote:
Thorsten Leemhuis wrote:
> But the most well known linux distribution that gets a lot of public
> attention gets away with it, so with similar tricks it might be
> possible for us as well. But that would need closer evaluation and is
> a complicated different topic we should ignore for now.
No distribution ships proprietary drivers bundled and linked by default
[...]
I know; but as I said: it's a complicated different topic we should
ignore for now.
> So here are my suggestions:
>
> (a) use "RPM Fusion" and prefix for all official spins (Just like
> Fedora project uses the name Fedora for its spins) ; a "RPM Fusion
> Spin" (using the kickstart file from omega as base) will be the first
> and official spin that has both the free and nonfree repos enabled;
> this naming scheme leaves room for other spins under the hood of RPM
> Fusion:
>
> * "RPM Fusion Free" (only free; nonfree repo not even enabled);
>
> * "RPM Fusion Games" (games from Fedora, RPM Fusion free/nonfree)
>
> * "RPM Fusion foo" (whatever people want to do)
>
> (b) just like "(a)", but only that we use "Omega" as the name for
the
> "official spin"; all others use "RPM Fusion" and prefix
>
> (c) Just like "(a)", but use Omega as prefix everywhere
>
> (d) your suggestion here
I don't think using the "spin" naming convention is a good idea for
trademark reasons.
I doubt that "spins" can be protected, as it's afaics a generic word.
The new trademark guidelines for Fedora proposed at
https://fedoraproject.org/wiki/User:Pfrields/NewTrademarkGuidelines
differentiates between a spin and a remix.
That is just the definition for that document afaics ("Hereinafter,
"Spin" refers to a combination on[...]"). Sure, we could consider
following that terminology. But "RPM Fusion Games Spin (a Fedora remix)"
IMHO is a nice description with term people are used to. But maybe we
should just ask Paul or FAB for options.
If you believe, that other
variants are going to be made available and they need to be in the same
space (separate sub domains are a possibility), instead of a omega
subdomain, you could setup a remix subdomain instead.
Not sure if that's wroth setting up an additional domain; the main spins
from Fedora are also just served in the usual repo path (
http://spins.fedoraproject.org/ for example doesn't contain the Live or
KDE spin). I'd say RPM Fusion should follow that example.
RPMFusion is
going to be providing packages for EL distributions as well. Someone
might have an interest in creating a remix around that. So to be
specific, you will get a name like - RPMFusion spin - free repository
for Fedora (GNOME edition) or something like that which tends to be
clumsy.
Leave some words out, rearrange some other and you have a nice name that
properly describes what it is and where it comes from:
RPM Fusion GNOME Spin
or
RPM Fusion GNOME Spin (Fedora reminx)
[...]
The proposed more liberal rules around the secondary mark for Fedora
remixes which I am keeping a close eye on will likely allow this
possibility. This is the reason I suggested the word "remix" in the
conversation which has been accepted by Red Hat Legal. It seems we are
close to getting the above guidelines finalized - certainly before the
Fedora 10 GA release. I will apply for approval if necessary and go
through the due process to get this done.
Many thanks for your work in that area!
Cu
knurd
11:39 a.m.
Thorsten Leemhuis wrote:
> I don't think using the "spin" naming convention is
a good idea for
> trademark reasons.
I doubt that "spins" can be protected, as it's afaics a generic word.
Fedora or even Windows is a generic word as well. For trademarks,
context matters a lot. Also see below.
> The new trademark guidelines for Fedora proposed at
> https://fedoraproject.org/wiki/User:Pfrields/NewTrademarkGuidelines
> differentiates between a spin and a remix.
That is just the definition for that document afaics ("Hereinafter,
"Spin" refers to a combination on[...]"). Sure, we could consider
following that terminology. But "RPM Fusion Games Spin (a Fedora
remix)" IMHO is a nice description with term people are used to. But
maybe we should just ask Paul or FAB for options.
My point is that since this
effort is closely associated with Fedora,
following the naming convention in there leaves less room for confusion.
I am probably going to be approaching FAB as part of the trademark
process anyway.
> If you believe, that other variants are going to be made
available
> and they need to be in the same space (separate sub domains are a
> possibility), instead of a omega
> subdomain, you could setup a remix subdomain instead.
Not sure if that's wroth setting up an additional domain; the main
spins from Fedora are also just served in the usual repo path (
http://spins.fedoraproject.org/ for example doesn't contain the Live
or KDE spin). I'd say RPM Fusion should follow that example.
The current notion
is that because Live or KDE images go through
release engineering, they aren't classified as spins. They are in
torrent.fp.o instead. I don't think we have a comparable situation
here. I would still vouch for using either Omega or remix for the sub
domain name and stick to Omega for the remix name itself. Again, we have
new trademark guidelines coming up with a secondary mark that we can
take advantage of, quite nicely.
https://fedoraproject.org/wiki/User:Pfrields/Secondary_trademark_design
Piggy backing on the already well established Fedora brand would help us
a lot here.
Rahul
10:35 a.m.
On Sun October 12 2008, Thorsten Leemhuis wrote:
And exactly that "I" in "went ahead with a name I
picked" IMHO is
totally unacceptable in a *community* project when it comes to important
issues (like releasing and branding a new spin; just imagine what had
happened if "I" (me in this context) would have simply imported all
kmods from livna months ago without asking somebody else ahead of
time!). If that is done to often then sooner or later we will be forced
Parts of my mind think: Omega is well known by now so just use that.
Other parts say: Why can't we simply use the name RPM Fusion together
with the Free and Nonfree suffixes? That will make it obvious what this
is about.
Was Omega promoted as the official RPMFusion spin anywhere? I cannot see
anything that implies this in the announcement of fedora-annouce:
https://www.redhat.com/archives/fedora-announce-list/2008-September/msg00...
Eearlier also Orange Sombrero was announced there:
https://www.redhat.com/archives/fedora-announce-list/2008-September/msg00...
Afaik it is one important feature of Fedora to allow people to freely remix
the contents and add stuff to create customs spins / live media. For Fedora
the only Guideline is, that it must not called Fedora, if it does contains
packages that are not from Fedora.
Regards,
Till
10:30 p.m.
On Sat October 11 2008, Thorsten Leemhuis wrote:
On 09.10.2008 07:07, Rahul Sundaram wrote:
> We have already been discussing the details including the name
for a
> while in this list.
Please point me to that discussion. As far as I remember and from
searching "omega site:lists.rpmfusion.org" it was you who came up with
the name; there was not even a proper discussion (and thus no consensus).
How do you want to enforce such a discussion? It was mentioned here now
several times and I did not remember any objections except from you and no
alternative naming ideas. I guess the majority does not care about the name
or agree to it. I think it's a nice name, but I also do not care much.
Regards,
Till
10:37 a.m.
On Wed October 8 2008, Rahul Sundaram wrote:
I would like to start hosting omega as part of rpmfusion
infrastructure. A subdomain like omega.rpmfusion.org would be a good
space. Thoughts? Anyone testing the rawhide snapshots?
I suggest to use spins.rpmfusion.org or rpmfusion.org/spins.
This allows to host several different spins, e.g. a game live medium.
Regards,
Till
5810
days inactive
5814
days old
rpmfusion-developers@lists.rpmfusion.org
15 comments
5 participants
participants (5)
-
Nicolas Chauvet -
Rahul Sundaram -
Thorsten Leemhuis -
Till Maas -
Xavier Lamien