orphaning Taskotron-related packages
by Kamil Paral
Hello,
our Taskotron-related repositories (with exceptions like resultsdb) have
been marked as EOL and archived more than half a year ago. I believe it's
time to also tidy up our rpm packages in Fedora.
Looking at our group ownership [1] I have identified the following rpms
which could be retired:
* libtaskotron - nothing depends on it
* taskotron-trigger - nothing depends on it
* python-mongoquery - only taskotron-trigger depends on it
* execdb - nothing depends on it
I think we could have a light discussion regarding libtaskotron. The git
repo is marked as EOL and therefore the package should go away. However,
it's easy to flip the git repo back to a live state and it's not that
trivial to bring back an rpm package. So we should at least briefly
consider whether there is anything in that repo that could be useful in
some of our other current efforts. When looking at the code [2], I think
there are a few modules that could be potentially useful elsewhere, like
koji_utils/bodhi_utils/rpm_utils, perhaps a method or two from
os_utils/file_utils, and a perhaps a few directives. The problem is that
the code is not currently designed to work as a standalone library, but as
a runner - it expects a config file present, it expects certain directories
present, etc. The directives are exceptionally horrible if you want to use
them just by importing and not through the runner. It would require a
fairly big rewrite. Also we could drop ca. 70%-80% of the current codebase
(the runner stuff and unuseful modules).
If Tim said he would like to use some of that code in his CI efforts, or
Josef et al. said they would use some of that for oraculum or packager
dashboard etc, we might not retire libtaskotron, but restructure it into
something more useful. I'd be fine helping with that. But, even if we
wanted to do that, I'd honestly consider leaving libtaskotron as it is, and
rather creating a new package instead, something like 'libfedoraqa' or
similar. And only the few useful modules would be transferred there. It
feels to me much cleaner than reusing the libtaskotron name but gutting it
heavily.
What are your thoughts? Do you see any near-term use of some of the
existing code in libtaskotron? Or any other mentioned packages? Or can we
just drop them and bring them back if we ever need them? (If we don't have
an immediate use, there is a high probability we won't ever need them
again).
Thanks,
Kamil
[1] https://src.fedoraproject.org/group/qa-tools-sig
[2] https://pagure.io/taskotron/libtaskotron/blob/develop/f/libtaskotron
2 years, 10 months
New openQA and os-autoinst deployed on lab (stg)
by Adam Williamson
Hey folks! Just a heads up that I've deployed new git snapshots of
openQA and os-autoinst to lab (stg), with ~3 months worth of changes in
each. I did a quick test run on my own pet deployment and nothing blew
up, but yell if you see anything awful. If they work OK for the next
few days I'll send them to prod.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2 years, 11 months
current maintainer of lmbench3
by Ryan Kosta
Dear QA tool development,
During this week's kernel testday, I encountered a few interesting
compilation errors with lmbench. Nothing to warrent major concern but
their was a variable or two that had the wrong types, enough to offer a
patch or two.
When looking for lmbench I found the official intel github repository
for it online. The readme was consistent with the readme in the source
from the testcase stating the version as 2alpha8. yet the directory was
named lmbench3.
For this testcase did you clone lmbench directly from the intel github
repository or is their an internal Fedora repository in which it came
from?
Thank you,
Ryan Kosta
<ryanpkosta(a)gmail.com>
2 years, 11 months
