[Fedora-spins] Fedora Unity re-spins

[Jeroen van Meeuwen]

Paul W. Frields wrote:
> As you might be aware already, Red Hat Legal has been working on the
> text for a licensing agreement that will be used to formally give
> permission for groups outside the Fedora Project to use the Fedora
> name in their domains, group names, and so forth.  Red Hat recognizes
> there is great value in this to Fedora and Red Hat itself, so the
> intent is to have the agreement cover uses to which we know people are
> putting the Fedora trademarks now.
> 
> One of those uses is the Fedora Respins.  I want to make sure that the
> agreement is explicitly allowing coverage of the Respins, but to do
> that I wanted to make sure I have the construction clear in my mind.
> If the Fedora Respins include software that Fedora hasn't explicitly
> released verbatim, like a patched anaconda, I want the trademark
> license agreement to permit that use.  If patches to anaconda are now
> being mainlined by its upstream, regardless of whether they're issued
> in an updated package, then the language might need to be slightly
> different.
> 
> Jeroen, can you tell me what the current process is for issuing
> Respins, and where, if any, packages or content on the Respins differ
> from what Fedora has officially released in its software repositories?
> Then I can make sure the proper language gets into the agreement.
> Once I have that agreement in hand, I'll send a copy to the
> appropriate contact for Fedora Unity (along with its other
> destinations) to be executed.
> 

Hi Paul,

the current process for issuing Re-Spins is as follows:

1) The Unity team decides to do a Fedora N Re-Spin
2) I go to work and do some compose testing and preliminary run-tests
2a) Either of these fail and I fix the compose tool, or whatever is in 
between my compose and a successful, working Re-Spin (this is where 
things get side-tracked, so I will continue on this later). When done, I 
go back to 2).
2b) The Re-Spin is successful, and released to our testers. Continue 
with 3).
3) The Re-Spin is tested using the Fedora Project QA Test Cases Matrix 
and may show no regression, either
3a) fails, continue with 2).
3b) is successful, continue with 4)
4) The Re-Spin is released to the public.

Now, for the part where things get side-tracked;

There's occasions where I have fixed Fedora N anaconda by backporting 
the fix from Fedora N+1 or rawhide into Fedora N. This code lives in 
anaconda, just not in the correct branch. I always refer to the specific 
commit I use, either in the existing bug-report on bugzilla.redhat.com 
or bugs.fedoraunity.org. Should I have modified the patch backported, to 
have it apply smoothly, then the code lives on 
http://git.kanarip.com/?p=anaconda. SRPMs and RPMs are built and 
released with the Re-Spins.

There may be cases where anaconda needs a fix for rawhide, to overcome a 
problem that we hit when testing anaconda for Fedora N, in which case I 
submit the patch upstream.

There may also be other applications, for which I basically follow the 
same paradigm, but it has not occurred up and until now.

Either way, our product differs from the regular Fedora released media 
in the following aspects:

- it contains more up-to-date RPM payload (the packages to be installed 
on the system)
- it also contains entirely different installer images (e.g. stage2.img 
/ install.img), since these have been created using the more up-to-date 
packages, and since these images are composed with anaconda, may not be 
reproducible without the patches applied to anaconda.


I hope this clarifies the process a little, and of course if you have 
any questions, let me know.

Kind regards,

Jeroen van Meeuwen
-kanarip