Hi all,
in reply to some comments and ideas posted in this thread here's a
couple of reasons why we do what we do the way we do it.
We do not, unlike the Fedora Project, release beta or testing Re-Spins
only to get the feedback we need to come up with a final Re-Spin we
could release to the public, which makes the need for or shape of a
testing process very much different then for Fedora itself. It is the
exact same Re-Spin now in testing that we release; The location of a
link to the data is what distinguishes this Re-Spin in testing from
others being released and out in the open.
Besides, we do not have feature or development freeze periods, which
makes our jobs so-and-so much more difficult. We take a snapshot of what
is in a release and updates tree and go with that. I'm sure you
appreciate the major issues this could potentially introduce in freshly
built installation media. Were we to try and fix things in actual code
and commit patches and the like, we would fit better in a FixSIG in the
Fedora Project itself. Instead, we try to compose off what has been
fixed "upstream" -which is basically us, again-, a newly created set of
installation media that enables people to install and use Fedora 8.
We are not building a distribution, we're rebuilding it. We're not
upstream for the distribution itself: Anyone using a Fedora Unity
Re-Spin can still join #fedora and ask questions or log bugs on RHBZ,
sorta speak. That makes it an awkward situation. We use what is in
"upstream", rebuild what upstream built and release it under the same
name as upstream, but we are not on the receiving end of bugs. That
calls for a certain amount of caution in getting out what we are getting
out.
So far we've not been able to tempt upstream to do it themselves or mix
it with their processes, which would potentially open up some gates and
might help us getting stuff done. Not that it is a problem or anything,
I don't think we should get that mixed up. So far, I think we've been
doing a good job, but doing what we do doesn't mean we can do it without
having some kind of guarantee we are not damaging ourselves (which to me
includes you, the Fedora community as well as Fedora Unity group of
Fedora community members).
The method we currently use for testing and releasing Re-Spins obliges
us to test a Re-Spin as soon as we compose a Re-Spin and in order to be
able to withdraw the Re-Spin -should it have regression compared to the
official release, we need to not release it to the public immediately
(regardless of it being a "test" or "final" release). Bear in mind that
"not releasing to the public" here does not mean we apply access lists
or require you to register. More on that later.
These Re-Spins are so very much affiliated with the Fedora Project, by
both our audience as well as many of our own, and as such I think that
besides Unity's reputation potentially being damaged should we release
bad products, so would the Fedora Project's. Mind that it is Fedora
Unity as a group of concerned Fedora community members that is currently
one of few (it not the only one) party that gets to release this media
still carrying the Fedora brand. I think we're earned that position and
we should do everything in our power to prevent that from going south in
any way. The Fedora Project's Free Media program in fact distributes our
Re-Spins to those who request it.
So, before we make announcements and release anything to the public we
ensure there is no regression compared to the originally released
installation media. That's a good thing, I hope you agree there.
For your information, these last couple of weeks we released and
canceled 4 Re-Spins, and released another. I wouldn't want Google to
pick up on these. I blog about what happens, try and get people to join
our testing process. I'm sure all these people know what it is we do and
what it is they can expect. Unlike someone suggested earlier, I'm not in
favor of announcing "This is likely crap, take it of leave it" and it
fail on anyone.
So, what I've done these last couple of weeks is Re-Spin, distribute,
back-port fixes, dig up bug numbers and contacted people in private that
could potentially confirm or deny our Re-Spin having fixed particular
issues. Most of these people did not have to register or join the
test-team. But I was sure they knew they were taking a chance, and that
they were giving me the feedback I needed to fix whatever I did not fix
yet. I will do everything in my power to prevent John Doe getting a bad
impression of Fedora, or Fedora Unity for that matter, just because we
release to the public untested Re-Spins, and John thinks he got the
latest and greatest. I'm sure you see a point there.
Now, if there's any other way we could prevent crappy test-releases
hitting the public yet still having the testing releases out in the
public, let me know how you think we should arrange that.
Thank you in advance,
Kind regards,
Jeroen van Meeuwen
-kanarip
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
