On 06/05/2018 07:59 AM, Stephen Gallagher wrote:
On Tue,
Jun 5, 2018 at 2:13 AM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> 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@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.
Yes, let's do what makes sense. I like the proposal.
And my axe! Err, or my +1, yeah.
Ditto! I've referenced these a number of times to see where my
variants have gone astray, but have always used the git repo for
this and hadn't even thought of looking for such an artifact. The
proposal of tags and docs will only make this easier.
|
