On Tue, Jun 5, 2018 at 2:13 AM Zbigniew Jędrzejewski-Szmek
<zbyszek@in.waw.pl> wrote:
>
> 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@fedoraproject.org> 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.

Yes, let's do what makes sense.  I like the proposal.