Learn more about these different git repos.
Other Git URLs
So, I recently floated a proposal to remove the release criterion that requires a spin-kickstarts package that corresponds to the kickstarts used to create the release be included in the release. This has met with a generally positive response, but before I go ahead with it, I think we should ensure the proposed replacement is done already.
That idea is, every time a candidate compose is done, a tag should be created in the fedora-kickstarts repo with the compose's ID (and/or label). That way it's easy to get the correct kickstarts that match the compose: just check out the tag.
We could also do this for nightly composes, I guess, it just depends whether creating tons of tags causes any problems for git - I don't know if it does or not.
We could also tag the fedora-comps repo, possibly; it's less important in that case as the actual generated comps automatically become a part of the compose itself, but could still be useful.
Ideally this should be a part of the scripts that produce the compose, it should not be a manual step that the person doing the compose has to remember to do, as of course that introduces the possibility that they won't.
That idea is, every time a candidate compose is done, a tag should be created in the fedora-kickstarts repo with the compose's ID (and/or label).
seems a bit overkill. we could just make the criteria be that a tag is created in the repo that matches the gold compose we release. my preference here is that we only tag when we do a major release so that we don't have a million tags.
That way it's easy to get the correct kickstarts that match the compose:
That information is in the logs of the compose right?
Well, I just figured doing a tag for each candidate compose is the easiest way to ensure we have a tag for each release. Remember we don't do a lot of candidate composes - for F28 we only did 4. I don't see a way to do it only for the compose we actually release other than manually. But if you'd prefer to do it that way I'm fine with it, so long as we're solidly on top of actually doing the tag.
I wasn't planning to have a release criterion at all - if the process was automated it shouldn't really be necessary - but if we want to go with a manual process then that would make sense as a way to help ensure it gets done, I guess. I was kinda hoping to avoid that whole 'manual checking' thing, though.
I prefer one tag per release slightly better than tagging every release candidate, such that we can find what we shipped in the release instead of finding the release compose version number and matching that against the multiple tags that we might create for different release candidates.
Seems like a over kill for me.
We could also tag the fedora-comps repo, possibly;
I dont know what we can achieve from it, also the repo is just one master branch with all the release comps in it. We can still tag it, but that seems odd as it also has other release information.
I was kinda hoping to avoid that whole 'manual checking' thing, though.
+1, once every 6 months isn't too bad. and the way we've changed it (to not require an rpm but just make sure a tag is created) means it's not something where ordering and timing matter as much. I'm just trying to avoid us having to architect a process that does and blocking something else.
Either way works for me, just throwing out options.
Making sure a tag has been created is certainly a lot less effort than getting a package built and included in the final compose, no argument there. It'd still be an improvement.
I've sent out a proposal to replace the existing criterion with one requiring a repo tag to be done for Final.
We wound up implementing that proposal, so this is done now, I guess.
Metadata Update from @adamwill: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.