RFC: Spins process changes proposal

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 20 Aug 2013 20:28:31 +0000
"Jóhann B. Guðmundsson" <johannbg at gmail.com> wrote:

> On 08/20/2013 07:59 PM, Kevin Fenzi wrote:
> > Well, this change aims to at least see the QA part of that.
> > If they have to do some QA, will a community step up to do so?
> 
> The sub-community would have to do the testing while the QA community 
> would assist them in setting up the test matrix,release criteria 
> surrounding the relevant spin as I see it.
> 
> > Or will that spin just not be shipped?
> 
> 
> In the end of the day if the spin is shipped in a bad or unusable
> state
> 
> a)
> people will stop using it thus it will fail to build a community 
> surrounding it self and die off
> 
> or
> 
> b)
> people will become so frustrated that they will step up to improve
> it, which in turn they will either succeed and more people join the 
> community surrounding it or fail and it will die off.
> 
> What I propose here set's them ( as in each sub-community ) in
> control when they decide to ship ( since they would be doing all the
> necessary releng work themselves ) as well as giving them the
> freedom/flexibility to ship when they deem themselves ready enough
> and or align their release cycle to their upstream.

I think you are wrong in your thinking here. there is no reason why
they can not control their own future today, and develop things as they
want. We really can not let them ship things whenever. we need to
ensure GPL compliance with sources for one thing. we do that today by
having all the sources in one place. we also have pesky things like
release EOL etc to deal with. Its not as simple a solution as you make
out. 

> The releng community in general would not have to provide resource's
> ( with the exception of assist/guide-ing them through the releng
> process ) nor have to worry about them but instead could be focusing
> their resource only on whatever comes out of the ring discussion
> ( which would be the same as the QA community would be doing ).

We have a distinct problem in how do we get the composed bits onto the
mirrors. how do we sign the CHECKSUM that contains all the spins.
testing composes the spin subg group can and should be doing. They
can and should test the official composes. I am not saying we shouldn't
enable the sigs to control their own fate just that in the end we need
to have one body that produces the final set of deliverables that we
ship. That can sig off and say yes they were made in a controlled
manner with a know set of inputs, and have each sub group sign off that
the deliverable is whats expected and works. my complaint with spins
has never been about making them, its akways been about the lack of QA
that they have received. We have shipped broken spins far too often.

> We in QA already have everything in place to implement this while
> releng would have to better explain/document the spin release
> procedures although I think Dennis had already started working on
> improving the general documentation of releng so it might already be
> covered.

I need to update the documentation. But we need to get to the point
where the releng side is transparent and just happens. The crazy
schedules we have had since f18 have allowed zero time for Release
Engineering and QA to do much in the line of development. this is
entirely a failure of FESCo

> Which leaves fesco having to come up with some kind cleanup 
> policy/procedure surrounding this as in when is a spin and
> surrounding community declared "failed to succeed" and what to do
> when that happens.
> 
> So basically we should be able to implement this for F21 and onwards
> as I see it and F20 be the last cycle infra/releng providing
> resources and or bother to keep spins standing on their own to feets
> so to speak.

I think we can implement what is needed in F20. Releng stopped propping
up spins quite a few releases ago. we have not shipped things that
failed to compose. but things that failed to work have shipped. the
burden on releng really is minimal.


Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlIUABkACgkQkSxm47BaWfdv1ACfe7dMs3CqKbcaLon2xO3QRIbj
8PkAnRW5bPCUHw7Q0zlJzSUOrOk13bZr
=2/HE
-----END PGP SIGNATURE-----