(Example) |
No edit summary |
||
(One intermediate revision by the same user not shown) | |||
Line 8: | Line 8: | ||
*** Add the category to Spins_in_Development. Categories for previous releases of that spin should remain. | *** Add the category to Spins_in_Development. Categories for previous releases of that spin should remain. | ||
*** Make sure the content of their spin page is correct for the current release. | *** Make sure the content of their spin page is correct for the current release. | ||
*** They should change the link to the kickstart file to point to the HEAD of the appropriate release in the git repository. For example: <code> | *** They should change the link to the kickstart file to point to the HEAD of the appropriate release in the git repository. For example: <code>https://pagure.io/fedora-kickstarts/raw/f{{FedoraVersionNumber}}/f/fedora-live-games.ks</code> | ||
*** They should note the link to this specific version of the wiki page for their spin. They can get this by using the history tab and looking at the link for the current version. They should then add a link to this specific version in the "Previous releases" section (creating one if this is the first recurrence) with the name of the release (e.g. Fedora XX). You can do this using the fullurl macro. For example <code>[{{fullurl:Games_Spin|oldid=183119}} Fedora 13]</code>. | *** They should note the link to this specific version of the wiki page for their spin. They can get this by using the history tab and looking at the link for the current version. They should then add a link to this specific version in the "Previous releases" section (creating one if this is the first recurrence) with the name of the release (e.g. Fedora XX). You can do this using the fullurl macro. For example <code><nowiki>[{{fullurl:Games_Spin|oldid=183119}} Fedora 13]</nowiki></code>. | ||
*** They should then update the link to the kickstart file to point to the master branch of the git repository. For example: <code> | *** They should then update the link to the kickstart file to point to the master branch of the git repository. For example: <code>https://pagure.io/fedora-kickstarts/raw/master/f/fedora-live-games.ks</code> | ||
*** They should make any other changes to the spins page content that make sense at that time. (Particularly removing obsolete stuff from the previous release.) | *** They should make any other changes to the spins page content that make sense at that time. (Particularly removing obsolete stuff from the previous release.) | ||
** When their spin is ready for review for the upcoming release they should change the category to Spins_Ready_For_Wrangler. | ** When their spin is ready for review for the upcoming release they should change the category to Spins_Ready_For_Wrangler. |
Latest revision as of 00:29, 29 August 2016
Spins that are released over and over again, such as is the case when a spin is released for Fedora 40, then Fedora 41, then Fedora 42, and so forth, fall under the Recurring Spins process.
This process safe-guards that at least somebody looks at the spin itself as well as the Spin page, and prevents major changes to the spin from going unnoticed. It is not like all recurring spins will have to go through the entire review process step-by-step once more.
- Spin Maintainers
- If not planning to continue their spin should let the Spins SIG know.
- Shortly after release, the maintainer should:
- Add the category to Spins_in_Development. Categories for previous releases of that spin should remain.
- Make sure the content of their spin page is correct for the current release.
- They should change the link to the kickstart file to point to the HEAD of the appropriate release in the git repository. For example:
https://pagure.io/fedora-kickstarts/raw/f41/f/fedora-live-games.ks
- They should note the link to this specific version of the wiki page for their spin. They can get this by using the history tab and looking at the link for the current version. They should then add a link to this specific version in the "Previous releases" section (creating one if this is the first recurrence) with the name of the release (e.g. Fedora XX). You can do this using the fullurl macro. For example
[{{fullurl:Games_Spin|oldid=183119}} Fedora 13]
. - They should then update the link to the kickstart file to point to the master branch of the git repository. For example:
https://pagure.io/fedora-kickstarts/raw/master/f/fedora-live-games.ks
- They should make any other changes to the spins page content that make sense at that time. (Particularly removing obsolete stuff from the previous release.)
- When their spin is ready for review for the upcoming release they should change the category to Spins_Ready_For_Wrangler.
- Spins Wrangler or their delegate:
- Shortly after release the wrangler should verify that the above steps have been done.
- Before the Spins Freeze, all Spins pages should have been put back in the Spins_Ready_For_SIG category. For any that haven't been, the owners should be contacted to get an update on their spin.
- At spins freeze any spins that were not ready for the Spins SIG or approved, should have the discontinued spin process applied to them.
The Spins SIG then makes sure there is no significant changes causing the Spin to have to be re-evaluated, and if there's no such major changes, the Spins SIG can then autonomously approve the Spin. There's no further trademark approval required from the Fedora Project Board at this point.
Should there be major changes to a spin, then the process re-enters normal review and approval procedures.