On Thu, 2010-09-23 at 17:55 -0400, Kamil Paral wrote: > ----- "James Laska" <[email protected]> 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.
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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ autoqa-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/autoqa-devel
