On Thu, 2010-09-23 at 17:55 -0400, Kamil Paral wrote:
----- "James Laska" jlaska@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:
- In all repos there is foo-2.0.
- I want to push foo-3.0 into f13-updates-testing.
- 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.
That makes sense, thanks for the details. I misinterpreted the previous discussion to mean that we weren't going to inspect 'updates-testing' repos when attempting to assert upgradepath, not that we weren't going to trigger upgradepath tests for 'updates-testing'. Apologies.
This is a good topic to consider for future planning ... re: the testing we do for 'updates' and 'updates-testing'. I imagine in most cases we'll want to do the same tests, but provide karma differently since policy differs for each. Anyhow, as noted previously, we'll leave integrating upgradepath with updates-testing as a future effort.
Thanks, James