On Mon, 2018-06-04 at 16:39 -0700, Adam Williamson 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!

So an update on this: as the response has generally been positive I'm
planning to go ahead with it, but I think we should make sure the repo
tagging thing is done *before* we remove the criterion. So I've filed
https://pagure.io/releng/issue/7568 for that. Once that's resolved I'll
go ahead with the criterion removal and docs updates.
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to