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? Kevin Kofler _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
