Adam Williamson wrote:
> AFAIK we've always had that rule. It's always been policy that we don't
> untag once a build has been in a successful compose. I don't think this
> changed "a few years ago", unless I'm misremembering.
Not always: The policy that disallows Rawhide going backwards was supposedly
documented (it does not say where) in 2009:
https://pagure.io/fesco/issue/96
and the ticket says that it was introduced by FESCo "at some point in the
not too distant past". So I guess it was introduced somewhere around
2008-2009. I have been trying to fight it ever since, especially with the
introduction of distro-sync that makes it completely pointless.
Also note that, at the time, it was not as strictly enforced as now because
untagging from Rawhide was self-service, anyone was able to untag any build
from Rawhide at any time, so at most the rogue untagger would get scorned by
rel-eng. It was fairly common to see downgrades in Rawhide reports,
typically as the result of untagging broken builds.
And before that ca. 2008-2009 FESCo decision, there was no rule at all
against it, which is where I want to get back to. Even upgrade paths between
stable releases (which I would consider still relevant) are apparently no
longer considered relevant due to distro-sync, so why be so strict about
them in Rawhide of all places?
About a year ago I asked fesco to add
"In exceptional cases, releng may untag packages."