Possible QA Devel Projects for GSoC 2014

[Tim Flink]

On Tue, 11 Mar 2014 07:52:06 -0400 (EDT)
Kamil Paral <kparal at redhat.com> wrote:

> > > Well, are we sure now how exactly the client setup process will be
> > > hooked into taskotron or its underlying tools?
> > 
> > I'm not exactly sure how this will work, either. It's going to
> > depend on what we end up using for graphical testing, what
> > openstack is capable of, what cloud resources we have access to and
> > what the cloud SIG ends up needing for their testing.
> > 
> > > Are we committed to using buildbot, or might it change?
> > 
> > I don't really see how this is relevant. Can you elaborate on how
> > using buildbot or not would factor in here?
> 
> Hmm. In AutoQA, we used Autotest for managing test clients. Any
> disposable client support would most probably needed some support in
> Autotest. I assumed it's the same for Buildbot. Instead of using a
> pre-defined machine, it will need to be able to say "you there,
> create me a machine matching these requirements; zzz; thank you".

There are several ways that we could go about implementing disposable
clients. Buildbot already has some support for ephemeral slaves using
OpenStack but I've not spent any time with it yet so I can't speak to
how well it would work for our needs.

The only potential problem I see with openstack is that I'm not sure we
can do graphical testing with openstack instances (ie, direct access
to the VNC interface or through libvirt). We'd have to investigate that
to be sure, though.

> > > So, two different systems (i.e. two different databases)
> > > displayed in a single web frontend, right? I guess it makes sense.
> > 
> > Yeah, that's what I had in mind, anyways.
> > 
> > Since student registration has started, I'd like to get our proposed
> > ideas in the wiki soon. The question of whether any of these
> > projects would be worth distracting folks from other dev/testing
> > work remains - any thoughts on that front?
> 
> So far it seems you're the only candidate for mentoring, you it's
> probably up to your decision and past experience. Of course any of us
> will help the student when needed, but I assume most of the
> communication will be between the mentor and the student. Josef says
> that he recommend picking a project for which we don't need to spend
> weeks to introduce and explain to the student the whole project, our
> needs, etc. Something that is simple to explain, and can be
> implemented without being blocked on us.

Yeah, that's one of my concerns - the time that at least one of us
would need to invest. I concur with Josef's suggestion of something
that doesn't require too much background but I also think that having
multiple mentors and involved folks is also important so it's not just
1 person interacting with a student.

> > It sounds like the results middleware project, the graphical
> > installation project, the gnome-continuous project and _maybe_ the
> > disposable client project are the best candidates. Any thoughts on
> > the value for those?
> 
> I don't know much about gnome-continuous, but the rest of the
> projects you mentioned really seems to be the best picks. Results
> middleware is probably closest to Josef, graphical testing is closest
> to me and disposable clients is closest to you. When it comes to
> importance, disposable clients have probably the highest priority,
> then results middleware, and then comes the rest. But that's just my
> guesses.

I think that gnome-continuous would be a good way to start getting some
graphical testing done without needing disposable clients but I'm not
clear on how much setup, integration and hw overhead there would be for
the support infrastructure (rpm-ostree, at least AFAIK).

I think that either disposable clients or the results middleware are
going to be the highest priorities of the projects I listed. They're
both things that have been (at least indirectly) asked for several
times over the last couple years and I think that getting them
implemented would help restore some confidence that we're going in the
right direction.

At this point, there are 3 or so days left in the application process
and since we all seem to be on the fence on this a bit, I'm thinking it
would be wise to skip GSoC for this year. I might put the ideas up on
the wiki page tomorrow in case someone sees them and gets inspired for
next year, though.

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/qa-devel/attachments/20140318/cb90e796/attachment.sig>