-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 20 Aug 2013 20:28:31 +0000 "Jóhann B. Guðmundsson" <johannbg@xxxxxxxxx> 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----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
