Fedora 13 has been branched!!

Christoph Wickert christoph.wickert at googlemail.com
Wed Feb 17 13:23:22 UTC 2010

Am Mittwoch, den 17.02.2010, 12:18 +0100 schrieb Till Maas:
> On Wed, Feb 17, 2010 at 10:44:10AM +0100, Christoph Wickert wrote:
> > And what about the updates that don't have a custom tag?
> If the update is big enough, that a lot of packages require a rebuild,
> using a custom tag seems to be the best approach, so if there is none,
> ask of it. If there is no need for one, then the buildroot overwrite
> approach seems to be good enough. Or what is the specific problem you
> are seeing?

Both approaches have their ups and downs, but both slow down
      * Asking rel-eng for overwrites takes time.
      * Asking rel-eng for a tag takes some time too. And I'm afraid
        that with an inflationary number of tags things get unclear for
        other maintainers. They don't know what to build their packages
        against or when to use which tag. It requires a lot of
        coordination between the different parties.

> The advantage of using a custom tag is also, that it does not touch the
> buildroots of all packages and therefore makes it possible to still push
> updates for the affected dependent packages, if they are required to fix
> a bug. 

The major advantage of a custom tag for me is that we have a consistency
plan. If something goes wrong, we can just throw away all these builds
and turn back to a previous state without downgrading packages and
introducing epochs.

So we both agree about the advantages of custom tags, but we are talking
about the development versions here and not about stable releases. In
the branches that are under development we would not do a bugfix against
the "stable" tag. Instead, all updates are supposed to target
development. If we really needed a bugfix in a development branch, this
could easily be done with early branching.

> Afaik currently kde does not use a custom tag, and therefore if
> one wants to update a kde/qt dependent package, it would be build with
> a incompatible kde/qt version and therefore cannot be pushed to stable.

Again, we are not talking about stable releases. But if someone does
large updates in the stable releases, I agree they should use a custom

> Regards
> Till


More information about the devel mailing list