On 07/06/2013 05:01 PM, Kevin Fenzi wrote:
People creating spins should be allowed to create sub community
surrounding their spins and will not be able to do that with those
insane requirements.
If they have a "sub community" shouldn't that mean there's at least
one other person in it that could test?
Not necessary when they initially create the spin we ( the community
service sub-communities releng/infra/qa/design/marketing ) should be
supportive to allow it to establish a sub-community surrounding that
spin for up to 3 release cycle. Even if not in the end it would just
mean more work for that individual it's just easier for him if there are
more.
And if that individual fails to meet the criteria and what other
requirements that will decide here the spin wont be shipped.
However I argue the way forward for spins is to allow each of the spins
to control their own release cycle and the spins owner themselves having
to learning and do the necessary work from the releng side ( handle the
entire process and stand or fall with it instead of tapping into
existing releng resources ) encase they want to deviate from the
"default" release cycle by for example adapting their spin release cycle
to their upstream but that topic I was just going to discuss well first
with Adam and Tim and the rest of the QA and Releng community at flock
along with the idea of applying the steady release cycle to "base/coreOS
and X" only.
Bear in mind that anything you decide here should be applicable to
the Gnome live spin as well.
The KDE and Desktop (Gnome) spins are not included here, as they are
release blocking, so they already have their own critera.
Our release blocking criteria is not limited to Gnome and KDE but all
spins. ( same thing should apply to primary/secondary arch as well from
my pov )
If our criteria cant cover that then that's a design flaw as I see it in
our criteria process because it should be sufficient for spins having to
meet what is defined there and apply to the bits the relevant spin ships
and that's something we ( QA ) need to fix.
Our QA first and foremost function as I see it is to cover the
installer,base/core OS and X any testing outside that should be handled
by the relevant sub community.
Gnome desktop users for Gnome,KDE for KDE XFCE/LXDE and so on.
Basically what ever spins add on top of base/coreOS and X should work at
their release time and meet the existing criteria as I see since I dont
see the need for us to complicate the process more than that on top of
having to learn and handle the entire releng release process and testing
to the bits they ship with the exception of "base/core OS and X".
I do believe that will solve the underlying problem which spurred this
discussion and change in the spins process in the first place.
JBG
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
