Fedora.next in 2014 -- Big Picture and Themes

[Tim Flink]

On Fri, 24 Jan 2014 09:58:07 -0700
Eric Smith <spacewar at gmail.com> wrote:

> On Jan 23, 2014 2:33 PM, "Kevin Fenzi" <kevin at scrye.com> wrote:
> >
> > On Thu, 23 Jan 2014 19:03:02 +0100
> > Thorsten Leemhuis <fedora at leemhuis.info> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140124/7fdfa4c7/attachment.sig>