On Tue, Jun 05, 2018 at 02:26:25AM +0100, Peter Robinson wrote: > On Tue, Jun 5, 2018 at 12:39 AM, Adam Williamson > <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > Hi, folks! > > > > We currently have a Final release criterion that reads as follows: > > > > "A spin-kickstarts package which contains the exact kickstart files > > used to build the release must be present in the release repository. > > The included kickstarts must define the correct set of release > > repositories. > > > > Why? > > > > This is considered part of Fedora's duty to be 'self-hosting': the > > kickstarts used to produce the release images are a vital piece of > > information required to duplicate that release, so they must be > > preserved along with the release." > > > > Lately this requirement has been fairly annoying in practice. Updating > > the package prior to release does not appear to be in anyone's regular > > schedule, so invariably what happens is shortly before the release > > deadline I realize we haven't built a 'release' spin-kickstarts package > > and have to file a blocker bug and ping people with the necessary > > permissions (of which there are only a few) to build one in a tearing > > hurry. Then we have to approve the blocker bug and push the updated > > package through the freeze, all wasting time we could be spending on > > more important fixes. > > > > The benefit here is really fairly tiny, as well. It's arguable whether > > anyone cares particularly whether a Fedora release, as a frozen > > artifact, is 100% internally reproducible (and I'm not sure whether our > > releases actually *are* reproducible in any case, these days, I'm not > > at all sure we ship all the necessary metadata and so on for *every > > single deliverable* within the distribution). > > > > These days I'd suggest it should be quite acceptable to simply use git > > tags for this purpose. It should be quite easy for rel-eng to adjust > > the release scripts to create a tag in the fedora-kickstarts repo (and > > why not fedora-comps too, while we're at it) for each 'candidate' > > compose, named for the compose ID. That would make it very easy to > > access the correct kickstarts for any Fedora candidate compose just by > > a 'git checkout', with no need for the cumbersome work of getting the > > package into the compose. > > > > Naturally this would go along with updates to any relevant docs or wiki > > pages, recommending to use the git repository instead of the RPM > > packages, and explaining the tagging scheme. As for the package, we > > could either keep it but not sweat about updating it for each release, > > retire it entirely, or change it to contain only a text file pointing > > to the git repository (or to the doc / wiki page that explains the git > > repo location and tagging strategy). > > > > Thoughts? Thanks! > > It makes perfect sense, the package is not actually shipped as part of > any of the actual deliverable artifacts and they're widely available > in a public git repository for people to consume so it's not reducing > the ability to reproduce Fedora, we don't rush around and ensure all > the tools that might need last minute patches in the compose process > are all tagged stable in the release either so I don't see actually > shipping this package as stable makes any difference in reality, we > don't even use the package in the compose process, we pull the > kickstarts directly from git. +1 too. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/3H3WQXVPTLYLC6ZVEL3XLVV6NS6QVCCX/
