On Fri, 24 Jan 2014 09:58:07 -0700 Eric Smith <spacewar@xxxxxxxxx> wrote: > On Jan 23, 2014 2:33 PM, "Kevin Fenzi" <kevin@xxxxxxxxx> wrote: > > > > On Thu, 23 Jan 2014 19:03:02 +0100 > > Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> wrote: > > > I'm still undecided if I overall like Fedora.next or fear it. But > > > more and more I tend to the latter position and wonder if it > > > might be wise to slow things down: Do one more Fedora release the > > > old style in round about June; that would give us more time to > > > better discuss and work out Fedora.next and get contributors > > > involved better in the planing. > > > > This is not practical. Lots of people are thinking about a > > fedora.next, qa folks are coding away, lots of people who normally > > would be working on the next release are not. If we tell them to > > stop all that and go back to normal, we could, but then fedora.next > > will likely never ever happen. > [...] > > The current problem I have with Fedora.next is that it's so > > abstract. > > How are QA folks "coding away" for Fedora.next, rather than > traditional Fedora QA processes, if Fedora.next is "so abstract"? Kevin covered most of it, but the short answer is that we have so much stuff in our backlog of qa tools and technical debt to pay off right now that the details of fedora.next aren't required to make progress. The primary focus for now is replacing autoqa with taskotron. There are a lot of moving parts in a decent, generic automation system and the base for those parts need to be replaced at the same time or not at all. Regardless of what happens with Fedora.next, there is a real need for better automation support to start running more checks on packages and other output and the delay between f20 and f21 will give us the time we need to at least get the basics in place. As a concrete example, a package-level check was recently proposed to help detect scriptlet errors like the one that caused the SELinux issue with F20. That type of check is just not possible to run sanely in autoqa due to its host-destructive nature. While destructive checks aren't in scope for the initial deployment of taskotron, it is a feature that we're planning on. I believe that releng is in a similar position - lots of improvements on the wishlist but the regular release cadence prevents work on anything substantial. However, I can't speak to what their specific plans are for the delay between f20 and f21. Tim
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
