Hi,
Now that the new trademark guidelines have been published at
http://fedoraproject.org/wiki/Legal:Trademark_guidelines
I would like to see the ability for remixes to use the secondary brand easily. One way to do this is to have a remix-logos package in the Fedora repository that contains secondary brand images which can be used as a replacement for fedora-logos and instead of generic-logos. Anyone willing to look at this?
Rahul
Rahul Sundaram wrote:
Hi,
Now that the new trademark guidelines have been published at
http://fedoraproject.org/wiki/Legal:Trademark_guidelines
I would like to see the ability for remixes to use the secondary brand easily. One way to do this is to have a remix-logos package in the Fedora repository that contains secondary brand images which can be used as a replacement for fedora-logos and instead of generic-logos. Anyone willing to look at this?
The -logos package in the creation of installation media gets chosen by product name, nowadays. You cannot pick a specific -logos package for the installer images build process to use although that was the first patch I attempted to get into anaconda.
I can see the added value of having a remix-logos, but it's name is shorter then "fedora-logos" so I'm afraid it might start winning some yum-best-package selections.
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen wrote:
Rahul Sundaram wrote:
Hi,
Now that the new trademark guidelines have been published at
http://fedoraproject.org/wiki/Legal:Trademark_guidelines
I would like to see the ability for remixes to use the secondary brand easily. One way to do this is to have a remix-logos package in the Fedora repository that contains secondary brand images which can be used as a replacement for fedora-logos and instead of generic-logos. Anyone willing to look at this?
The -logos package in the creation of installation media gets chosen by product name, nowadays. You cannot pick a specific -logos package for the installer images build process to use although that was the first patch I attempted to get into anaconda.
I can see the added value of having a remix-logos, but it's name is shorter then "fedora-logos" so I'm afraid it might start winning some yum-best-package selections.
Is this affecting pungi or livecd-tools as well? I assume I can still exclude fedora-logos and include remix-logos in a kickstart file for live cds. If it does affect live image creation, what is the recommended method to rebrand Fedora now?
Rahul
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
The -logos package in the creation of installation media gets chosen by product name, nowadays. You cannot pick a specific -logos package for the installer images build process to use although that was the first patch I attempted to get into anaconda.
I can see the added value of having a remix-logos, but it's name is shorter then "fedora-logos" so I'm afraid it might start winning some yum-best-package selections.
Is this affecting pungi or livecd-tools as well? I assume I can still exclude fedora-logos and include remix-logos in a kickstart file for live cds. If it does affect live image creation, what is the recommended method to rebrand Fedora now?
The change in anaconda behaviour is affecting revisor and pungi, or actually installation media compose processes in general. That's a separate issue.
My concern with regards to dependency resolving is that if you do not explicitly say you want fedora-logos, you end up with remix-logos being pulled in as the best provider for system-logos. So, this concern really applies to the situation in which one would not want to rebrand.
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen wrote:
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
The -logos package in the creation of installation media gets chosen by product name, nowadays. You cannot pick a specific -logos package for the installer images build process to use although that was the first patch I attempted to get into anaconda.
I can see the added value of having a remix-logos, but it's name is shorter then "fedora-logos" so I'm afraid it might start winning some yum-best-package selections.
Is this affecting pungi or livecd-tools as well? I assume I can still exclude fedora-logos and include remix-logos in a kickstart file for live cds. If it does affect live image creation, what is the recommended method to rebrand Fedora now?
The change in anaconda behaviour is affecting revisor and pungi, or actually installation media compose processes in general. That's a separate issue.
My concern with regards to dependency resolving is that if you do not explicitly say you want fedora-logos, you end up with remix-logos being pulled in as the best provider for system-logos. So, this concern really applies to the situation in which one would not want to rebrand.
Well, ideally people would be inheriting the base ks file and getting it automatically but if that is a real concern, let's call it fedora-remix-logos and that name won't be the shortest anymore.
Rahul
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
The -logos package in the creation of installation media gets chosen by product name, nowadays. You cannot pick a specific -logos package for the installer images build process to use although that was the first patch I attempted to get into anaconda.
I can see the added value of having a remix-logos, but it's name is shorter then "fedora-logos" so I'm afraid it might start winning some yum-best-package selections.
Is this affecting pungi or livecd-tools as well? I assume I can still exclude fedora-logos and include remix-logos in a kickstart file for live cds. If it does affect live image creation, what is the recommended method to rebrand Fedora now?
The change in anaconda behaviour is affecting revisor and pungi, or actually installation media compose processes in general. That's a separate issue.
My concern with regards to dependency resolving is that if you do not explicitly say you want fedora-logos, you end up with remix-logos being pulled in as the best provider for system-logos. So, this concern really applies to the situation in which one would not want to rebrand.
Well, ideally people would be inheriting the base ks file and getting it automatically but if that is a real concern, let's call it fedora-remix-logos and that name won't be the shortest anymore.
Still a little patching would be required for anaconda I believe, to substitute spaces in the product name to a '-'. Either way, fedora-remix-logos seems to have a better chance! ;-)
Kind regards,
Jeroen van Meeuwen -kanarip
On Mon, Mar 09, 2009 at 01:21:36PM +0100, Jeroen van Meeuwen wrote:
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
The -logos package in the creation of installation media gets chosen by product name, nowadays. You cannot pick a specific -logos package for the installer images build process to use although that was the first patch I attempted to get into anaconda.
I can see the added value of having a remix-logos, but it's name is shorter then "fedora-logos" so I'm afraid it might start winning some yum-best-package selections.
Is this affecting pungi or livecd-tools as well? I assume I can still exclude fedora-logos and include remix-logos in a kickstart file for live cds. If it does affect live image creation, what is the recommended method to rebrand Fedora now?
The change in anaconda behaviour is affecting revisor and pungi, or actually installation media compose processes in general. That's a separate issue.
My concern with regards to dependency resolving is that if you do not explicitly say you want fedora-logos, you end up with remix-logos being pulled in as the best provider for system-logos. So, this concern really applies to the situation in which one would not want to rebrand.
Well, ideally people would be inheriting the base ks file and getting it automatically but if that is a real concern, let's call it fedora-remix-logos and that name won't be the shortest anymore.
Still a little patching would be required for anaconda I believe, to substitute spaces in the product name to a '-'. Either way, fedora-remix-logos seems to have a better chance! ;-)
I'm late and not as educated a remixer myself. I'm running a livecd-creator process right now to see what happens in the generic-* case. Would it make sense to have the Fedora Remix logos appear in the generic-logos package by default?
On Mon, Mar 09, 2009 at 10:05:15AM -0400, Paul W. Frields wrote:
On Mon, Mar 09, 2009 at 01:21:36PM +0100, Jeroen van Meeuwen wrote:
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
The -logos package in the creation of installation media gets chosen by product name, nowadays. You cannot pick a specific -logos package for the installer images build process to use although that was the first patch I attempted to get into anaconda.
I can see the added value of having a remix-logos, but it's name is shorter then "fedora-logos" so I'm afraid it might start winning some yum-best-package selections.
Is this affecting pungi or livecd-tools as well? I assume I can still exclude fedora-logos and include remix-logos in a kickstart file for live cds. If it does affect live image creation, what is the recommended method to rebrand Fedora now?
The change in anaconda behaviour is affecting revisor and pungi, or actually installation media compose processes in general. That's a separate issue.
My concern with regards to dependency resolving is that if you do not explicitly say you want fedora-logos, you end up with remix-logos being pulled in as the best provider for system-logos. So, this concern really applies to the situation in which one would not want to rebrand.
Well, ideally people would be inheriting the base ks file and getting it automatically but if that is a real concern, let's call it fedora-remix-logos and that name won't be the shortest anymore.
Still a little patching would be required for anaconda I believe, to substitute spaces in the product name to a '-'. Either way, fedora-remix-logos seems to have a better chance! ;-)
I'm late and not as educated a remixer myself. I'm running a livecd-creator process right now to see what happens in the generic-* case. Would it make sense to have the Fedora Remix logos appear in the generic-logos package by default?
Sorry to reply to self -- I discovered that the generic logos match upstream, i.e. in the generic 10 spin, you get GNOME foor logos for the GNOME desktop, which makes sense.
After further consideration I can see that a separate set of remix logos would be useful. There are cases where the generic logos could be useful as opposed to simply slapping Fedora Remix logos everywhere by default.
Sorry for the noise.
Paul W. Frields wrote:
I'm late and not as educated a remixer myself. I'm running a livecd-creator process right now to see what happens in the generic-* case. Would it make sense to have the Fedora Remix logos appear in the generic-logos package by default?
In my opinion, we should have a generic package that just debrands.
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen wrote:
Paul W. Frields wrote:
I'm late and not as educated a remixer myself. I'm running a livecd-creator process right now to see what happens in the generic-* case. Would it make sense to have the Fedora Remix logos appear in the generic-logos package by default?
In my opinion, we should have a generic package that just debrands.
Don't we have already have that with generic-logos? My opinion is that by making available fedora-remix-logos, we can encourage remixes to give Fedora credit which is the whole point of the secondary brand.
Rahul
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
Paul W. Frields wrote:
I'm late and not as educated a remixer myself. I'm running a livecd-creator process right now to see what happens in the generic-* case. Would it make sense to have the Fedora Remix logos appear in the generic-logos package by default?
In my opinion, we should have a generic package that just debrands.
Don't we have already have that with generic-logos? My opinion is that by making available fedora-remix-logos, we can encourage remixes to give Fedora credit which is the whole point of the secondary brand.
Rahul
Yes.. so three logo packages, and you only include one:
fedora-logos generic-logos fedora-remix-logos
-- bk
Bryan Kearney wrote:
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
Paul W. Frields wrote:
I'm late and not as educated a remixer myself. I'm running a livecd-creator process right now to see what happens in the generic-* case. Would it make sense to have the Fedora Remix logos appear in the generic-logos package by default?
In my opinion, we should have a generic package that just debrands.
Don't we have already have that with generic-logos? My opinion is that by making available fedora-remix-logos, we can encourage remixes to give Fedora credit which is the whole point of the secondary brand.
Rahul
Yes.. so three logo packages, and you only include one:
fedora-logos generic-logos fedora-remix-logos
I don't know what you mean by saying I only include one. You appear confused. To be clear, there is only two logos packages currently. fedora-logos and generic-logos and I am proposing, we have a third one, fedora-remix-logos. Read my first post.
Rahul
Rahul Sundaram wrote:
Bryan Kearney wrote:
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
Paul W. Frields wrote:
I'm late and not as educated a remixer myself. I'm running a livecd-creator process right now to see what happens in the generic-* case. Would it make sense to have the Fedora Remix logos appear in the generic-logos package by default?
In my opinion, we should have a generic package that just debrands.
Don't we have already have that with generic-logos? My opinion is that by making available fedora-remix-logos, we can encourage remixes to give Fedora credit which is the whole point of the secondary brand.
Rahul
Yes.. so three logo packages, and you only include one:
fedora-logos generic-logos fedora-remix-logos
I am saying I agree :)
-- bk
On Tue, Mar 10, 2009 at 6:05 PM, Bryan Kearney bkearney@redhat.com wrote:
Rahul Sundaram wrote:
Bryan Kearney wrote:
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
Paul W. Frields wrote:
I'm late and not as educated a remixer myself. I'm running a livecd-creator process right now to see what happens in the generic-* case. Would it make sense to have the Fedora Remix logos appear in the generic-logos package by default?
In my opinion, we should have a generic package that just debrands.
Don't we have already have that with generic-logos? My opinion is that by making available fedora-remix-logos, we can encourage remixes to give Fedora credit which is the whole point of the secondary brand.
Rahul
Yes.. so three logo packages, and you only include one:
fedora-logos generic-logos fedora-remix-logos
I am saying I agree :)
-- bk
Okay,
so I am not sure if we've decided or not to have this package in place, but I'd like to offer to create the logo package. The reason I want to do this, is to learn where the logos go in the filesystem. I plan on continuing to present Fedora Remix at Conferences and LUG meetings as much as possible and feel it would be good to help this effort. Plus this will be quite an easy package to create as it's just a matter of figuring out where to install the images and some documentation.
I hope I'm not out of line and would be able to put this in place pretty quickly.
Cheers,
Clint
Clint Savage wrote:
so I am not sure if we've decided or not to have this package in place, but I'd like to offer to create the logo package. The reason I want to do this, is to learn where the logos go in the filesystem. I plan on continuing to present Fedora Remix at Conferences and LUG meetings as much as possible and feel it would be good to help this effort. Plus this will be quite an easy package to create as it's just a matter of figuring out where to install the images and some documentation.
I hope I'm not out of line and would be able to put this in place pretty quickly.
Awesome! You get my +1 ;-)
Kind regards,
Jeroen van Meeuwen -kanarip
Clint Savage wrote:
Okay,
so I am not sure if we've decided or not to have this package in place, but I'd like to offer to create the logo package. The reason I want to do this, is to learn where the logos go in the filesystem.
Great. You can look at generic-logos and replace some of the images with the remix equivalents as applicable. That's all we need but we need to be done every release as the artwork changes.
Rahul
On Tue, Mar 10, 2009 at 06:29:58PM -0600, Clint Savage wrote:
On Tue, Mar 10, 2009 at 6:05 PM, Bryan Kearney bkearney@redhat.com wrote:
Rahul Sundaram wrote:
Bryan Kearney wrote:
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
Paul W. Frields wrote: > I'm late and not as educated a remixer myself. ??I'm running a > livecd-creator process right now to see what happens in the generic-* > case. ??Would it make sense to have the Fedora Remix logos appear in > the generic-logos package by default? > In my opinion, we should have a generic package that just debrands.
Don't we have already have that with generic-logos? My opinion is that by making available fedora-remix-logos, we can encourage remixes to give Fedora credit which is the whole point of the secondary brand.
Rahul
Yes.. so three logo packages, and you only include one:
fedora-logos generic-logos fedora-remix-logos
I am saying I agree :)
-- bk
Okay,
so I am not sure if we've decided or not to have this package in place, but I'd like to offer to create the logo package. The reason I want to do this, is to learn where the logos go in the filesystem. I plan on continuing to present Fedora Remix at Conferences and LUG meetings as much as possible and feel it would be good to help this effort. Plus this will be quite an easy package to create as it's just a matter of figuring out where to install the images and some documentation.
I hope I'm not out of line and would be able to put this in place pretty quickly.
Fantastic, Clint -- great way to step up to the plate.
Rahul Sundaram wrote:
Bryan Kearney wrote:
Yes.. so three logo packages, and you only include one:
fedora-logos generic-logos fedora-remix-logos
I don't know what you mean by saying I only include one. You appear confused. To be clear, there is only two logos packages currently. fedora-logos and generic-logos and I am proposing, we have a third one, fedora-remix-logos. Read my first post.
"You include only one on the spin you're creating" being the target situation.
-Jeroen
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
Paul W. Frields wrote:
I'm late and not as educated a remixer myself. I'm running a livecd-creator process right now to see what happens in the generic-* case. Would it make sense to have the Fedora Remix logos appear in the generic-logos package by default?
In my opinion, we should have a generic package that just debrands.
Don't we have already have that with generic-logos? My opinion is that by making available fedora-remix-logos, we can encourage remixes to give Fedora credit which is the whole point of the secondary brand.
Yes Rahul..., we have debranding in the form of generic-logos...
So, the actual question was, whether the remix logos should be shipped in the generic-logos package instead of being in their own fedora-remix-logos package.
My answer to that question was, that we should have a package that just debrands, in my opinion no less.
That would at the very least maintain the current situation with a fedora-logos trademark package, and a generic-logos debrand package. Hence the remix logos should go into their own package.
How was this unclear exactly?
-Jeroen
Jeroen van Meeuwen wrote:
That would at the very least maintain the current situation with a fedora-logos trademark package, and a generic-logos debrand package. Hence the remix logos should go into their own package.
How was this unclear exactly?
As long as we are keeping all the three different options as separate from each other, I am ok with it. If that is what you are recommending as well, I agree with you. Nothing unclear about that.
Rahul
2009/3/8 Jeroen van Meeuwen kanarip@kanarip.com:
Rahul Sundaram wrote:
Hi,
Now that the new trademark guidelines have been published at
http://fedoraproject.org/wiki/Legal:Trademark_guidelines
I would like to see the ability for remixes to use the secondary brand easily. One way to do this is to have a remix-logos package in the Fedora repository that contains secondary brand images which can be used as a replacement for fedora-logos and instead of generic-logos. Anyone willing to look at this?
The -logos package in the creation of installation media gets chosen by product name, nowadays. You cannot pick a specific -logos package for the installer images build process to use although that was the first patch I attempted to get into anaconda.
I can see the added value of having a remix-logos, but it's name is shorter then "fedora-logos" so I'm afraid it might start winning some yum-best-package selections.
This business with the way logo packages are selected really has to change. If i create a derivative of Fedora called Fap Linux, then fap-logos would beat out fedora-logos both alphabetically and by length. This could create some embarrassing situations.
-Yaakov
On Wed, 2009-03-11 at 16:36 -0400, Yaakov Nemoy wrote:
This business with the way logo packages are selected really has to change. If i create a derivative of Fedora called Fap Linux, then fap-logos would beat out fedora-logos both alphabetically and by length. This could create some embarrassing situations.
Which is why your configs should have --exclude fedora-logos
Yaakov Nemoy wrote:
This business with the way logo packages are selected really has to change. If i create a derivative of Fedora called Fap Linux, then fap-logos would beat out fedora-logos both alphabetically and by length. This could create some embarrassing situations.
First of all let me say that I agree but the way I had envisioned this to work did not pass patch review on anaconda-devel.
Now, the product name you pass to anaconda sets the brand package to use and you'll need to exclude every other logos package or they will be pulled in by pungi or Revisor (the latter should only do so in --respin mode, by default it uses exclusive dependency resolving).
-Jeroen
-
Bryan Kearney -
Clint Savage -
Jeroen van Meeuwen -
Jesse Keating -
Paul W. Frields -
Rahul Sundaram -
Yaakov Nemoy