On Fri, 2010-01-15 at 08:40 -0500, Kamil Paral wrote:
----- "Kamil Paral" <kparal(a)redhat.com> wrote:
>
> Generally
> there is one use case where rpmguard compares the new package with
> itself. It is when the updated package moves to official repositories
> before the rpmguard test is performed.
>
As I have mentioned, it is currently possible for a package to "fly
under our radar" by simply moving to official repositories (stable,
updates, updates-testing) too soon. It caused by our current strategy
to compare the package against its most recent version in official
repositories.
So how to tackle it?
Solution #1: Leave it be
I suppose this events will not happen too often. If you deem it
appropriate, we can just let it be. Currently it's mainly proof
of concept. In the future if we have a policy that no package can
move from -updates-candidate unless it has been checked by AutoQA
test, then the problem is automatically solved.
Solution #2: Re-implement "search for latest" strategy
I have been playing with koji command and it seems to be able
to list all the history of builds with particular tag, not just
the latest build. You can try it yourself:
$ koji list-tag-history --package=PackageKit
$ koji list-tagged dist-f12-updates PackageKit
Therefore we can re-implement/add a new method to our library
that would not just provide the latest build of a package, but
all of them from the history. Then we would pick the one that
suits us most. The API clearly offers this capabilities.
There is also one question that is directly connected to this topic.
Which tags do we want to search through when looking for previous
builds?
a) Currently we search through stable, -updates and -updates-testing.
b) Would it make sense to search also through -updates-candidate?
The differences would always show to the very latest build, doesn't
have to be released.
c) Or the other way round, would it be better to search through only
stable and -updates (skip -updates-testing)?
When more builds are in testing repo, the differences would be
displayed always against the latest build in stable repos (stable or
-updates).
I would say solution #2 shouldn't be that hard, I would do it. And as
for repositories searched, maybe c) would be better than a), but I don't
know packagers' needs.
re: solution#2 - Will probably has good historical perspective here, but
this seems sensible to me.
/me walks through a mental exercise ...
A package-0.0 exists in dist-f12 (or dist-f12-updates). An updated
version package-0.1 lands in updates-testing and turns out to be bad.
Then, a new package-0.2 is built and tagged for updates-testing. I
don't think we'd want to compare package-0.2 with package-0.1.
I believe we want to compare against the previous generally available
package (and allow for an optional over-ride if desired?). I don't
consider updates-testing to mean generally available. True, it might
mean that some of the same issues identified from the previous
comparison, will be displayed again for review. When we need to review
test results for a package that was released with a problem, I'd prefer
looking at one test summary, instead of potentially piecing together the
results from multiple comparisons against interim test versions of the
package.
Thoughts/concerns?
Thanks,
James