On Tue, 2011-07-19 at 04:07 -0400, Kamil Paral wrote:
> Greetings gang,
>
> During the EPEL meeting today, Kevin Fenzi asked whether it was
> possible
> for autoqa to run for EPEL updates. Since EPEL uses many of the same
> processes and infrastructure used for Fedora builds, I'm wondering how
> difficult this would be.
>
> I'm guessing we would need test clients with labels 'el5' and
'el6'
> available to accept jobs [1]. Some additional repo targets would be
> needed in repoinfo.conf. We'd probably run into python-2.4-isms when
> running tests on el5. Kevin also mentioned, that the upgradepath test
> might not apply. I'm sure plenty additional changes would be needed.
>
> Has anyone tried this yet?
We didn't.
Questions:
1. Who's gonna read the results? Fedora package maintainers who enabled their
packages for EPEL? Or someone else?
2. Are the results going to be taken seriously?
I assume the EPEL package maintainers, but I've cc'd Kevin on this mail
for additional guidance. I'm not entirely clear if the request comes
from the EPEL SIG
(
http://meetbot.fedoraproject.org/teams/epel/epel.2011-07-18-19.30.html)
or from EPEL maintainers. Currently, a repoclosure report is mailed out
on a weekly basis. The EPEL SIG then works with maintainers to resolve
issues.
3. Are we going to "support" these releases, that means
digging into problems and solving them?
By "we", you mean autoqa-devel, right? We won't be responsible for
fixing EPEL packages. We would be responsible for maintaining the
toolchain to support testing EPEL packages, and this would include
diagnosing and prioritizing any strange failures uncovered.
4. What exactly is the benefit of this? Is it large enough to
justify
all the extra work?
Well, the benefits should be clear, but the justification is partly why
I started the thread here. I want start identifying all the
hurdles/challenges with this effort. Clearly, maint/support is an
important issue.
Our current concerns:
a) Depcheck somehow works, but we are sure it doesn't work correctly,
just semi-correctly.
Heh, where's the confidence? :)
b) We want to get rid of Python 2.4, really.
So that means we can limit testing to RHEL6, or as jskladan pointed out,
alter how tests are scheduled. Originally, tests were independent of
the release under test. However since then, we've grown a dependency on
the release under test.
c) More machines types, more client types. At least 4 new machines.
(Note: Jskladan supposes depcheck could be adjusted to work system-independently, e.g.
testing F15 on F14 machine. But that's just an idea.)
I don't know enough of the internals to know why depcheck couldn't
operate independent of the system (much like repoclosure or repoquery).
However, there is something to be said for running depcheck/yum on the
release you are testing. Although, it does make for additional test
client maint.
Overall it should be doable, but it requires quite some work and
resources.
Of course, thanks for your input.
Any other hurdles/challenges/pain_points we haven't yet discussed?
Thanks,
James