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

James Laska jlaska at redhat.com
Mon Sep 27 13:43:16 UTC 2010


On Thu, 2010-09-23 at 17:55 -0400, Kamil Paral wrote: 
> ----- "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.

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://fedorahosted.org/pipermail/autoqa-devel/attachments/20100927/321acc1d/attachment.bin 


More information about the autoqa-devel mailing list