On 08/15/2013 03:55 PM, Stephen John Smoogen wrote:
On 15 August 2013 15:48, Matthew Garrett <mj...@srcf.ucam.org
<mailto:mj...@srcf.ucam.org>> wrote:
Oh, and to clarify - upgrades were supported even before then, but
required booting Anaconda from new install media. That's been true
since
the Red Hat Linux days, so years before Fedora even existed.
I believe we are arguing over words which have different meanings
depending on what each person is talking about.
Agreed
Does supported mean:
a) We guarantee that upgrade works always and without problems?
This is what end users think of when they read "Officially supported"
with even higher demand if they are existing RHEL customers...
b) We guarantee that upgrade code works but may encounter problems if
you have done stuff other than a default install/stuff.
Some form of middle ground of this is what we have currently implemented
in QA and test for but even there we cannot "guarantee" anything, like
if we take the default desktop installation how well can Gnome itself
handle upgrades between releases ( think for example *conf schema
changes here )
Now with rings and "servers" I'm afraid we ( as in QA ) have to start
officially support which ever application are in it which often bring
incompatible changes with them.
c) We guarantee that the upgrade code is there, and it should work but
you should know what you are doing
This is what the QA attitude used to be, before "official upgrade support".
d) There is some code, we worked on it, you can activate it, but that
is all we can say.
Each of those has been said of upgrade by various developers over the
years (Jeremy Katz would try to get it down to D but Gafton would want
it to be b) and every new person on anaconda would say they wanted to
get to a someday.)
What's alarming with the decision to officially support upgrades that it
was done without consulting the QA community, which are the ones that
have to come up with the test cases,make the necessary changes to the
release criteria, essentially have to do all the work and above all test
it.
With the upcoming changes we have to ensure all the supporting sig
within the project ( qa,releng,infra etc... ) are being properly
communicated,informed and consulted with, in regards to any decision
which directly affects them and the community surrounding them.
In the end of the day they ( as in all the supporting sig ) are the ones
that will have to do all the work as well as allocate resources
necessary to do it.
JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
