major change release management for former Extras packages?

Ville Skyttä ville.skytta at iki.fi
Mon May 7 19:46:58 UTC 2007


On Monday 07 May 2007, Jesse Keating wrote:
> On Monday 07 May 2007 13:13:57 Dominik 'Rathann' Mierzejewski wrote:
> > So... all my unpushed updates would actually be reverted when rawhide is
> > open again?
> >
> > That's... unexpected and ill-conceived, to say the least. Actually it
> > stiffles development at this point. It means I can't happily hack away
> > even if I'm sure my currently published package set is stable.
>
> Incorrect. dist-fc8 or dist-f8 or whatever we call it will inherit from
> dist-fc7, and thus any unpublished builds will magically show up.

But magically only in post-F7 Rawhide, not F7, right?

If this is true and I now understand correctly how things proceed from here, 
there will be lots of ex-Extras packages with broken upgrade paths from FE6 
to F7, unless packagers are aware of what exactly they're expected to do and 
send the corresponding lots of mails to rel-eng and rel-eng accepts and is 
able to process those mails in time.  Assuming all goes well to the point 
where the mails are actually sent and rel-eng can handle that load during the 
smallish timeframe there will be available for it before F7, will those 
packages need to be rebuilt or will the already done builds be just 
cherry-picked and added to F7 by rel-eng from somewhere?  If rebuilt, whose 
responsibility is it?

The current NEVR upgrade checker script in the FE buildsys can produce a 
report that will clarify the picture somewhat, but only for packages for 
which some version existed in the Extras devel repository before the merge.  
Packages introduced anew after the merge and during the freeze will need to 
be taken care of by other means, or the script hacked to take this into 
account some way.

I think I do understand the goal of this change and it makes mostly sense to 
me, but I think expecting it to happen within the timeframe left before F7 in 
an organized manner is a pretty ambitious goal.




More information about the Fedora-maintainers mailing list