Ticket #5215 (closed task: fixed)

Opened 4 years ago

Last modified 2 months ago

Stage comps and spin-kickstarts during freezes

Reported by: adamwill Owned by: rel-eng@…
Milestone: Fedora 23 Alpha Component: git
Keywords: planning Cc: kevin
Blocked By: Blocking:

Description

As noted on the F17 QA retrospective by me and Bruno Wolff:

https://fedoraproject.org/wiki/Fedora_17_QA_Retrospective

it's a problem that we use git master of both comps and spin-kickstarts for composes - not the latest packaged version - and both these git repos are not frozen during freezes.

During the 17 cycle, we had a concrete example of a comps change during a freeze causing considerable trouble: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=807879 - pulling Boxes into comps during the Beta freeze made that issue a serious problem. For spin-kickstarts, the same kind of thing is possible, and we also have a release criterion requiring a spin-kickstarts package which matches the .ks files used for the compose to be present in the release repository; obviously, the lack of a git freeze makes this tricky to ensure.

So we would strongly recommend, at minimum, a mechanism for freezing spin-kickstarts and comps at Alpha, Beta and Final freeze. Post-freeze changes could be made following the same blocker/NTH process used for other post-freeze changes.

Change History

comment:1 Changed 16 months ago by ausil

  • Keywords planning added
  • Milestone changed from Fedora 18 Alpha to Fedora 23 Alpha

It is not a bad idea. we will need to evaluate how we can achieve it.

comment:2 follow-up: ↓ 5 Changed 4 months ago by acarter

Consider moving comps and spin kickstarts into Pagure and limit commit access to releng (or a very limited set beyond that) to solve this problem.

comment:3 Changed 4 months ago by acarter

  • Cc kfenzi added

comment:4 Changed 4 months ago by acarter

  • Cc kevin added; kfenzi removed

comment:5 in reply to: ↑ 2 Changed 4 months ago by pbrobinson

Replying to acarter:

Consider moving comps and spin kickstarts into Pagure and limit commit access to releng (or a very limited set beyond that) to solve this problem.

Well if we limit commit access it would have to be on a specific branch because neither rawhide or stable releases freeze comps (on all releases) or kickstarts (specifically on rawhide, might need changes for a CVE release on stable releases).

The other way it could be done is with git tags, where we create a tag each time we need to adjust the ks and use that in pungi. At the moment in pungi we just specify the branch HEAD (see below) there's no reason that couldn't be a commit hash (or short hash) or a tag. That wouldn't need any development, although being able to specify a global ksurl would be useful as the same URL is currently in the config 12 times.

'ksurl': 'git://git.fedorahosted.org/git/spin-kickstarts.git?#origin/f24'

comment:6 Changed 4 months ago by ausil

The idea is that anyone can submit pull requests, we can then setup ci testing on all pull requests so we can make sure people do not break anything any commits for rawhide can and should be pulled at any time so long as they do not break comps validation. but we can ensure that we want the change in branched or stable releases and control when they land.

We could do it y specifying a commit reference in the pungi config. however I see more value in validating all commits.

comment:7 Changed 2 months ago by ausil

  • Status changed from new to closed
  • Resolution set to fixed

closing this ticket as I feel we have a way now to do staging and controlled merges with pagure

Note: See TracTickets for help on using tickets.