[Fedora-spins] Proposal: Spins process amendment for Fedora 20 cycle

"Jóhann B. Guðmundsson" johannbg at gmail.com
Sat Jul 6 17:50:30 UTC 2013


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


More information about the test mailing list