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

James Laska jlaska at redhat.com
Tue Sep 28 20:49:38 UTC 2010


On Mon, 2010-09-27 at 09:43 -0400, James Laska wrote:
> 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.

Hey gang,

I'm failing when looking into the list archives to review our previous
conclusions on this topic.  I know we talked about this before, but I
can't find the threads.

The more I think about the upgradepath test, the more I come up with
scenarios where I (as a maintainer) would want to know the upgradepath
result for my updates in 'updates-testing'.  I recognize there might be
some weird policy issues here, perhaps we need to get clarification on
this from FESCO?  

I know there is also the potential that an update in 'updates-testing'
fails during functional validation, and never lands in 'stable'.  Isn't
this scenario covered by also scheduling upgradepath for bodhi 'updates'
requests?

Sorry for coming back to this topic, I think I need some re-educating on
what 'upgradepath' means.

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/20100928/2fb9ad9e/attachment.bin 


More information about the autoqa-devel mailing list