[PATCH] upgradepath doesn't support -testing repos yet, disable scheduling

Kamil Paral kparal at redhat.com
Thu Sep 23 21:55:27 UTC 2010


----- "James Laska" <jlaska at redhat.com> wrote:

> On Thu, 2010-09-23 at 13:04 +0200, Kamil Páral wrote:
> > This patch kind of reverts fbe9ee91b. We don't want upgradepath to
> be run
> > for -testing repos, because that would effectively prevent
> maintainers
> > from pushing into -testing. They would need to wait until that
> package
> > gets into stable updates in more recent Fedora releases, and we
> don't
> > want that.
> 
> 
> > So the solution is not to schedule upgradepath for these update
> requests
> > at all (at least until we have more complex upgradepath). That will
> fix
> > the assertion error we had received.
> 
> Sorry Kamil, I'm in need of clarification.  Isn't 'upgradepath'
> listed
> as a mandatory test [1] for any updates entering 'updates-testing'? 
> I
> feel like we're missing out if we don't run the test when a package
> is
> proposed for updates-testing.  
> 
> Re-reading the criteria [2], do I understand correctly that
> upgradepath
> must PASS in order to be pushed into 'stable'?  If that's true, I
> think
> I better understand the open question now.  If the result of
> upgradepath
> would only prevent a package from being pushed to stable, why bother
> running it for 'updates-testing'?  Is that correct?


We have decided (there are some mails in this conference about it some
month ago) that updates-testing repo causes too many problems and we 
won't implement checks for it, at least for now. So we check upgradepath
constraint only for main+updates repos.

Example use case showing problems with updates-testing:

1. In all repos there is foo-2.0.
2. I want to push foo-3.0 into f13-updates-testing.
3. Currently upgradepath reports FAILED, because neither f14 nor
f14-updates contain foo >= 3.0.
4. The only way in this case would be:
 * push into rawhide
 * push into f14-updates-testing, *wait* until it goes to f14-updates
 * push into f13-updates-testing

Which is kind of PITA, because maintainers want to push the package
into ALL *-updates-testing immediately, without waiting several weeks
until it propagates top to bottom.

The result is that we completely ignore -updates-testing for now. We
don't check it for upgradepath constraint and we also don't want to check
any proposed updates for this repo. We check only builds proposed
for main or -updates repo.

That means we will ensure upgradepath constraint for common users (using
main+updates repos), but not for power users (using -updates-testing).

Does it make sense? It's a little late in here, I might be rambling a bit ;)
I hope I haven't confused anything.


More information about the autoqa-devel mailing list