major change release management for former Extras packages?

[Jesse Keating]

On Monday 07 May 2007 15:46:58 Ville Skyttä wrote:
> But magically only in post-F7 Rawhide, not F7, right?

Correct.

> 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?

Presumably the maintainer knew that they were breaking upgrade path when doing 
the FE6 build, and thus did a build on devel/.  Therefor the build would be 
sitting there, tagged with dist-fc7, waiting for the request and rel-eng to 
do a simple 'tag-pkg' command.  A second's worth of work.

> If 
> rebuilt, whose responsibility is it?

It is the responsibility of the maintainer to already have the build complete 
(and automatically tagged with dist-fc7) before requesting it be tagged for 
f7-final.

> 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 fully expect MUCH of our scripts to need some form of work.

> 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.

organized....  or small amounts of chaos...  Thankfully tagging a package is 
extremely quick, it just takes time to generate an email.  Things go faster 
if the rebuilds are to fix NVR only and not "oh, I'm rebuilding, might as 
well suck down the latest upstream and introduce a soname bump and new 
features and...."

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070507/e0ae7f0e/attachment.sig>