From Fedora Project Wiki

(update for Taskotron)
Line 1: Line 1:
{{header|qa}}
{{header|qa}}


With each new development release of Fedora (aka [[Releases/Branched|Branched]]), new package repositories are available for testing.  This page describes the changes to the AutoQA {{filename|repoinfo.conf}} file needed to accommodate a new release of Fedora.
With each new development release of Fedora (aka [[Releases/Branched|Branched]]), new package repositories are available for testing.  This page describes the changes to the Taskotron {{filename|yumrepoinfo.conf}} file needed to accommodate a new release of Fedora.


= Introduction =
= Introduction =
Line 7: Line 7:
Leading up to each release, the [[Releases/Rawhide|rawhide]] development stream is branched.  Branching results in two parallel development streams, called [[Releases/Rawhide|rawhide]] and [[Releases/Branched|branched]].  As always, ''rawhide'' continues to track the latest and greatest development intended for future releases of Fedora.  While, ''branched'' is intended for stabilization of the upcoming Fedora release.
Leading up to each release, the [[Releases/Rawhide|rawhide]] development stream is branched.  Branching results in two parallel development streams, called [[Releases/Rawhide|rawhide]] and [[Releases/Branched|branched]].  As always, ''rawhide'' continues to track the latest and greatest development intended for future releases of Fedora.  While, ''branched'' is intended for stabilization of the upcoming Fedora release.


The branch date can be found on the [http://poelstra.fedorapeople.org/schedules/f-{{FedoraVersion|number|next}}/f-{{FedoraVersion|number|next}}-releng-tasks.html release engineering schedule].
The branch date can be found in the [[Releases#Development|release schedule]].


= When to Update =
= When to Update =


The {{filename|repoinfo.conf}} file will need to change whenever a new package repository is available, the location of an existing repository changes or we no longer want to support an existing repository.  The most common scenarios where this happens are:
The {{filename|yumrepoinfo.conf}} file will need to change whenever a new package repository is available, the location of an existing repository changes or we no longer want to support an existing repository.  The most common scenarios where this happens are:
# When Fedora branches to stabilize the upcoming Fedora release
# When Fedora branches to stabilize the upcoming Fedora release
# When Fedora is released
# When Fedora is released
# When Fedora support has ended (it's EOL'd)
# When Fedora support has ended (it's EOL'd)


The AutoQA team will be notified by the [[ReleaseEngineering|release engineering]] or [[Infrastructure|infrastructure]] teams when either of the above events occur.  An AutoQA TRAC ticket will be filed to request the {{filename|repoinfo.conf}} changes (see [[Mass_Branching_SOP#Update_AutoQA_repoinfo.conf]], [[Release_Infrastructure_SOP#Step_5_.28AutoQA_repoinfo.conf.29]] and [[End_of_life_SOP#AutoQA]]).
The Taskotron team will be notified by the [[ReleaseEngineering|release engineering]] or [[Infrastructure|infrastructure]] teams when either of the above events occur.  A Taskotron ticket will be filed to request the {{filename|yumrepoinfo.conf}} changes (see [[Mass_Branching_SOP#Update_AutoQA_repoinfo.conf]], [[Release_Infrastructure_SOP#Step_5_.28AutoQA_repoinfo.conf.29]] and [[End_of_life_SOP#AutoQA]]).


= What To Update =
= What To Update =
Line 28: Line 28:
{{#tag:pre|
{{#tag:pre|
[rawhide]
[rawhide]
arches = i386, x86_64
url = %(rawhideurl)s
path = development/rawhide
path = development/rawhide
url = %(rawhideurl)s
tag = f{{FedoraVersion|number|next2}}
tag = f{{FedoraVersion|number|next2}}
collection_name = devel
release_status = rawhide
}}</li>
}}</li>
<li>Create new config sections for the current branch.  A section will be needed for each of the package repositories available.  For example, if branching for {{FedoraVersion|long|next}}, you would use the configuration listed below.  
<li>Create new config sections for the current branch.  A section will be needed for each of the package repositories available.  For example, if branching for {{FedoraVersion|long|next}}, you would use the configuration listed below.  
{{#tag:pre|
{{#tag:pre|
[f{{FedoraVersion||next}}]
[f{{FedoraVersion||next}}]
url = %(rawhideurl)s
path = development/{{FedoraVersion||next}}
path = development/{{FedoraVersion||next}}
url = %(rawhideurl)s
release_status = branched
collection_name = F-{{FedoraVersion||next}}
isactiverelease = yes
composes = yes


[f{{FedoraVersion||next}}-updates]
[f{{FedoraVersion||next}}-updates]
url = %(updatesurl)s
path = {{FedoraVersion||next}}
path = {{FedoraVersion||next}}
url = %(updatesurl)s
parent = f{{FedoraVersion||next}}
parents = f{{FedoraVersion||next}}
collection_name = F-{{FedoraVersion||next}}


[f{{FedoraVersion||next}}-updates-testing]
[f{{FedoraVersion||next}}-updates-testing]
url = %(updatesurl)s
path = testing/{{FedoraVersion||next}}
path = testing/{{FedoraVersion||next}}
url = %(updatesurl)s
parent = f{{FedoraVersion||next}}-updates
parents = f{{FedoraVersion||next}}-updates, f{{FedoraVersion||next}}
collection_name = F-{{FedoraVersion||next}}
}}</li></ol>
}}</li></ol>


Line 63: Line 58:
{{#tag:pre|
{{#tag:pre|
[f{{FedoraVersion|number|current}}]
[f{{FedoraVersion|number|current}}]
isactiverelease = yes
url = %(goldurl)s
path = {{FedoraVersion|number|current}}
path = {{FedoraVersion|number|current}}
url = %(goldurl)s
release_status = stable
collection_name = F-{{FedoraVersion|number|current}}
}}</li>
}}</li>
</ol>
</ol>
Line 77: Line 71:
{{#tag:pre|
{{#tag:pre|
[f{{FedoraVersion||previous2}}]
[f{{FedoraVersion||previous2}}]
isactiverelease = yes
url = %(goldurl)s
path = {{FedoraVersion||previous2}}
path = {{FedoraVersion||previous2}}
url = %(goldurl)s
release_status = stable
collection_name = F-{{FedoraVersion||previous2}}


[f{{FedoraVersion||previous2}}-updates]
[f{{FedoraVersion||previous2}}-updates]
url = %(updatesurl)s
path = {{FedoraVersion||previous2}}
path = {{FedoraVersion||previous2}}
url = %(updatesurl)s
parent = f{{FedoraVersion||previous2}}
parents = f{{FedoraVersion||previous2}}
collection_name = F-{{FedoraVersion||previous2}}


[f{{FedoraVersion||previous2}}-updates-testing]
[f{{FedoraVersion||previous2}}-updates-testing]
url = %(updatesurl)s
path = testing/{{FedoraVersion||previous2}}
path = testing/{{FedoraVersion||previous2}}
url = %(updatesurl)s
parent = f{{FedoraVersion||previous2}}-updates
parents = f{{FedoraVersion||previous2}}-updates, f{{FedoraVersion||previous2}}
collection_name = F-{{FedoraVersion||previous2}}
}}</li></ol>
}}</li></ol>


= How to Update =


Please use <code>git</code> to generate and submit patches for review by the AutoQA development team.  For information on AutoQA patch, please see [[AutoQA_Patch_Process#Patch_submission]]
[[Category:Taskotron]] [[Category:AutoQA]]
[[Category:AutoQA]]

Revision as of 09:06, 11 February 2015

QA.png


With each new development release of Fedora (aka Branched), new package repositories are available for testing. This page describes the changes to the Taskotron yumrepoinfo.conf file needed to accommodate a new release of Fedora.

Introduction

Leading up to each release, the rawhide development stream is branched. Branching results in two parallel development streams, called rawhide and branched. As always, rawhide continues to track the latest and greatest development intended for future releases of Fedora. While, branched is intended for stabilization of the upcoming Fedora release.

The branch date can be found in the release schedule.

When to Update

The yumrepoinfo.conf file will need to change whenever a new package repository is available, the location of an existing repository changes or we no longer want to support an existing repository. The most common scenarios where this happens are:

  1. When Fedora branches to stabilize the upcoming Fedora release
  2. When Fedora is released
  3. When Fedora support has ended (it's EOL'd)

The Taskotron team will be notified by the release engineering or infrastructure teams when either of the above events occur. A Taskotron ticket will be filed to request the yumrepoinfo.conf changes (see Mass_Branching_SOP#Update_AutoQA_repoinfo.conf, Release_Infrastructure_SOP#Step_5_.28AutoQA_repoinfo.conf.29 and End_of_life_SOP#AutoQA).

What To Update

New Fedora Branch

When a new Fedora branch release is available, the following changes are required.

  1. Update the the [rawhide] configuration. Change the value of tag to the koji tag for the next release. For example, if branching for Fedora 41, you would set tag = f42 as shown below:
    [rawhide]
    url = %(rawhideurl)s
    path = development/rawhide
    tag = f42
    release_status = rawhide
    
  2. Create new config sections for the current branch. A section will be needed for each of the package repositories available. For example, if branching for Fedora 41, you would use the configuration listed below.
    [f41]
    url = %(rawhideurl)s
    path = development/41
    release_status = branched
    
    [f41-updates]
    url = %(updatesurl)s
    path = 41
    parent = f41
    
    [f41-updates-testing]
    url = %(updatesurl)s
    path = testing/41
    parent = f41-updates
    

New Fedora Release

When a new release of Fedora is available, the following changes are required.

  1. Update the existing configuration for the recently released version of Fedora. For example, if Fedora 40 was just released, you would need to update the values for path and url as listed below.
    [f40]
    url = %(goldurl)s
    path = 40
    release_status = stable
    

Fedora support ended

When a Fedora release reaches its End of Life (EOL), the following changes are required.

  1. Remove the sections corresponding to the EOL'd release. For example, when Fedora 38 reaches EOL, the following sections would be removed:
    [f38]
    url = %(goldurl)s
    path = 38
    release_status = stable
    
    [f38-updates]
    url = %(updatesurl)s
    path = 38
    parent = f38
    
    [f38-updates-testing]
    url = %(updatesurl)s
    path = testing/38
    parent = f38-updates