----- "James Laska" <jlaska(a)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.