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

James Laska jlaska at redhat.com
Wed Sep 29 13:15:20 UTC 2010


On Wed, 2010-09-29 at 08:11 -0400, Kamil Paral wrote:
> ----- "James Laska" <jlaska at redhat.com> wrote:
> > 
> > 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.
> 
> Weird, I think we did discuss it, I even think of some ascii art showing
> possible problems. But I found just this, nothing more:
> https://fedorahosted.org/pipermail/autoqa-devel/2010-August/000982.html
> 
> > 
> > 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 have search through whole fedoraproject wiki and a lot of pages talk
> about upgrade path, but none defines it exactly. Therefore we could ask
> FESCo about exact definition, yes, that's probably a good idea (to have
> some solid background for what we do).
> 
> The main question is whether we want to have upgrade path constraint
> fulfilled when dealing with updates-testing repositories and what exactly
> it means in this case. Does it mean upgrading from F12-updates-testing to
> F13-updates? Or does it mean upgrading from F12-updates-testing to 
> F13-updates-testing? We don't know, and that's the problem.

That's exactly where my confusion was coming from.  We can certainly
choose one path to test, but whether that is the correct specification,
I don't know.

> I'll write another email talking about the problems that may arise.


> > 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.
> 
> First of all, I'd like to have my patch accepted, if possible. That should
> put into a consistent state - 'updates' checked correctly, 'updates-testing'
> not checked at all. Right now we are in an inconsistent state.

You are right, I corrected the original issue you noted by introducing
an odd behavior.  It is running for 'updates-testing', but only checking
'stable' and 'updates' repositories for upgradepath.  It seemed right at
the time, but now I realize there isn't a clear policy/expectation on
how 'updates-testing' should[n't] be included during upgradepath
calculations.

> Also I have some more patches coming for upgradepath test, so pushing into
> master would save me some trouble.
> 
> When we are in a consistent state, we can unleash the debate about the 
> updates-testing problem :) In a following email I'll sum up the main problems
> that arise and what we can do about it.

That'd be excellent, thanks Kamil for moving this forward.

> Since Will is now on PTO, do you think I can push this into master, James?

I don't see the harm in more correctly fixing the original traceback
(https://fedorahosted.org/autoqa/ticket/226).  From discussions (mail
and 1x1) I've had with everyone, it seems we all agree we need to
include 'updates-testing' in the upgradepath test, but we don't have
consensus on what the policy is.  Given that, please do push your
changes into master.  We'll address 'updates-testing' in your follow-on
mail.

Thanks for the clarification!
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/20100929/25022fc3/attachment.bin 


More information about the autoqa-devel mailing list