2:43 a.m.
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