Plan for tomorrows (20070418) FESCO meeting

[Michael Schwendt]

On Thu, 19 Apr 2007 11:00:15 +0200, Thorsten Leemhuis wrote:

> > Only packages, which are not rebuilt,
> > keep their old Release. But builds in devel would get a .fc8 dist tag, so
> > when rebuilding a package why jump to .1 instead of .fc8?
> 
> Because we solve the problem in the *long term* once and for all.

It doesn't solve any real problem, since packages that would benefit from
a verified rebuild (under consideration of build logs and testing) would
now sit in the distribution as old builds with a "hidden" dist tag.

It remains an attempt at hiding the dist tag (or the "fc" in it!) for a
purely cosmetical reason. The dist tag does not guarantee that a pkg
really works for a distribution. If packages from Fedora 6 work just fine
in Fedora 7 and haven't changed since Fedora 6, that's fine.

> Example:
> 
> - after F7 was branched change the disttag in devel to be ".1"
> - packages that get build afterwards pick it up
> - assume we have a mass-rebuild in F8 (we'll have one sooner or later in 
> any case, so lets just assume F8 for now)
> - F8 gets released and no packages shipped with it have a disttag "fc8" 
> now; new packages build after release get one, as that easier
> - F9 sees no mass rebuild; packages that were not rebuild during the 
> devel cycle F8 -> F9 can stay as they are; F9 gets release and there are 
> no packages with a ".fc8" in it, so we avoid the confusion we have now 
> (that is: ship F7 with packages that have fc6 in ENVR)

Yes, it hides/alters the dist tag for all packages that are (re)built
during the next devel cycle. Those, that are rebuilt frequently, lose the
"fc" in the dist tag and cannot get it back until a post-release update is
built. And those, that are not rebuilt between dist releases, remain a
[potential] problem. I'm not a fan of %dist (because of its side-effects
in deps and changelogs), but playing tricks with dist tags makes it worse.

Better would be a proper roadmap that requests package owners to prepare
their packages for test1 (e.g.) and enforce an automated rebuild (with
Release bump and changelog entry) if they don't meet the deadline.