Re: repoinfo.conf and older releases

[Kamil Paral]

----- "James Laska"  wrote:
> > What is the reason to keep repos of unmaintained released in
>
> repoinfo.conf?
> > I can't find any usage of it. Currently I would just remove all
>
> unmaintained
> > releases and remove 'isactiverelease' keyword as well.
>
> Hmm, yeah.  I don't know why I like keeping the old entries around. 
> But
> it does seem silly to continue with old entries that don't work. 
> Let's
> just drop f10 and f11 from repoinfo.conf.

If we don't have other uses for it, I would drop it. We have the history
in git, it can be easily added back again when needed in the future.
> > By the way, 'isactiverelease' variable confuses me anyway. Why is
>
> Branched
> > active, but Rawhide inactive? I don't understand that.
>
> While it's not 100% clear from the mail thread or the commit log on
> this
> subject, I understand that the 'isactiverelease' was added to
> indicate
> what entries has install images available.  Wwoods can confirm. 
> Iirc,
> post-tree-compose was failing because install images are no longer
> built
> and provided for rawhide (and for EOL'd releases [1]).  According to
> the
> comment in repoinfo.py,
>     getreleases() - '''Return the list of known, non-EOL
>     releases.'''
>
> Using that definition, Rawhide isn't a Fedora release as installation
> images are not provided.  Rawhide is just a repository of packages. 
> I
> wonder if it makes sense to rename 'isactiverelease' to
> 'isinstallable'?

Ah, in that case it makes sense. The variable name could really be
improved to be clearer.

If the variable exists just for this one use case, we can also avoid
it and just disable test scheduling for post-tree-compose tests 
for rawhide (hardcoded in control.autoqa). Whatever you like.

repoinfo.conf and older releases

[James Laska]

On Thu, 2010-09-23 at 17:33 -0400, Kamil Paral wrote:
> ----- "James Laska"  wrote:
> > > What is the reason to keep repos of unmaintained released in
> >
> > repoinfo.conf?
> > > I can't find any usage of it. Currently I would just remove all
> >
> > unmaintained
> > > releases and remove 'isactiverelease' keyword as well.
> >
> > Hmm, yeah.  I don't know why I like keeping the old entries around. 
> > But
> > it does seem silly to continue with old entries that don't work. 
> > Let's
> > just drop f10 and f11 from repoinfo.conf.
>
> If we don't have other uses for it, I would drop it. We have the history
> in git, it can be easily added back again when needed in the future.
> > > By the way, 'isactiverelease' variable confuses me anyway. Why is
> >
> > Branched
> > > active, but Rawhide inactive? I don't understand that.
> >
> > While it's not 100% clear from the mail thread or the commit log on
> > this
> > subject, I understand that the 'isactiverelease' was added to
> > indicate
> > what entries has install images available.  Wwoods can confirm. 
> > Iirc,
> > post-tree-compose was failing because install images are no longer
> > built
> > and provided for rawhide (and for EOL'd releases [1]).  According to
> > the
> > comment in repoinfo.py,
> >     getreleases() - '''Return the list of known, non-EOL
> >     releases.'''
> >
> > Using that definition, Rawhide isn't a Fedora release as installation
> > images are not provided.  Rawhide is just a repository of packages. 
> > I
> > wonder if it makes sense to rename 'isactiverelease' to
> > 'isinstallable'?
>
> Ah, in that case it makes sense. The variable name could really be
> improved to be clearer.
>
> If the variable exists just for this one use case, we can also avoid
> it and just disable test scheduling for post-tree-compose tests 
> for rawhide (hardcoded in control.autoqa). Whatever you like.

I have a suspicion that it will be easier for us to manage policy
changes if we continue to control this by way of a config file variable.
I'll send a patch to the list later on to rename the config variable.

Thanks,
James