Possible QA Devel Projects for GSoC 2014

[Tim Flink]

Fedora has been accepted as a mentoring org for GSoC 2014 and I'm
planning to sign up as a mentor again this year. I'm trying to think of
good projects that we could put on the list of suggestions of things
that we'd like students to work on and figured it was a good topic for
wider discussion.

I'd like to avoid any blockerbugs projects this year so that we can
focus on taskotron and keeping forward momentum. I've made a quick list
of the possible projects that I can think of. Please comment on any of
them that you think would benefit from having a dedicated intern over
the summer or add to the list if you can think of other projects.

Ideally, the projects would be self-contained enough for the student to
demonstrate their progress over the summer but not so isolated that
they wouldn't be interacting with the community. Projects should be far
enough out that we wouldn't be critically blocked on them but close
enough that the effects of their work are visible before the end of
GSoC.

Tim


------------------------------------------------------------
Graphical Installation Testing
------------------------------------------------------------
Continue the work that Jan started with his thesis or look into
integrating something like openqa. The emphasis here is on the
graphical interface since ks-based installation testing could be
covered by stuff already written for beaker


------------------------------------------------------------
Beaker Integration
------------------------------------------------------------
This is on our roadmap and is certainly something that would be useful.
It would require a bit of infrastructure work and likely the
cooperation of the beaker devs but seems like it could be a good
project even if it isn't the most exciting thing ever.

On the other hand, this could end up being rather critical and may not
be something that we want to mostly hand off to a student.


------------------------------------------------------------
Gnome Integration Test Support
------------------------------------------------------------

An over-simplification of this would be to say "take the stuff that's
run as part of gnome continuous [1] and run it on fedora packages". The
goal would be to have gnome's integration test suites running with any
new gnome builds.

[1] https://wiki.gnome.org/action/show/Projects/GnomeContinuous


------------------------------------------------------------
Disposable Client Support
------------------------------------------------------------

This is another of the big features that we'll be implementing before
too long. It's one of the reasons that we made the shift from AutoQA to
taskotron and is blocking features which folks say they want to see
(user-submitted tasks, mostly).

This would involve some investigation into whether OpenStack would be
practical, if there is another provisioning system we could use or if
we'll be forced to roll our own (which I'd rather avoid). There should
be some tie-in with the graphical installation support and possibly the
gnome integration tests.


------------------------------------------------------------
RPM-OSTree Support/Integration
------------------------------------------------------------

I haven't used rpm-ostree enough yet to figure out how good of a fit
it'd be with taskotron but from the description of the project and the
discussions I've had with cwalters, it sounds like it could be a good
fit as part of our provisioning system for disposable clients.

If we're serious about proposing this as a GSoC project, we should
probably explore it a bit more to be certain that we'd want it now but
I figured it was worth putting on the list.

[2] https://github.com/cgwalters/rpm-ostree


------------------------------------------------------------
System for apparent results storage and modification
------------------------------------------------------------

There has to be a better title for this but it would be one of the last
major steps in enabling bodhi/koji to block builds/updates on check
failures. The idea would be to provide an interface which can decide
whether a build/update is OK based on what checks were passed/failed.
It would have a mechanism for manual overrides and algorithmic
overrides (ie, we know that foo has problem X and are working on it,
ignore failures for now) so that we don't upset packagers more than we
need to.

When Josef and I last talked about this, we weren't sure that putting
this functionality into our results storage mechanism was wise. It's a
different concern that has the potential to make a mess out of the
results storage.
-------------- 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/20140305/e5350795/attachment-0001.sig>