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!
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.
On Tue, 2018-06-12 at 12:11 -0700, Adam Williamson wrote:
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.
A further update here: it appears releng, at least for the present, is inclined to favour manual tagging of just the kickstarts for the actual release compose. Given that, I think we should still have a release criterion (since this will be a manual process we'd better have something to trigger us to make sure it happens). I propose we replace the existing criterion with this:
"At the time of the release, the [https://pagure.io/fedora-kickstarts fedora-kickstarts git repository] must have a tag matching the commit used to produce the accepted release candidate compose. The tag's name must clearly and unambiguously match the release number."
It'd probably be ideal to tag the repo for Beta releases too, but we probably only need to *require* the tag to be done for Final.
How's that sound?
On Tue, 2018-06-19 at 17:33 -0700, Adam Williamson wrote:
A further update here: it appears releng, at least for the present, is inclined to favour manual tagging of just the kickstarts for the actual release compose. Given that, I think we should still have a release criterion (since this will be a manual process we'd better have something to trigger us to make sure it happens). I propose we replace the existing criterion with this:
"At the time of the release, the [https://pagure.io/fedora-kickstarts fedora-kickstarts git repository] must have a tag matching the commit used to produce the accepted release candidate compose. The tag's name must clearly and unambiguously match the release number."
It'd probably be ideal to tag the repo for Beta releases too, but we probably only need to *require* the tag to be done for Final.
How's that sound?
As there were no complaints, I'm going ahead and making this change now.
-
Adam Williamson