https://fedoraproject.org/w/api.php?action=feedcontributions&user=Jwboyer&feedformat=atomFedora Project Wiki - User contributions [en]2024-03-19T03:35:16ZUser contributionsMediaWiki 1.39.4https://fedoraproject.org/w/index.php?title=Development/SteeringCommittee/Nominations&diff=508330Development/SteeringCommittee/Nominations2018-01-03T13:11:51Z<p>Jwboyer: </p>
<hr />
<div><!-- {{admon/important|Collection of questions for [[Elections/Questionnaire|Questionnaire]] is in progress.|The collection period ends on 2017-Nov-20 at 23:59:59]}} --><br />
<!-- {{admon/important|Collection of questions for candidates begins on 2017-Oct-24 at 00:00 UTC}} --><br />
<!--{{admon/important|Nomination period is not yet open.|The nomination period starts on 2018-Jan-03 at 00:00:00 UTC}}--><br />
{{admon/important|Nomination & Campaign period is now open.|The period ends on 2018-Jan-10 at 23:59:59 UTC}}<br />
<!-- {{admon/important|Nomination & Campaign period for FESCo is now open.|The period ends on 2017-Dec-07 at 23:59:59 UTC}} --><br />
<br />
The following [[Elections|elections]] take place in January 2018:<br />
<br />
* [[Development/SteeringCommittee/Nominations|FESCo (Engineering)]] (five seats)<br />
<br />
More information about FESCo on [[Fedora_Engineering_Steering_Committee|FESCo wiki page]].<br />
<br />
= FESCo Elections January 2018 =<br />
As per the [[FESCo_election_policy|FESCo election policy]], the following FESCo members finish their terms, and the seats are up for re-election:<br />
<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) - elected for F26/F27 period<br />
* [[User:Maxamillion|Adam Miller]] (maxamillion) - elected for F26/F27 period<br />
* [[User:Jsmith|Jared Smith]] (jsmith) - elected for F26/F27 period<br />
* [[User:Jforbes|Justin Forbes]] (jforbes) - elected for F26/F27 period<br />
* [[User:Kalev|Kalev Lember]] (kalev) - elected for F26/F27 period<br />
<br />
For the last election, see [https://fedoraproject.org/w/index.php?title=Development/SteeringCommittee/Nominations&oldid=499699 Nominations August 2017]<br />
<br />
{{admon/note|Eligible Voters|Voting eligibility is determined by a community member's Fedora Account System ([https://admin.fedoraproject.org/accounts/ FAS]) memberships.<br/>To vote for [[Fedora_Engineering_Steering_Committee|FESCo]] you must have cla_done + one other "non-cla" group in FAS.}}<br />
<br />
{{admon/note|Community Blog Interview|A set of questions for nominees is prepared as [[Elections/Questionnaire|Questionnaire]]. The [https://pagure.io/fesco/issue/1805 top 3 selected questions] are published in [https://pagure.io/fedora-project-schedule/blob/master/f/elections/2018-January Pagure]. Nominees are requested to answer these [https://pagure.io/fedora-project-schedule/blob/master/f/elections/2018-January selected questions] using '''[https://pagure.io/fedora-project-schedule/issues private issue in Pagure]'''. In this way only [https://fedoraproject.org/wiki/User:Jkurik Election Wrangler] and [https://fedoraproject.org/wiki/User:Bex Fedora Action and Impact Coordinator] (as election wrangler substitute) are allowed to see these answers. In compliance with Fedora Council [https://pagure.io/Fedora-Council/tickets/issue/135 decision #135] nominees not having completed their interviews (as a [https://pagure.io/fedora-project-schedule/issues private issue in Pagure]) are excluded from the list of nominees.}}<br />
<br />
[[Category:FESCo]] [[Category:Elections]]<br />
<br />
== Candidate Nominations ==<br />
Please nominate just by Name, IRC nick and FAS account ID.<br />
<br />
You may self-nominate. If you wish to nominate someone else, please consult with that person ahead of time.<br />
<br />
{|class="wikitable"<br />
|- style=" color: #fff; background-color: #3074c2;" tablewidth="98%" <br />
| '''Name''' || '''FAS / IRC nick''' ||''' Nominated by ''' <br />
|-<br />
| Josh Boyer || jwboyer/jwb || mattdm<br />
|-<br />
|}</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Previous_Fedora_Engineering_Steering_Committee_Members&diff=500682Previous Fedora Engineering Steering Committee Members2017-09-01T12:41:38Z<p>Jwboyer: /* Members of January 2017 - August 2017 */</p>
<hr />
<div>= Previous Extras Steering Committees =<br />
<br />
The following are the members of previous FESCos.<br />
<br />
=== Members of January 2017 - August 2017 ===<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) - F26/F27<br />
* [[User:Jwboyer| Josh Boyer]] (jwb) - F25/F26<br />
* [[User:Maxamillion|Adam Miller]] (maxamillion) - F26/F27<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore) - F25/F26<br />
* [[User:Jsmith|Jared Smith]] (jsmith) - F26/F27<br />
* [[User:Jforbes|Justin Forbes]] (jforbes) - F26/F27<br />
* [[User:Kalev|Kalev Lember]] (kalev) - F26/F27<br />
* [[User:Rathann| Dominik Mierzejewski]] (rathann) - F25/F26<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh) - F25/F26<br />
<br />
=== Members of July 2016 - January 2017 ===<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) - F24/F25<br />
* [[User:Jwboyer| Josh Boyer]] (jwb) - F25/F26<br />
* [[User:Maxamillion|Adam Miller]] (maxamillion) - F24/F25<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore) - F25/F26<br />
* [[User:Jsmith|Jared Smith]] (jsmith) - F24/F25<br />
* [[User:Pnemade|Parag Nemade]] (paragan) - F24/F25<br />
* [[User:Kalev|Kalev Lember]] (kalev) - F24/F25<br />
* [[User:Rathann| Dominik Mierzejewski]] (rathann) - F25/F26<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh) - F25/F26<br />
<br />
=== Members of December 2015 - July 2016 ===<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) - F24/F25<br />
* [[User:Jwboyer| Josh Boyer]] (jwb) - F23/F24<br />
* [[User:Maxamillion|Adam Miller]] (maxamillion) - F24/F25<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore) - F23/F24<br />
* [[User:Jsmith|Jared Smith]] (jsmith) - F24/F25<br />
* [[User:Pnemade|Parag Nemade]] (paragan) - F24/F25<br />
* [[User:Kalev|Kalev Lember]] (kalev) - F24/F25<br />
* [[User:Hguemar| Haïkel Guémar]] (hguemar) - F23/F24<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh) - F23/F24<br />
<br />
=== Members of June 2015 - December 2015 ===<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) - F22/F23<br />
* [[User:Jwboyer| Josh Boyer]] (jwb) - F23/F24<br />
* [[User:Thozza| Tomas Hozza]] (thozza) - F22/F23<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore) - F23/F24<br />
* [[User:Ajax|Adam Jackson]] (ajax) - F22/F23<br />
* [[User:Pnemade|Parag Nemade]] (paragan) - F22/F23<br />
* [[User:Rishi|Debarshi Ray]] (rishi) - F22/F23<br />
* [[User:Hguemar| Haïkel Guémar]] (hguemar) - F23/F24<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh) - F23/F24<br />
<br />
=== Members of February 2015 - June 2015 ===<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) - F22/F23<br />
* [[User:Jwboyer| Josh Boyer]] (jwb) - F21/F22<br />
* [[User:Thozza| Tomas Hozza]] (thozza) - F22/F23<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore) - F21/F22<br />
* [[User:Mitr| Miloslav Trmač]] (mitr) - F21/F22<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh) - F21/F22<br />
* [[User:Ajax| Adam Jackson]] (ajax) - F22/F23<br />
* [[User:Pnemade| Parag Nemade]] (paragan) - F22/F23<br />
* [[User:Rishi| Debarshi Ray]] (rishi) - F22/F23<br />
<br />
=== Members of Feb 2014 - February 2015 (after special elections in June) ===<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) - F20/F21<br />
* [[User:Jwboyer| Josh Boyer]] (jwb) - F21/F22<br />
* [[User:Thozza| Tomas Hozza]] (thozza) - F20/F21<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore) - F21/F22<br />
* [[User:Kalev|Kalev Lember]] (kalev) - F20/F21<br />
* [[User:Mattdm|Matthew Miller]] (mattdm) - F20/F21<br />
* [[User:Tmraz|Tomáš Mráz]] (t8m) - F20/F21<br />
* [[User:Mitr| Miloslav Trmač]] (mitr) - F21/F22<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh) - F21/F22<br />
<br />
=== Members of Fifteenth FESco (Jun 2013 - Feb 2014) ===<br />
<br />
* [[User:Kevin| Kevin Fenzi]] (nirik)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Toshio| Toshio Kuratomi]] (toshio)<br />
* [[User:Mmaslano| Marcela Mašláňová]] (mmaslano)<br />
* [[User:Pjones| Peter Jones]] (pjones)<br />
* [[User:Mattdm| Matthew Miller]] (mattdm)<br />
* [[User:Tmraz| Tomáš Mráz]] (t8m)<br />
* [[User:Mitr| Miloslav Trmač]] (mitr)<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh)<br />
<br />
=== Members of Eleventh FESco (Dec 2011 - current) ===<br />
<br />
* [[User:Kevin| Kevin Fenzi]] (nirik)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Mjg59| Matthew Garrett]] (mjg59)<br />
* [[User:Mmaslano| Marcela Mašláňová]] (mmaslano)<br />
* [[User:Pjones| Peter Jones]] (pjones)<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh)<br />
* [[User:Tmraz| Tomáš Mráz]] (t8m)<br />
* [[User:Mitr| Miloslav Trmač]] (mitr)<br />
* [[User:Limb| Jon Ciesla]] (limburgher)<br />
<br />
Chair is rotating.<br />
<br />
=== Members of Tenth FESco (Jun 2011 - Dec 2011) ===<br />
<br />
* [[User:Kevin| Kevin Fenzi]] (nirik)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Ajax| Adam Jackson]] (ajax)<br />
* [[User:Cwickert| Christoph Wickert]] (cwickert)<br />
* [[User:Mjg59| Matthew Garrett]] (mjg59)<br />
* [[User:Mmaslano|Marcela Mašláňová]] (mmaslano)<br />
* [[User:Pjones|Peter Jones]] (pjones)<br />
* [[User:Sgallagh|Stephen Gallagher]] (sgallagh)<br />
* [[User:Tmraz|Tomáš Mráz]] (t8m)<br />
<br />
Chair is rotating.<br />
<br />
=== Members of Ninth FESCo (Jan 2011 - Jun 2011) ===<br />
<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) (Chair)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Ajax| Adam Jackson]] (ajax)<br />
* [[User:Cwickert| Christoph Wickert]] (cwickert)<br />
* [[User:Mjg59| Matthew Garrett]] (mjg59)<br />
* [[User:Kyle| Kyle McMartin]] (kyle)<br />
* [[User:Tuxbrewr| Steven M. Parrish]] (tuxbrewr)<br />
* [[User:Mclasen|Matthias Clasen]] (mclasen)<br />
* [[User:Mmaslano|Marcela Mašláňová]] (mmaslano)<br />
<br />
=== Members of Eighth FESCo (May 2010 - Dec 2010) ===<br />
<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) (Chair)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Ajax| Adam Jackson]] (ajax)<br />
* [[User:Cwickert| Christoph Whickert]] (cwickert)<br />
* [[User:Mjg59| Matthew Garrett]] (mjg59)<br />
* [[User:Kyle| Kyle McMartin]] (kyle)<br />
* [[User:Tuxbrewr| Steven M. Parrish]] (tuxbrewr)<br />
* [[User:Mclasen|Matthias Clasen]] (mclasen)<br />
* [[User:Pjones|Peter Jones]] (pjones)<br />
<br />
=== Members of Seventh FESCo (Jan 2010 - May 2010) ===<br />
<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) (Chair)<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Skvidal| Seth Vidal]] (skvidal)<br />
* [[User:Kkofler| Kevin Kofler]] (kkofler)<br />
* [[User:Ajax| Adam Jackon]] (ajax)<br />
* [[User:Cwickert| Christoph Whickert]] (cwickert)<br />
* [[User:Pjones| Peter Jones]] (pjones)<br />
* [[User:Mjg59| Matthew Garrett]] (mjg59)<br />
<br />
=== Members of Sixth FESCo (Jul 2009 - Dec 2009) ===<br />
* [[User:Jwboyer| Josh Boyer]] (jwb) - left FESCo in November 2009<br />
<br />
=== Members of Fifth FESCo (Dec 2008 - Jul 2009) ===<br />
* [[User:Jwboyer| Josh Boyer]] (jwb)<br />
* [[User:Kevin| Kevin Fenzi]] (nirik)<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore)<br />
* [[User:Sharkcz| Dan Horák]] (sharkcz)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Bpepple| Brian Pepple]] (bpepple)<br />
* [[User:Jstanley| Jon Stanley]] (jds2001) (Chair)<br />
* [[User:Jwilson| Jarod Wilson]] (j-rod)<br />
* [[User:Dwmw2| David Woodhouse]] (dwmw2)<br />
<br />
=== Members of fourth FESCo (Jul 2008 - Dec 2008) ===<br />
* [[User:Kevin| Kevin Fenzi]] (nirik)<br />
* [[User:Bpepple| Brian Pepple]] (bpepple) (chair)<br />
* [[User:Jwboyer| Josh Boyer]] (jwb)<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Dwmw2| David Woodhouse]] (dwmw2)<br />
* [[User:Karsten| Karsten Hopp]] (kick_)<br />
* [[User:Jstanley| Jon Stanley]] (jds2001)<br />
* [[User:Jwilson| Jarod Wilson]] (j-rod)<br />
<br />
=== Members of third FESCo (Jul 2007 - Jul 2008) ===<br />
<br />
* [[User:Katzj| Jeremy Katz]] (jeremy)<br />
* [[User:Spot| Tom Callaway]] (spot)<br />
* [[User:Kevin| Kevin Fenzi]] (nirik)<br />
* [[User:Wtogami| Warren Togami]] (warren)<br />
* [[User:Bpepple| Brian Pepple]] (bpepple) (chair)<br />
* [[User:Tibbs| Jason Tibbitts]] (tibbs)<br />
* [[User:C4chris| Christian Iseli]] (c4chris)<br />
* [[User:Jwboyer| Josh Boyer]] (jwb)<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore)<br />
* [[User:Jkeating| Jesse Keating]] (f13)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Dwmw2| David Woodhouse]] (dwmw2)<br />
* [[User:Caillon| Christopher Aillon]] (caillon)<br />
<br />
=== Members of second FESCo (Jun 2006 - Jul 2007) ===<br />
<br />
* [[ThorstenLeemhuis| Thorsten Leemhuis]] (thl) - chair until January 2007; left FESCo in February 2007 as being a member of FESCo became conflicting with his day job due to the Core and Extras merge<br />
* [[VilleSkyttä]] (scop) -- left FESCo in January 2007<br />
* [[AndreasBierfert]] (awjb) -- left FESCo in February 2007 due to time constraints<br />
* [[JeremyKatz]] (jeremy)<br />
* [[TomCallaway]] (spot)<br />
* [[KevinFenzi]] (nirik)<br />
* [[WarrenTogami]] (warren)<br />
* [[RexDieter]] (rdieter)<br />
* [[BrianPepple]] (bpepple) - chair since February 2007<br />
* [[JasonTibbitts]] (tibbs)<br />
* [[ChristianIseli]] (c4chris)<br />
* [[ToshioKuratomi]] (abadger1999)<br />
* [[JoshBoyer]] (jwb)<br />
* [[DennisGilmore]] (dgilmore)<br />
* [[JesseKeating]] (f13)<br />
* [[BillNottingham]] (notting)<br />
<br />
=== Members of the original FESCo (Feb 2005 - Jun 2006) ===<br />
<br />
* [[AdrianReber]] (adrianr)<br />
* [[ColinCharles]] (bytee)<br />
* [[DamsNadé]] (Anvil)<br />
* [[ElliotLee]] (Sopwith)<br />
* [[EnricoScholl]] (ensc)<br />
* [[GregDeKoenigsberg]] (gregdek) - founder and chair until January 2006<br />
* [[JeremyKatz]] (jeremy)<br />
* [[JesseKeating]] (f13)<br />
* [[Jose-PedroOliviera]] (jpo)<br />
* [[MatthiasSaou]] (thias)<br />
* [[MichaelSchwendt]] (mschwendt)<br />
* [[SethVidal]] (skvidal)<br />
* [[ThomasVanderStichele]] (thomasvs)<br />
* [[ThorstenLeemhuis| Thorsten Leemhuis]] (thl) - chair since January 2006<br />
* [[TomCallaway]] (spot)<br />
* [[VilleSkyttä]] (scop)<br />
* [[WarrenTogami]] (warren)<br />
<br />
[[Category:FESCo]]</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Previous_Fedora_Engineering_Steering_Committee_Members&diff=500680Previous Fedora Engineering Steering Committee Members2017-09-01T12:40:45Z<p>Jwboyer: /* Previous Extras Steering Committees */</p>
<hr />
<div>= Previous Extras Steering Committees =<br />
<br />
The following are the members of previous FESCos.<br />
<br />
=== Members of January 2017 - August 2017 ===<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) - F26/F27<br />
* [[User:Jwboyer| Josh Boyer]] (jwb) - F25/F26<br />
* [[User:Maxamillion|Adam Miller]] (maxamillion) - F26/F27<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore) - F25/F26<br />
* [[User:Jsmith|Jared Smith]] (jsmith) - F26/F27<br />
* [[User:Pnemade|Parag Nemade]] (paragan) - F24/F25<br />
* [[User:Kalev|Kalev Lember]] (kalev) - F26/F27<br />
* [[User:Rathann| Dominik Mierzejewski]] (rathann) - F25/F26<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh) - F25/F26<br />
<br />
=== Members of July 2016 - January 2017 ===<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) - F24/F25<br />
* [[User:Jwboyer| Josh Boyer]] (jwb) - F25/F26<br />
* [[User:Maxamillion|Adam Miller]] (maxamillion) - F24/F25<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore) - F25/F26<br />
* [[User:Jsmith|Jared Smith]] (jsmith) - F24/F25<br />
* [[User:Pnemade|Parag Nemade]] (paragan) - F24/F25<br />
* [[User:Kalev|Kalev Lember]] (kalev) - F24/F25<br />
* [[User:Rathann| Dominik Mierzejewski]] (rathann) - F25/F26<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh) - F25/F26<br />
<br />
=== Members of December 2015 - July 2016 ===<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) - F24/F25<br />
* [[User:Jwboyer| Josh Boyer]] (jwb) - F23/F24<br />
* [[User:Maxamillion|Adam Miller]] (maxamillion) - F24/F25<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore) - F23/F24<br />
* [[User:Jsmith|Jared Smith]] (jsmith) - F24/F25<br />
* [[User:Pnemade|Parag Nemade]] (paragan) - F24/F25<br />
* [[User:Kalev|Kalev Lember]] (kalev) - F24/F25<br />
* [[User:Hguemar| Haïkel Guémar]] (hguemar) - F23/F24<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh) - F23/F24<br />
<br />
=== Members of June 2015 - December 2015 ===<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) - F22/F23<br />
* [[User:Jwboyer| Josh Boyer]] (jwb) - F23/F24<br />
* [[User:Thozza| Tomas Hozza]] (thozza) - F22/F23<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore) - F23/F24<br />
* [[User:Ajax|Adam Jackson]] (ajax) - F22/F23<br />
* [[User:Pnemade|Parag Nemade]] (paragan) - F22/F23<br />
* [[User:Rishi|Debarshi Ray]] (rishi) - F22/F23<br />
* [[User:Hguemar| Haïkel Guémar]] (hguemar) - F23/F24<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh) - F23/F24<br />
<br />
=== Members of February 2015 - June 2015 ===<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) - F22/F23<br />
* [[User:Jwboyer| Josh Boyer]] (jwb) - F21/F22<br />
* [[User:Thozza| Tomas Hozza]] (thozza) - F22/F23<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore) - F21/F22<br />
* [[User:Mitr| Miloslav Trmač]] (mitr) - F21/F22<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh) - F21/F22<br />
* [[User:Ajax| Adam Jackson]] (ajax) - F22/F23<br />
* [[User:Pnemade| Parag Nemade]] (paragan) - F22/F23<br />
* [[User:Rishi| Debarshi Ray]] (rishi) - F22/F23<br />
<br />
=== Members of Feb 2014 - February 2015 (after special elections in June) ===<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) - F20/F21<br />
* [[User:Jwboyer| Josh Boyer]] (jwb) - F21/F22<br />
* [[User:Thozza| Tomas Hozza]] (thozza) - F20/F21<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore) - F21/F22<br />
* [[User:Kalev|Kalev Lember]] (kalev) - F20/F21<br />
* [[User:Mattdm|Matthew Miller]] (mattdm) - F20/F21<br />
* [[User:Tmraz|Tomáš Mráz]] (t8m) - F20/F21<br />
* [[User:Mitr| Miloslav Trmač]] (mitr) - F21/F22<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh) - F21/F22<br />
<br />
=== Members of Fifteenth FESco (Jun 2013 - Feb 2014) ===<br />
<br />
* [[User:Kevin| Kevin Fenzi]] (nirik)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Toshio| Toshio Kuratomi]] (toshio)<br />
* [[User:Mmaslano| Marcela Mašláňová]] (mmaslano)<br />
* [[User:Pjones| Peter Jones]] (pjones)<br />
* [[User:Mattdm| Matthew Miller]] (mattdm)<br />
* [[User:Tmraz| Tomáš Mráz]] (t8m)<br />
* [[User:Mitr| Miloslav Trmač]] (mitr)<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh)<br />
<br />
=== Members of Eleventh FESco (Dec 2011 - current) ===<br />
<br />
* [[User:Kevin| Kevin Fenzi]] (nirik)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Mjg59| Matthew Garrett]] (mjg59)<br />
* [[User:Mmaslano| Marcela Mašláňová]] (mmaslano)<br />
* [[User:Pjones| Peter Jones]] (pjones)<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh)<br />
* [[User:Tmraz| Tomáš Mráz]] (t8m)<br />
* [[User:Mitr| Miloslav Trmač]] (mitr)<br />
* [[User:Limb| Jon Ciesla]] (limburgher)<br />
<br />
Chair is rotating.<br />
<br />
=== Members of Tenth FESco (Jun 2011 - Dec 2011) ===<br />
<br />
* [[User:Kevin| Kevin Fenzi]] (nirik)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Ajax| Adam Jackson]] (ajax)<br />
* [[User:Cwickert| Christoph Wickert]] (cwickert)<br />
* [[User:Mjg59| Matthew Garrett]] (mjg59)<br />
* [[User:Mmaslano|Marcela Mašláňová]] (mmaslano)<br />
* [[User:Pjones|Peter Jones]] (pjones)<br />
* [[User:Sgallagh|Stephen Gallagher]] (sgallagh)<br />
* [[User:Tmraz|Tomáš Mráz]] (t8m)<br />
<br />
Chair is rotating.<br />
<br />
=== Members of Ninth FESCo (Jan 2011 - Jun 2011) ===<br />
<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) (Chair)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Ajax| Adam Jackson]] (ajax)<br />
* [[User:Cwickert| Christoph Wickert]] (cwickert)<br />
* [[User:Mjg59| Matthew Garrett]] (mjg59)<br />
* [[User:Kyle| Kyle McMartin]] (kyle)<br />
* [[User:Tuxbrewr| Steven M. Parrish]] (tuxbrewr)<br />
* [[User:Mclasen|Matthias Clasen]] (mclasen)<br />
* [[User:Mmaslano|Marcela Mašláňová]] (mmaslano)<br />
<br />
=== Members of Eighth FESCo (May 2010 - Dec 2010) ===<br />
<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) (Chair)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Ajax| Adam Jackson]] (ajax)<br />
* [[User:Cwickert| Christoph Whickert]] (cwickert)<br />
* [[User:Mjg59| Matthew Garrett]] (mjg59)<br />
* [[User:Kyle| Kyle McMartin]] (kyle)<br />
* [[User:Tuxbrewr| Steven M. Parrish]] (tuxbrewr)<br />
* [[User:Mclasen|Matthias Clasen]] (mclasen)<br />
* [[User:Pjones|Peter Jones]] (pjones)<br />
<br />
=== Members of Seventh FESCo (Jan 2010 - May 2010) ===<br />
<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) (Chair)<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Skvidal| Seth Vidal]] (skvidal)<br />
* [[User:Kkofler| Kevin Kofler]] (kkofler)<br />
* [[User:Ajax| Adam Jackon]] (ajax)<br />
* [[User:Cwickert| Christoph Whickert]] (cwickert)<br />
* [[User:Pjones| Peter Jones]] (pjones)<br />
* [[User:Mjg59| Matthew Garrett]] (mjg59)<br />
<br />
=== Members of Sixth FESCo (Jul 2009 - Dec 2009) ===<br />
* [[User:Jwboyer| Josh Boyer]] (jwb) - left FESCo in November 2009<br />
<br />
=== Members of Fifth FESCo (Dec 2008 - Jul 2009) ===<br />
* [[User:Jwboyer| Josh Boyer]] (jwb)<br />
* [[User:Kevin| Kevin Fenzi]] (nirik)<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore)<br />
* [[User:Sharkcz| Dan Horák]] (sharkcz)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Bpepple| Brian Pepple]] (bpepple)<br />
* [[User:Jstanley| Jon Stanley]] (jds2001) (Chair)<br />
* [[User:Jwilson| Jarod Wilson]] (j-rod)<br />
* [[User:Dwmw2| David Woodhouse]] (dwmw2)<br />
<br />
=== Members of fourth FESCo (Jul 2008 - Dec 2008) ===<br />
* [[User:Kevin| Kevin Fenzi]] (nirik)<br />
* [[User:Bpepple| Brian Pepple]] (bpepple) (chair)<br />
* [[User:Jwboyer| Josh Boyer]] (jwb)<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Dwmw2| David Woodhouse]] (dwmw2)<br />
* [[User:Karsten| Karsten Hopp]] (kick_)<br />
* [[User:Jstanley| Jon Stanley]] (jds2001)<br />
* [[User:Jwilson| Jarod Wilson]] (j-rod)<br />
<br />
=== Members of third FESCo (Jul 2007 - Jul 2008) ===<br />
<br />
* [[User:Katzj| Jeremy Katz]] (jeremy)<br />
* [[User:Spot| Tom Callaway]] (spot)<br />
* [[User:Kevin| Kevin Fenzi]] (nirik)<br />
* [[User:Wtogami| Warren Togami]] (warren)<br />
* [[User:Bpepple| Brian Pepple]] (bpepple) (chair)<br />
* [[User:Tibbs| Jason Tibbitts]] (tibbs)<br />
* [[User:C4chris| Christian Iseli]] (c4chris)<br />
* [[User:Jwboyer| Josh Boyer]] (jwb)<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore)<br />
* [[User:Jkeating| Jesse Keating]] (f13)<br />
* [[User:Notting| Bill Nottingham]] (notting)<br />
* [[User:Dwmw2| David Woodhouse]] (dwmw2)<br />
* [[User:Caillon| Christopher Aillon]] (caillon)<br />
<br />
=== Members of second FESCo (Jun 2006 - Jul 2007) ===<br />
<br />
* [[ThorstenLeemhuis| Thorsten Leemhuis]] (thl) - chair until January 2007; left FESCo in February 2007 as being a member of FESCo became conflicting with his day job due to the Core and Extras merge<br />
* [[VilleSkyttä]] (scop) -- left FESCo in January 2007<br />
* [[AndreasBierfert]] (awjb) -- left FESCo in February 2007 due to time constraints<br />
* [[JeremyKatz]] (jeremy)<br />
* [[TomCallaway]] (spot)<br />
* [[KevinFenzi]] (nirik)<br />
* [[WarrenTogami]] (warren)<br />
* [[RexDieter]] (rdieter)<br />
* [[BrianPepple]] (bpepple) - chair since February 2007<br />
* [[JasonTibbitts]] (tibbs)<br />
* [[ChristianIseli]] (c4chris)<br />
* [[ToshioKuratomi]] (abadger1999)<br />
* [[JoshBoyer]] (jwb)<br />
* [[DennisGilmore]] (dgilmore)<br />
* [[JesseKeating]] (f13)<br />
* [[BillNottingham]] (notting)<br />
<br />
=== Members of the original FESCo (Feb 2005 - Jun 2006) ===<br />
<br />
* [[AdrianReber]] (adrianr)<br />
* [[ColinCharles]] (bytee)<br />
* [[DamsNadé]] (Anvil)<br />
* [[ElliotLee]] (Sopwith)<br />
* [[EnricoScholl]] (ensc)<br />
* [[GregDeKoenigsberg]] (gregdek) - founder and chair until January 2006<br />
* [[JeremyKatz]] (jeremy)<br />
* [[JesseKeating]] (f13)<br />
* [[Jose-PedroOliviera]] (jpo)<br />
* [[MatthiasSaou]] (thias)<br />
* [[MichaelSchwendt]] (mschwendt)<br />
* [[SethVidal]] (skvidal)<br />
* [[ThomasVanderStichele]] (thomasvs)<br />
* [[ThorstenLeemhuis| Thorsten Leemhuis]] (thl) - chair since January 2006<br />
* [[TomCallaway]] (spot)<br />
* [[VilleSkyttä]] (scop)<br />
* [[WarrenTogami]] (warren)<br />
<br />
[[Category:FESCo]]</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Fedora_Engineering_Steering_Committee&diff=500679Fedora Engineering Steering Committee2017-09-01T12:38:13Z<p>Jwboyer: /* Members */</p>
<hr />
<div><!-- page was renamed from Extras/SteeringCommittee<br />
--><br />
<br />
{{autolang|base=yes}}<br />
<br />
FESCo is the Fedora Engineering Steering Committee. It is a fully community elected body and represents the technical leadership in Fedora. <br />
<br />
== Overall Mission ==<br />
<br />
FESCo handles the process of accepting new features, the acceptance of new packaging sponsors, Special Interest Groups (SIGs) and SIG Oversight, the packaging process, handling and enforcement of maintainer issues and other technical matters related to the distribution and its construction.<br />
<br />
== Common tasks and responsibilities ==<br />
<br />
FESCo is responsible for technical issues and coordination of technical resources for the project.<br />
<br />
Issues FESCo handles include:<br />
<br />
* Approval and coordination of "changes" for Fedora releases.<br />
* Package maintainer disputes<br />
* Larger changes to the Fedora Package collection<br />
* Guidance and technical direction for other parts of the project<br />
* Setting the schedule for Fedora development cycles.<br />
* Reviewing and approving technical content from Fedora Working groups (Product Requirement Docs, deliverables, processes).<br />
* Responsible for what software is offered to end users under what conditions.<br />
* Oversight and approval of new spins and other media that doesn't fit under a working group.<br />
<br />
FESCo has empowered the FPC (Fedora Packaging Comittee) to handle management of packaging guidelines, so those items are usually deferred to them with occasional FESCo oversight.<br />
<br />
Candidates for FESCo should be people who have a wide breadth of knowledge about the Fedora Project as a whole and who understand how the many different pieces fit together. Ideal candidates should also have a history of fostering inter-team coordination.<br />
<br />
FESCo has a designate for each Working Group that coordinates with that Group and communicates back to FESCo any issues or concerns. Currently there are: Workstation, Server and Atomic Working groups. <br />
<br />
== Members ==<br />
<br />
* [[User:Kevin| Kevin Fenzi]] (nirik) - F26/F27<br />
* [[User:bowlofegss| Randy Barlow]] (bowlofeggs) - F27/F28<br />
* [[User:Maxamillion|Adam Miller]] (maxamillion) - F26/F27<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore) - F27/F28<br />
* [[User:Jsmith|Jared Smith]] (jsmith) - F26/F27<br />
* [[User:Jforbes|Justin Forbes]] (jforbes) - F26/F27<br />
* [[User:Kalev|Kalev Lember]] (kalev) - F26/F27<br />
* [[User:Till| Till Mass]] (till) - F27/F28<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh) - F27/F28<br />
<br />
Chair is rotating.<br />
<br />
You can find their mission statements (issued during the last FESCo-election) [https://fedoraproject.org/w/index.php?title=Development/SteeringCommittee/Nominations&oldid=290360| here] . Members of previous FESCos can be found [[Extras/SteeringCommitteeHistory| here]] .<br />
<br />
== Agenda ==<br />
<br />
{{Admon/tip | You can find FESCO's weekly agenda in the [https://pagure.io/fesco FESCo Ticketing System] with [https://pagure.io/fesco/report/meeting_agenda this report.]}}<br />
<br />
Generally, issues are voted on in FESCo. A majority of the committee (that is, 5 of 9) is required to pass a proposal. Votes can be accepted in the agenda tickets as well as the meeting, however, if less than 5 members are able to attend a meeting, the meeting is cancelled.<br />
<br />
== Meetings ==<br />
<br />
FESCo meets usually each Friday at 16:00 UTC or 15:00 UTC (when daylight saving time applies) on the Freenode IRC Network (<code>irc.freenode.net</code>) in #fedora-meeting. You should verify the meeting date and time from the [https://admin.fedoraproject.org/mailman/listinfo/devel devel] mail "''Plan for tomorrow's FESCo meeting''" being sent in advance.<br />
<br />
FESCo meeting discussions will last for 15 minutes. At the end of the 15 minute discussion one of the following actions may be taken:<br />
<br />
* If there is a vote to continue, then discussion continues for an additional 15 minutes.<br />
<br />
* If there is no vote to continue the discussion after the initial 15 minutes, ask those members who are discussing the issue to clearly write up their thoughts and position on a wiki page for consideration at the next meeting. Each view point can list their thoughts as a separate proposal, or work off-line with others, to come up with a single proposal acceptable to them all. The wiki page is used in the next meeting to guide discussions and voting.<br />
<br />
All requests for consideration by the steering committee (including group sponsorship requests and maintainer-ship issues) should be submitted as a ticket:<br />
* [https://pagure.io/fesco FESCo Ticketing System]<br />
* [https://pagure.io/fesco/new_issue Enter New FESCo Ticket]<br />
<br />
== Meeting Minutes ==<br />
<br />
You can find FESCO's meeting minutes at [http://meetbot.fedoraproject.org/sresults/?group_id=fesco&type=team the fedora meetbot site] as well as posted to the devel@lists.fedoraproject.org list after each meeting. Note that meetings prior to the 2010-10-20 meeting were on Tuesdays.<br />
<br />
== Mailing List ==<br />
<br />
FESCo has a private mailing list for sensitive matters. This list will have as subscribers only the current FESCo members and the Fedora Project Leader. <br />
This list should only be used in very rare situations with private information. The FESCo chair will make sure any discussion on this list that doesn't need to be private will be resent to a public forum (FESCo trac, devel list, etc). <br />
<br />
[[Category:FESCo]] [[Category:FESCo policy]]<br />
[[Category:Fedora_leadership]]</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Architectures/PowerPC&diff=481926Architectures/PowerPC2016-12-08T14:39:55Z<p>Jwboyer: /* Supported Architectures */</p>
<hr />
<div>{{shortcut|Arch:PPC}}<br />
<br />
{| style="width: 50%; float: right; margin-left: 2em;"<br />
|-<br />
| style="border-width: 0;" | {{admon/tip | Getting Started with Fedora for Power::|<br />
<br />
Check out our [[Architectures/PowerPC/CurrentDevelopment|current development efforts]] and join the Fedora for Power team on IRC in {{fpchat|#fedora-ppc}} on http://freenode.net<br />
}}<br />
|}<br />
<br />
= PowerPC/POWER Special Interest Group =<br />
* IRC: {{fpchat|#fedora-ppc}} on irc.freenode.net<br />
* Mailing List: {{fplist|ppc}}<br />
<br />
== Members ==<br />
* [[User:sharkcz| Dan Horák]] (IBM IntelliStation 275)<br />
* [[User:than| Than Ngo]]<br />
* Mark Hamzy<br />
* Mike Wolf<br />
* [[User:Gustavold| Gustavo Luiz Duarte]]<br />
* [[User:menantea| Guy Menanteau]]<br />
* [[User:sinnykumari| Sinny Kumari]]<br />
<br />
== Stable Release, GPG keys == <br />
<br />
Fedora 25 is the latest stable release of Fedora for Power. It was announced on November 22, 2016. Please see [https://lists.fedoraproject.org/archives/list/announce@lists.fedoraproject.org/thread/FG5BBVWKJBRZUDGN7RXPFVLHLWELWF3P/ the release announcement] for additional details or download it directly from [https://alt.fedoraproject.org/alt/ here].<br />
<br />
Fedora for Power uses different GPG keys than the primary architectures. Check [https://fedoraproject.org/keys The official Fedora GPG key list] for a list of secondary arch keys.<br />
<br />
=== Release Notes ===<br />
<br />
* [[Architectures/PowerPC/26|Fedora 26]]<br />
* [[Architectures/PowerPC/25|Fedora 25]]<br />
* [[Architectures/PowerPC/24|Fedora 24]]<br />
<br />
== Supported Architectures ==<br />
<br />
Only 64bit machines (big endian Power5 or newer and little endian Power8 or newer) are supported, 32bit packages are not available anymore in F22 or newer. The last Fedora release with 32bit boot images was Fedora 17. Although it might be possible to install a 32bit F17 release and then update with the latest F21 packages, this is not supported by the Fedora PPC developers anymore. <br />
<br />
Fedora 18 through Fedora 23 also includes several optimized packages for Power7 machines. These will be installed automatically if a Power7 processor is detected. The focus for Fedora 24 and newer is on Power8 or newer hardware and the optimizations for these CPU types are handled through a different mechanism.<br />
<br />
== Previous Releases ==<br />
<br />
You can find information about previous Fedora for Power releases at [[Architectures/PowerPC/PreviousReleases]]. <br />
<br />
== Build System & Resources ==<br />
<br />
===Koji=== <br />
<br />
====F25 or previous releases====<br />
Till F25, all official Fedora PowerPC packages are built by the koji build system at the<br />
[http://ppc.koji.fedoraproject.org/koji PowerPC koji hub]<br />
Everyone with a [[Join_the_package_collection_maintainers#Get_a_Fedora_Account|Fedora account]] can do scratch builds of packages on the PowerPC koji build system. After running fedora-packager-setup from the fedora-packager rpm<br />
ppc-koji build --scratch f20 yourpkg.src.rpm<br />
<br />
Scratch builds can be found [http://ppc.koji.fedoraproject.org/scratch/ here], and will be removed from koji automatically after a while.<br />
<br />
For a build to end up in the final Fedora for Power distribution, that NVR must have been built on the primary Fedora koji and then pushed as an update for that release. koji-shadow is used by Fedora for Power to track both the stable (e.g. 'f20' during f20 branched development and 'f20-updates' after GA) and updates-testing tags of each release, as well as the current rawhide tag. Please feel free to find [[User:sharkcz| Dan Horák]] on the #fedora-ppc IRC channel if you have questions about the koji-shadow process.<br />
<br />
====Rawhide====<br />
On October 29, 2016 announcement was made to [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SBQOANIUYRRRJGK3BNN5WOYERMEVTD5V/ merge ppc64(le)] koji builds of packages with [http://koji.fedoraproject.org/koji/ primary koji].<br />
<br />
To make a scratch build of package for ppc64 and ppc64le in Fedora rawhide, run:<br />
koji build --scratch --arch-override=ppc64,ppc64le rawhide yourpkg.src.rpm<br />
<br />
=== PPC Shell access for debugging ===<br />
[[user:sharkcz|Dan Horák ]] ([[fas:sharkcz|sharkcz]]) can provide you access to a PPC box for build debugging purposes. Just send him an e-mail with a request and a public SSH key.<br />
fedora-infra team is also working on providing easier access to a PowerPC VM for debugging build issues. Once we have it ready, we will update this section.<br />
<br />
== Bugzilla ==<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&rep_platform=powerpc&rep_platform=ppc64&rep_platform=ppc&bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&product=Fedora&classification=Fedora List of currently open PowerPC bugs]<br />
* [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179260 ExcludeArch for PowerPC]<br />
* [[Architectures/BuildIssues|Power & s390x build issues]] <br />
<br />
<br />
== Links ==<br />
* [http://lists.fedoraproject.org/pipermail/ppc fedora-ppc mailing list] <BR><br />
* [[Architectures/PowerPC/PPC-hub-serverstatus|Special files and configuration on the PPC hub]]<br />
* [http://www.ibm.com/systems/power/ Power homepage] <BR><br />
* [https://www.ibm.com/developerworks/community/wikis/home/wiki/W51a7ffcf4dfd_4b40_9d82_446ebc23c550?lang=en The PowerLinux Community Wiki] <BR><br />
* [http://www.power.org/ Power.org] <BR><br />
* [http://www.powerdeveloper.org/ powerdeveloper.org]<br />
* [http://pic.dhe.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaae/lcon_Installing_Linux_on_System_p5.htm Installation docs] for IBM Power hardware <BR><br />
<br />
<br />
[[Category:Arch-specific SIGs]][[Category:SIGs]]<br />
[[Category:Fedora special-interest groups|PowerPC]]</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Architectures/PowerPC&diff=481685Architectures/PowerPC2016-12-07T12:56:26Z<p>Jwboyer: /* Members */</p>
<hr />
<div>{{shortcut|Arch:PPC}}<br />
<br />
{| style="width: 50%; float: right; margin-left: 2em;"<br />
|-<br />
| style="border-width: 0;" | {{admon/tip | Getting Started with Fedora for Power::|<br />
<br />
Check out our [[Architectures/PowerPC/CurrentDevelopment|current development efforts]] and join the Fedora for Power team on IRC in {{fpchat|#fedora-ppc}} on http://freenode.net<br />
}}<br />
|}<br />
<br />
= PowerPC/POWER Special Interest Group =<br />
* IRC: {{fpchat|#fedora-ppc}} on irc.freenode.net<br />
* Mailing List: {{fplist|ppc}}<br />
<br />
== Members ==<br />
* [[User:sharkcz| Dan Horák]] (IBM IntelliStation 275)<br />
* [[User:than| Than Ngo]]<br />
* Mark Hamzy<br />
* Mike Wolf<br />
* [[User:Gustavold| Gustavo Luiz Duarte]]<br />
* [[User:menantea| Guy Menanteau]]<br />
* [[User:sinnykumari| Sinny Kumari]]<br />
<br />
== Stable Release, GPG keys == <br />
<br />
Fedora 25 is the latest stable release of Fedora for Power. It was announced on November 22, 2016. Please see [https://lists.fedoraproject.org/archives/list/announce@lists.fedoraproject.org/thread/FG5BBVWKJBRZUDGN7RXPFVLHLWELWF3P/ the release announcement] for additional details or download it directly from [https://alt.fedoraproject.org/alt/ here].<br />
<br />
Fedora for Power uses different GPG keys than the primary architectures. Check [https://fedoraproject.org/keys The official Fedora GPG key list] for a list of secondary arch keys.<br />
<br />
=== Release Notes ===<br />
<br />
* [[Architectures/PowerPC/26|Fedora 26]]<br />
* [[Architectures/PowerPC/25|Fedora 25]]<br />
* [[Architectures/PowerPC/24|Fedora 24]]<br />
<br />
== Supported Architectures ==<br />
<br />
Only 64bit machines (big endian Power5 or newer and little endian Power8 or newer) are supported, 32bit packages are not available anymore in F22 or newer. The last Fedora release with 32bit boot images was Fedora 17. Although it might be possible to install a 32bit F17 release and then update with the latest F21 packages, this is not supported by the Fedora PPC developers anymore. <br />
<br />
Fedora 18 and newer also includes several optimized packages for Power7 machines. These will be installed automatically if a Power7 processor is detected.<br />
<br />
== Previous Releases ==<br />
<br />
You can find information about previous Fedora for Power releases at [[Architectures/PowerPC/PreviousReleases]]. <br />
<br />
== Build System & Resources ==<br />
<br />
===Koji=== <br />
<br />
====F25 or previous releases====<br />
Till F25, all official Fedora PowerPC packages are built by the koji build system at the<br />
[http://ppc.koji.fedoraproject.org/koji PowerPC koji hub]<br />
Everyone with a [[Join_the_package_collection_maintainers#Get_a_Fedora_Account|Fedora account]] can do scratch builds of packages on the PowerPC koji build system. After running fedora-packager-setup from the fedora-packager rpm<br />
ppc-koji build --scratch f20 yourpkg.src.rpm<br />
<br />
Scratch builds can be found [http://ppc.koji.fedoraproject.org/scratch/ here], and will be removed from koji automatically after a while.<br />
<br />
For a build to end up in the final Fedora for Power distribution, that NVR must have been built on the primary Fedora koji and then pushed as an update for that release. koji-shadow is used by Fedora for Power to track both the stable (e.g. 'f20' during f20 branched development and 'f20-updates' after GA) and updates-testing tags of each release, as well as the current rawhide tag. Please feel free to find [[User:sharkcz| Dan Horák]] on the #fedora-ppc IRC channel if you have questions about the koji-shadow process.<br />
<br />
====Rawhide====<br />
On October 29, 2016 announcement was made to [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SBQOANIUYRRRJGK3BNN5WOYERMEVTD5V/ merge ppc64(le)] koji builds of packages with [http://koji.fedoraproject.org/koji/ primary koji].<br />
<br />
To make a scratch build of package for ppc64 and ppc64le in Fedora rawhide, run:<br />
koji build --scratch --arch-override=ppc64,ppc64le rawhide yourpkg.src.rpm<br />
<br />
=== PPC Shell access for debugging ===<br />
[[user:sharkcz|Dan Horák ]] ([[fas:sharkcz|sharkcz]]) can provide you access to a PPC box for build debugging purposes. Just send him an e-mail with a request and a public SSH key.<br />
fedora-infra team is also working on providing easier access to a PowerPC VM for debugging build issues. Once we have it ready, we will update this section.<br />
<br />
== Bugzilla ==<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&rep_platform=powerpc&rep_platform=ppc64&rep_platform=ppc&bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&product=Fedora&classification=Fedora List of currently open PowerPC bugs]<br />
* [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179260 ExcludeArch for PowerPC]<br />
* [[Architectures/BuildIssues|Power & s390x build issues]] <br />
<br />
<br />
== Links ==<br />
* [http://lists.fedoraproject.org/pipermail/ppc fedora-ppc mailing list] <BR><br />
* [[Architectures/PowerPC/PPC-hub-serverstatus|Special files and configuration on the PPC hub]]<br />
* [http://www.ibm.com/systems/power/ Power homepage] <BR><br />
* [https://www.ibm.com/developerworks/community/wikis/home/wiki/W51a7ffcf4dfd_4b40_9d82_446ebc23c550?lang=en The PowerLinux Community Wiki] <BR><br />
* [http://www.power.org/ Power.org] <BR><br />
* [http://www.powerdeveloper.org/ powerdeveloper.org]<br />
* [http://pic.dhe.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaae/lcon_Installing_Linux_on_System_p5.htm Installation docs] for IBM Power hardware <BR><br />
<br />
<br />
[[Category:Arch-specific SIGs]][[Category:SIGs]]<br />
[[Category:Fedora special-interest groups|PowerPC]]</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Development/SteeringCommittee/Nominations&diff=461575Development/SteeringCommittee/Nominations2016-07-05T12:08:04Z<p>Jwboyer: /* Candidate Nominations */</p>
<hr />
<div><!--{{admon/important|The nomination period has not yet begun. Please wait for the elections announcement.}}--><br />
{{admon/important|We're OPEN!|The nomination period is in progress! Please add your nomination before 23:59:59 UTC on July 11th, 2016! }}<br />
<!--{{admon/tip | VOTE FOR YOUR FAVORITE CANDIDATES. | Fedora contributors can elect FESCo at https://admin.fedoraproject.org/voting/about/fesco-december2012.--><br />
<!--{{admon/important|The nomination period has not yet begun. Please wait for the elections announcement.}}--><br />
<!--<br />DEADLINE: Dec. 9, 23:59:59 UTC}}--><br />
<br />
The following [[Elections|elections]] will take place in July 2016:<br />
<br />
* [[Development/SteeringCommittee/Nominations|FESCo (Engineering)]] (four seats)<br />
<br />
More information about FESCo on [[Fedora_Engineering_Steering_Committee|FESCo wiki page]].<br />
<br />
See [https://fedorapeople.org/groups/schedule/f-24/f-24-elections.html Election Schedule] page for more details regarding the Elections timeline.<br />
All dates and times noted are UTC time.<br />
<br />
= FESCo Elections July 2016 =<br />
As per the [[FESCo_election_policy|FESCo election policy]], the following FESCo members finish their terms, and the seats are up for re-election:<br />
<br />
* [[User:jwboyer| Josh Boyer]] (jwb) - elected for F23/F24 period<br />
* [[User:ausil| Dennis Gilmore]] (dgilmore) - elected for F23/F24 period<br />
* [[User:hguemar| Haïkel Guémar]] (hguemar) - elected for F23/F24 period<br />
* [[User:sgallagh| Stephen Gallagher]] (sgallagh) - elected for F23/F24 period<br />
<br />
<!--{{admon/important|The nomination period is CLOSED. The nomination period ended at 23:59:59 UTC on May 15, 2012.}}--><br />
For the last election, see [https://fedoraproject.org/w/index.php?title=Development/SteeringCommittee/Nominations&oldid=428892 Nominations Nov/Dec 2015]<br />
<br />
{{admon/note|Eligible Voters|Voting eligibility is determined by a community member's Fedora Account System ([https://admin.fedoraproject.org/accounts/ FAS]) memberships.<br/>To vote for [[Fedora_Engineering_Steering_Committee|FESCo]] you must have cla_done + one other "non-cla" group in FAS.}}<br />
<br />
== Candidate Nominations ==<br />
Please nominate just by Name, IRC nick and FAS account ID. A set of questions for candidates is being prepared, and the resulting introductions will be published in [https://communityblog.fedoraproject.org/ Community Blog] , at the end of the "Campaign" period.<br />
<br />
* NAME (IRC nick/FAS account ID)<br />
<br />
* Josh Boyer (jwb/jwboyer)<br />
<br />
You may self-nominate. If you wish to nominate someone else, please consult with that person ahead of time.<br />
<br />
[[Category:FESCo]]</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/FY17_Goals&diff=446807Kernel/FY17 Goals2016-05-17T19:16:21Z<p>Jwboyer: /* Goals */</p>
<hr />
<div>=== Team High Level Goals ===<br />
<br />
* Plan for and deliver high quality kernel for upcoming Fedora releases<br />
<br />
* Improve team efficiency and community collaboration<br />
<br />
* Increase participation in upstream kernel community<br />
<br />
=== Goals ===<br />
<br />
Specific action items will be derived from these goals.<br />
<br />
{|<br />
! Description !! Category !! Lead Person !! Target<br />
|-<br />
| '''Increase upstream kernel reviews and bugfixes.''' Upstream is continually looking for additional patch reviews. By increasing our participation there we can help avoid bugs. We'll also use this to increase our team's overall knowledge by gaining a deeper understanding of various focus areas within the kernel. || Upstream || ||<br />
|-<br />
| '''Publish various communications about the Fedora kernel.''' The kernel is often a hot topic in various communities. We'll look at continuing the upstream Fedora patch reports, and possibly writing articles for Fedora Magazine. || Collaboration || ||<br />
|-<br />
| '''Community Outreach''' The Fedora kernel community has several active members but could always improve. Through efforts like Outreachy, we can grow the understanding and expertise of interested community members. || Outreach || || <br />
|-<br />
| '''Improved popular platform support''' People like to use their hardware with a minimum amount of fuss. Look into ways to accomplish this for popular hardware. || Hardware enablement || ||<br />
|-<br />
| '''Architecture support''' The primary Fedora platform is x86_64. However, there are always interesting things happening on other architectures such as armv7hl, arm64, etc. We'll investigate possible areas where we as a team can help further progress or provide solutions with these architectures. || Architecture || ||<br />
|}<br />
<br />
==== Work Items ====<br />
{|<br />
! Description !! Lead Person !! Target<br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| Upstream patch reviews and bugfixes || All || FY<br />
|-<br />
| Blog/magazine postings on kernel topics || All || FY<br />
|-<br />
| Release maintenance || All || FY<br />
|-<br />
|}<br />
<br />
----<br />
<br />
Problems</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/FY17_Goals&diff=446806Kernel/FY17 Goals2016-05-17T19:13:48Z<p>Jwboyer: /* Goals */</p>
<hr />
<div>=== Team High Level Goals ===<br />
<br />
* Plan for and deliver high quality kernel for upcoming Fedora releases<br />
<br />
* Improve team efficiency and community collaboration<br />
<br />
* Increase participation in upstream kernel community<br />
<br />
=== Goals ===<br />
<br />
Specific action items will be derived from these goals.<br />
<br />
{|<br />
! Description !! Category !! Lead Person !! Target<br />
|-<br />
| '''Increase upstream kernel reviews and bugfixes.''' Upstream is continually looking for additional patch reviews. By increasing our participation there we can help avoid bugs. We'll also use this to increase our team's overall knowledge by gaining a deeper understanding of various focus areas within the kernel. || Upstream || ||<br />
|-<br />
| '''Publish various communications about the Fedora kernel.''' The kernel is often a hot topic in various communities. We'll look at continuing the upstream Fedora patch reports, and possibly writing articles for Fedora Magazine. || Collaboration || ||<br />
|-<br />
| '''Community Outreach''' The Fedora kernel community has several active members but could always improve. Through efforts like Outreachy, we can grow the understanding and expertise of interested community members. || XXXX || || <br />
|-<br />
| '''Improved popular platform support''' People like to use their hardware with a minimum amount of fuss. Look into ways to accomplish this for popular hardware. || XXXX || ||<br />
|-<br />
| '''Architecture support''' The primary Fedora platform is x86_64. However, there are always interesting things happening on other architectures such as armv7hl, arm64, etc. We'll investigate possible areas where we as a team can help further progress or provide solutions with these architectures. || XXXX || ||<br />
|}<br />
<br />
==== Work Items ====<br />
{|<br />
! Description !! Lead Person !! Target<br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| Upstream patch reviews and bugfixes || All || FY<br />
|-<br />
| Blog/magazine postings on kernel topics || All || FY<br />
|-<br />
| Release maintenance || All || FY<br />
|-<br />
|}<br />
<br />
----<br />
<br />
Problems</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/FY17_Goals&diff=446803Kernel/FY17 Goals2016-05-17T18:58:02Z<p>Jwboyer: /* Goals */</p>
<hr />
<div>=== Team High Level Goals ===<br />
<br />
* Plan for and deliver high quality kernel for upcoming Fedora releases<br />
<br />
* Improve team efficiency and community collaboration<br />
<br />
* Increase participation in upstream kernel community<br />
<br />
=== Goals ===<br />
<br />
Specific action items will be derived from these goals.<br />
<br />
{|<br />
! Description !! Category !! Lead Person !! Target<br />
|-<br />
| '''Increase upstream kernel reviews and bugfixes.''' Upstream is continually looking for additional patch reviews. By increasing our participation there we can help avoid bugs. We'll also use this to increase our team's overall knowledge by gaining a deeper understanding of various focus areas within the kernel. || Upstream || ||<br />
|-<br />
| '''Publish various communications about the Fedora kernel.''' The kernel is often a hot topic in various communities. We'll look at continuing the upstream Fedora patch reports, and possibly writing articles for Fedora Magazine. || Collaboration || ||<br />
|-<br />
| '''Community Outreach''' The Fedora kernel community has several active members but could always improve. Through efforts like Outreachy, we can grow the understanding and expertise of interested community members. || XXXX || || <br />
|-<br />
| '''Improved popular platform support''' People like to use their hardware with a minimum amount of fuss. Look into ways to accomplish this for popular hardware. || XXXX || ||<br />
|-<br />
| '''Thing 3''' Description || XXXX || ||<br />
|}<br />
<br />
==== Work Items ====<br />
{|<br />
! Description !! Lead Person !! Target<br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| Upstream patch reviews and bugfixes || All || FY<br />
|-<br />
| Blog/magazine postings on kernel topics || All || FY<br />
|-<br />
| Release maintenance || All || FY<br />
|-<br />
|}<br />
<br />
----<br />
<br />
Problems</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/FY17_Goals&diff=446735Kernel/FY17 Goals2016-05-17T12:29:28Z<p>Jwboyer: </p>
<hr />
<div>=== Team High Level Goals ===<br />
<br />
* Plan for and deliver high quality kernel for upcoming Fedora releases<br />
<br />
* Improve team efficiency and community collaboration<br />
<br />
* Increase participation in upstream kernel community<br />
<br />
=== Goals ===<br />
<br />
Specific action items will be derived from these goals.<br />
<br />
{|<br />
! Description !! Category !! Lead Person !! Target<br />
|-<br />
| '''Increase upstream kernel reviews and bugfixes.''' Upstream is continually looking for additional patch reviews. By increasing our participation there we can help avoid bugs. We'll also use this to increase our team's overall knowledge by gaining a deeper understanding of various focus areas within the kernel. || Upstream || ||<br />
|-<br />
| '''Publish various communications about the Fedora kernel.''' The kernel is often a hot topic in various communities. We'll look at continuing the upstream Fedora patch reports, and possibly writing articles for Fedora Magazine. || Collaboration || ||<br />
|-<br />
| '''Thing 1''' Description || XXXX || || <br />
|-<br />
| '''Thing 2''' Description || XXXX || ||<br />
|-<br />
| '''Thing 3''' Description || XXXX || ||<br />
|}<br />
<br />
==== Work Items ====<br />
{|<br />
! Description !! Lead Person !! Target<br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| Upstream patch reviews and bugfixes || All || FY<br />
|-<br />
| Blog/magazine postings on kernel topics || All || FY<br />
|-<br />
| Release maintenance || All || FY<br />
|-<br />
|}<br />
<br />
----<br />
<br />
Problems</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/FY17_Goals&diff=446734Kernel/FY17 Goals2016-05-17T12:27:36Z<p>Jwboyer: Created page with "Overall department goals * Modernizing release process and deliverables * Create and improve systems, resources, and upstream efforts that benefit general users, and help dra..."</p>
<hr />
<div>Overall department goals<br />
<br />
* Modernizing release process and deliverables<br />
* Create and improve systems, resources, and upstream efforts that benefit general users, and help draw power users into contribution<br />
* Improve/maintain systems/resources for existing contributors<br />
<br />
=== Team High Level Goals ===<br />
<br />
* Plan for and deliver high quality kernel for upcoming Fedora releases<br />
<br />
* Improve team efficiency and community collaboration<br />
<br />
* Increase participation in upstream kernel community<br />
<br />
=== Goals ===<br />
<br />
Specific action items will be derived from these goals.<br />
<br />
{|<br />
! Description !! Category !! Lead Person !! Target<br />
|-<br />
| '''Increase upstream kernel reviews and bugfixes.''' Upstream is continually looking for additional patch reviews. By increasing our participation there we can help avoid bugs. We'll also use this to increase our team's overall knowledge by gaining a deeper understanding of various focus areas within the kernel. || Upstream || ||<br />
|-<br />
| '''Publish various communications about the Fedora kernel.''' The kernel is often a hot topic in various communities. We'll look at continuing the upstream Fedora patch reports, and possibly writing articles for Fedora Magazine. || Collaboration || ||<br />
|-<br />
| '''Thing 1''' Description || XXXX || || <br />
|-<br />
| '''Thing 2''' Description || XXXX || ||<br />
|-<br />
| '''Thing 3''' Description || XXXX || ||<br />
|}<br />
<br />
==== Work Items ====<br />
{|<br />
! Description !! Lead Person !! Target<br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| || || <br />
|-<br />
| Upstream patch reviews and bugfixes || All || FY<br />
|-<br />
| Blog/magazine postings on kernel topics || All || FY<br />
|-<br />
| Release maintenance || All || FY<br />
|-<br />
|}<br />
<br />
----<br />
<br />
Problems</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Modularity_Working_Group/Initial_Nominations&diff=439943Modularity Working Group/Initial Nominations2016-03-22T16:12:10Z<p>Jwboyer: /* Working Group Self-Nominations */</p>
<hr />
<div>= Working Group Self-Nominations =<br />
<br />
{{admon/warning|Nomination period|Nominations will close on <b>April 18, 2016 00:00 UTC</b>. If you want to self-nominate, please have your name entered below before that time.}}<br />
<br />
To volunteer to serve on the Fedora Modularity Working Group, simply add yourself below, along with a brief description of your current involvement with Fedora and plans for participation in this group. Note that this will be a highly technical working group. We're looking particularly (but not exclusively) for representation from the previous Environments & Stacks and Base WGs, Release Engineering, Infrastructure, Quality Assurance, and the Security Team.<br />
<br />
See the [http://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/4K345EJD2HQ4U2XNE4UKHOOAVZ6HAHUU/ the devel-list annoucement] and [[Objectives/Fedora Modularization, Prototype Phase]] for background on what this is all about.<br />
<br />
----<br />
<br />
* [[User:langdon|Langdon White]] - Fedora Council member, Modularity Objective Lead, application developer, architect, manager, etc. I want to make Fedora more welcoming and usable by separating the lifecycles of applications from the OS.<br />
* [[User:mikedep333|Mike DePaulo]] - Packager & ambassador. SysAdmin by day. I like having the freedom to install any version of any application I want. That may not be 100% achievable, but I am passionate about working towards that goal.<br />
* [[User:cydrobolt|Chaoyi Zha]] - Developer on Infrastructure team, packager, ambassador. I want to help make Fedora more welcoming and customizable for a wider range of users.<br />
* [[User:ncoghlan|Nick Coghlan]] - Fedora Environments & Stacks member, CPython core developer involved in Python packaging initiatives. I want to help improve the Python upstream -> Fedora downstream redistribution pipeline.<br />
* [[User:harald|Harald Hoyer]] - Former Base Working Group member -> Helping out to form the Base module with the knowledge gained in the Base WG.<br />
* [[User:psabata|Petr Šabata]] -- Packager, packaging sponsor, Perl hacker. I want to participate in defining the, hopefully successful, future of Fedora and make sure it all makes sense.<br />
* [[User:adelton|Jan Pazdziora]] -- maintainer of FreeIPA server in Docker container and external authentication modules for Apache HTTP server. My goal is to have the modular approach powerful enough to support fairly complex applications like FreeIPA, and flexible enough to combine the solutions both for development and production, focusing on authentication and authorization.<br />
* [[User: lkocman|Luboš Kocman]] - Releng, code contributor to upstream rel-eng tools: mainly pungi, productmd. I'd like to bend rel-eng tools to scale with modularity (mainly split one big process of composing into independent/reusable actions).<br />
<br />
* [[User:fas-username|real-name]] - &lt; some remarks about your background /&gt;. &lt; why modularity is interesting for you or what you hope to accomplish /&gt;.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Modularity_Working_Group/Initial_Nominations&diff=439462Modularity Working Group/Initial Nominations2016-03-18T20:45:18Z<p>Jwboyer: /* Working Group Self-Nominations */</p>
<hr />
<div>= Working Group Self-Nominations =<br />
<br />
{{admon/warning|Nomination period|Nominations will close on <b>April 18, 2016 00:00 UTC</b>. If you want to self-nominate, please have your name entered below before that time.}}<br />
<br />
To volunteer to serve on the Fedora Modularity Working Group, simply add yourself below, along with a brief description of your current involvement with Fedora and plans for participation in this group. Note that this will be a highly technical working group. We're looking particularly (but not exclusively) for representation from the previous Environments & Stacks and Base WGs, Release Engineering, Infrastructure, Quality Assurance, and the Security Team.<br />
<br />
See the NOT YET POSTED post for background on what this is all about.<br />
<br />
----<br />
<br />
* [[User:langdon|Langdon]] - Fedora Council member, Modularity Objective Lead, application developer, architect, manager, etc. I want to make Fedora more welcoming and usable by separating the lifecycles of applications from the OS.<br />
* [[User:jwboyer|Josh Boyer]] - Fedora Council and FESCo member, general Fedora nosy person. I want to make sure Langdon doesn't break Fedora completely. More seriously, I want to make sure modularity is usable and useful outside of just composing the OS itself.<br />
* [[User:fas-username|real-name]] - &lt; some remarks about your background /&gt;. &lt; why modularity is interesting for you or what you hope to accomplish /&gt;.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=KernelBugTriage&diff=439451KernelBugTriage2016-03-18T16:47:02Z<p>Jwboyer: /* Quick links to bug lists */</p>
<hr />
<div>== Quick links to bug lists ==<br />
If you are looking for bugs to triage, start here:<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=VERIFIED&classification=Fedora&component=kernel&f1=flagtypes.name&keywords=Triaged%2C%20&keywords_type=nowords&list_id=1745711&o1=notsubstring&product=Fedora&query_format=advanced&v1=needinfo&version=22 Untriaged Fedora 22 Kernel Bugs]<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=VERIFIED&classification=Fedora&component=kernel&f1=flagtypes.name&keywords=Triaged%2C%20&keywords_type=nowords&list_id=1745711&o1=notsubstring&product=Fedora&query_format=advanced&v1=needinfo&version=23 Untriaged Fedora 23 Kernel Bugs]<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=VERIFIED&classification=Fedora&component=kernel&f1=flagtypes.name&keywords=Triaged%2C%20&keywords_type=nowords&list_id=1745711&o1=notsubstring&product=Fedora&query_format=advanced&v1=needinfo&version=24 Untriaged Fedora 24 Kernel Bugs]<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=VERIFIED&classification=Fedora&component=kernel&f1=flagtypes.name&keywords=Triaged%2C%20&keywords_type=nowords&list_id=1745711&o1=notsubstring&product=Fedora&query_format=advanced&v1=needinfo&version=rawhide Untriaged Rawhide Kernel Bugs]<br />
<br />
Full Bug Lists:<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&classification=Fedora&component=kernel&product=Fedora&query_format=advanced&version=22&order=bug_id%20DESC&query_based_on= Fedora 22 Kernel Bugs] <br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&classification=Fedora&component=kernel&product=Fedora&query_format=advanced&version=23&order=bug_id%20DESC&query_based_on= Fedora 23 Kernel Bugs] <br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&classification=Fedora&component=kernel&product=Fedora&query_format=advanced&version=24&order=bug_id%20DESC&query_based_on= Fedora 24 Kernel Bugs] <br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&classification=Fedora&component=kernel&product=Fedora&query_format=advanced&version=rawhide&order=bug_id%20DESC&query_based_on= Fedora rawhide Kernel Bugs]<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?keywords=Security&keywords_type=anywords&order=Bug%20Number&classification=Fedora&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&version=14&version=15&version=16&version=17&version=18&version=19&version=20&version=21&version=22&version=23&version=24&version=rawhide&component=kernel&product=Fedora Fedora Kernel Security Bugs (all versions)]<br />
<br />
* [http://bugzilla.kernel.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&kernel_version_type=allwordssubstr&kernel_version=&bug_status=NEW&bug_status=ASSIGNED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&newqueryname=&field0-0-0=noop&type0-0-0=noop&value0-0-0= Upstream Kernel Bugs]<br />
<br />
== Triage Quickstart ==<br />
<br />
So you've decided to do kernel bug triage. AWESOME! We could use the help. If you're already familiar with bugzilla and the kernel, here is a quickstart set of steps to help us triage the existing bugs. If you aren't familiar with kernel bugs, or need a refresher, the rest of the page has some good background on various aspects of kernel triage and we encourage you to read it before diving in.<br />
<br />
Steps (Start at the top, work to the bottom):<br />
<br />
* Read over the bug and come up with a basic classification (kernel panic, boot issue, RFE, missing/broken functionality, etc). Add a comment to the bug that provides this classification.<br />
* Determine which kernel subsystem or driver is involved. Prefix the bug subject with the driver/subsytem (e.g. ALSA, USB, ACPI, etc).<br />
** If it is a bug in the video subsystem, reassign it to xorg-x11-drv-{ati,intel,nouveau}. Although the modesetting drivers live in the kernel, they are maintained by the same people who maintain our userspace graphics drivers. See [[KernelBugTriage#Video_Subsystem_bugs]]<br />
** If it is in one of these categories, please add the matching email address as a "CC" on the bug: <br />
{|<br />
! Subsystem/Driver<br />
! CC<br />
|-<br />
| ACPI || fedora-kernel-acpi@fedoraproject.org<br />
|-<br />
| Audit || fedora-kernel-audit@fedoraproject.org<br />
|-<br />
| block (Issues with block/* OR drivers/block/loop.c) || fedora-kernel-block@fedoraproject.org<br />
|-<br />
| DMAR (Intel IOMMU) || fedora-kernel-dmar@fedoraproject.org<br />
|- <br />
| Ethernet (all issues) || fedora-kernel-ethernet@fedoraproject.org<br />
|-<br />
| Ethernet (atl1*, alx) || fedora-kernel-ethernet-ath@fedoraproject.org<br />
|-<br />
| Ethernet (bnx2, bnx2x, b44, tg3) || fedora-kernel-ethernet-broadcom@fedoraproject.org<br />
|-<br />
| Ethernet (r8169) || fedora-kernel-ethernet-realtek@fedoraproject.org<br />
|-<br />
| Filesystems (AIO, fs/aio.c) || fedora-kernel-aio@fedoraproject.org<br />
|-<br />
| Filesystems (BTRFS) || fedora-kernel-btrfs@fedoraproject.org<br />
|-<br />
| Filesystems (CIFS) || nfs-maint@redhat.com<br />
|-<br />
| Filesystems (DirectIO, fs/direct-io.c) || fedora-kernel-directio@fedoraproject.org<br />
|-<br />
| Filesystems (EXT2/EXT3/EXT4/JBD) || fedora-kernel-extfs@fedoraproject.org<br />
|-<br />
| Filesystems (fs/buffer.c) || fedora-kernel-fsbuffer@fedoraproject.org<br />
|-<br />
| Filesystems (NFS) || nfs-maint@redhat.com<br />
|-<br />
| Filesystems (XFS) || fedora-kernel-xfs@fedoraproject.org<br />
|-<br />
| Firewire || fedora-kernel-firewire@fedoraproject.org<br />
|-<br />
| Graphics (DRM core, but not Radeon/Intel/Nouveau drivers) || fedora-kernel-drm@fedoraproject.org<br />
|-<br />
| HID/Input/Multitouch (but not WACOM) || fedora-kernel-input@fedoraproject.org<br />
|-<br />
| intel-pstate (cpufreq driver) || fedora-kernel-intelpstate@fedoraproject.org<br />
|-<br />
| KVM virtualization || fedora-kernel-kvm@fedoraproject.org<br />
|-<br />
| LVM and device-mapper || lvm-team@redhat.com<br />
|-<br />
| Networking (NFC) || fedora-kernel-nfc@fedoraproject.org<br />
|-<br />
| Networking (TCP, UDP, SCTP, IP) || fedora-kernel-networking@fedoraproject.org<br />
|-<br />
| OpenVSwitch || fedora-kernel-openvswitch@fedoraproject.org<br />
|-<br />
| ptrace and utrace || fedora-kernel-ptrace@fedoraproject.org<br />
|-<br />
| PCI / PnP resource allocation || fedora-kernel-pci@fedoraproject.org<br />
|-<br />
| RAID (drivers/md) || fedora-kernel-raid@fedoraproject.org<br />
|-<br />
| SATA and libata || fedora-kernel-ata@fedoraproject.org<br />
|-<br />
| SCSI and libsas || fedora-kernel-scsi@fedoraproject.org<br />
|-<br />
| SELinux || fedora-kernel-selinux@fedoraproject.org<br />
|-<br />
| UEFI || fedora-kernel-uefi@fedoraproject.org<br />
|-<br />
| USB Video Cameras || fedora-kernel-usb-cameras@fedoraproject.org<br />
|-<br />
| Video4Linux || fedora-kernel-v4l@fedoraproject.org<br />
|-<br />
| Xen virtualization || fedora-kernel-xen@fedoraproject.org<br />
|-<br />
| Wireless (generic issues, or issues that do not match one of the below drivers) || fedora-kernel-wireless@fedoraproject.org<br />
|-<br />
| Wireless (ath*k) || fedora-kernel-wireless-ath@fedoraproject.org<br />
|-<br />
| Wireless (Broadcom (b43)) || fedora-kernel-wireless-b43@fedoraproject.org<br />
|-<br />
| Wireless (brcm80211) || fedora-kernel-wireless-brcm80211@fedoraproject.org<br />
|-<br />
| Wireless (Intel (iwlwifi and iwlegacy (iwl3945 and iwl4965))) || fedora-kernel-wireless-iwl@fedoraproject.org<br />
|-<br />
| Wireless (Ralink (rt2x00)) || fedora-kernel-wireless-ralink@fedoraproject.org<br />
|-<br />
| Wireless (Realtek (rtlwifi, r8712u)) || fedora-kernel-wireless-realtek@fedoraproject.org<br />
|}<br />
* If multiple categories apply, add them each to the CC list.<br />
* For oopses, add the oopsing function to the end of the bug subject. E.g. IP:hci_send_sco. For things like __list_del_entry, which are common kernel functions, try to find the latest function that was called before that and use that as the suffix.<br />
* Look for duplicate bugs across all Fedora releases. If you find a duplicate, use whichever bug has the most information as the "active" bug and duplicate the other in bugzilla. If you duplicate a bug from a newer release against one in an older release, then change the version on the active bug to the newest version the issue has been seen on.<br />
* If the bug is new, try to determine which kernel version it was first seen with. Note this in the bugzilla whiteboard with "first=X.Y.Z" (e.g. first=3.1.0). Also try to determine which kernel version is the latest tested and still having the issue. Note this in the bugzilla whiteboard with "latest=X.Y.Z" (e.g. latest=3.8.7).<br />
* If the bug is missing information, ask for it and put the bug in NEEDINFO. This can include things like dmesg, modules in use, full panic/oops backtraces, or questions as to what was occurring on the machine at the time. Information should be attached as text/plain attachments, or simple comments in the bug if the information is fairly short. In order to avoid information overload, please ask for only relevant missing information (e.g. we don't need /proc/cpuinfo for wifi bugs, etc).<br />
* If the bug looks fairly straightforward, try and see if upstream knows about it.<br />
** Look on the various mailing lists and kernel.org bugzilla to see if something similar has been reported upstream (or google search). If so, add a reference to the Fedora bug in the thread or in the kernel.org bug.<br />
** If it doesn't appear to be reported upstream, use the MAINTAINERS and scripts/get_maintainers.pl files in the kernel tree to narrow down who to report the issue to. Send them an email with all the relevant details from the bug, with kernel-team@fedoraproject.org on CC. Add a link to the mailing list thread archive of the email you sent to the Fedora bug, or use the external references field to pair it with a kernel.org bug.<br />
* Mark the bug as Triaged with the bugzilla Triaged keyword.<br />
<br />
== Kernel Bug Classification ==<br />
[[KernelBugClassification]]<br />
<br />
== Kernel Bugzilla Basics ==<br />
<br />
* If there's an upstream (http://bugzilla.kernel.org) bug that matches<br />
** In the Fedora bug, set 'external bugzilla references' to point to the upstream bug number<br />
** In the upstream kernel.org bugzilla, add a comment along the lines of "also seen in Fedora. http://bugzilla.redhat.com/show_bug.cgi?id=253096"<br />
* If the bug is against an already released Fedora (Ie, Fedora 7) and there isn't much information to go on "my machine locked up" for eg, request that the user try to reproduce the problem using the kernel-debug kernel. The additional debugging checks may trigger some clues.<br />
* If the bug you are triaging contains a patch, please add [PATCH] to the beginning of the summary line of the bugzilla.<br />
* Sometimes a user will attach a kernel panic as a jpeg, or in worst case, as a tarball of their /var/log/messages.<br />
** It saves the kernel team time if the kernel oops parts of these are transcribed/cut out and pasted into the bug as text.<br />
* Additionally, making sure that text attachments of bugs have their MIME type set to text/plain can save some time.<br />
* You can ask reporters to try and duplicate with the latest nightly live composes: http://alt.fedoraproject.org/pub/alt/nightly-composes/<br />
* You can ask reporters to try the newest kernel available in koji: http://koji.fedoraproject.org/koji/packageinfo?packageID=8<br />
* If the bug appears to be video/kernel modesetting related, reassign it to the xorg-x11-drv-{intel,ati,nouveau} component. See [[KernelBugTriage#Video_Subsystem_bugs]]<br />
* If the reporter is using a custom compiled kernel, close the bug as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=126342<br />
<br />
== Bug state transitions ==<br />
<br />
* A bug marked as MODIFIED has patches in testing and should not have their status changed. An exception to this is when a bug has been in MODIFIED state for some time (this usually indicates that the issue was fixed in an update, and no-one ever closed the bug. If in doubt, ping the reporter to retest with the latest build).<br />
* If a bug has been in NEEDINFO for several weeks with no follow-up from the reporter, there's not a great deal we can do. In this situation, closing the bug is the only recourse available (which does actually tend to 'wake up' some reporters who then reopen the bug). See [[KernelBugTriage#Stale_Bugs]] below.<br />
* When marking bugs as duplicates, we want the one with the most information to be the one that remains open, even if this means a higher numbered bug gets closed. Also, the Fedora release branches are kept on essentially the same kernel version. Therefore, if the same bug is reported in both releases then we close one of them as a duplicate of the other following the aforementioned rule. Duplicating bugs across releases is one way to control the bug count.<br />
* Don't close bugs marked beginning with [mmconf] or [msi] (bugs beginning with [$something] are usually specifically marked so developers can quickly see the main issue within the bug)<br />
<br />
== NEW state bugs ==<br />
<br />
If the bug is new and (this type of bug must be key-worded in either WHITEBOARD or BLOCKER):<br />
Hello, <br />
<br />
:''Thank you for taking the time to report this bug. I have added the proper keyword to this bug to bring it to the attention of the <subsystem-name> subsystem maintainer. <br />
<br />
:''Can you attach the following information to this bug: ''<br />
Then pick the info that is useful in this case:<br />
<br />
* dmesg output from boot before issue. <br />
* dmesg output after issue. <br />
* dmesg output from boot with 'quiet' option replaced with 'debug'<br />
* lspci output<br />
* lsusb output<br />
<br />
For other necessary information check:<br />
* X bugs see: http://fedoraproject.org/wiki/How_to_debug_Xorg_problems.<br />
* Other troubleshooting ideas: http://fedoraproject.org/wiki/Common_kernel_problems.<br />
<br />
== Bug assignment ==<br />
Assigning/cc'ing people responsible for the relevant subsystem is a good idea.<br />
<br />
When reassigning bugs to yourself, add kernel-maint@redhat.com to Cc:<br />
<br />
If you are an upstream developer, and would like to be added to the Cc: of relevant bugs, send an email to kernel-team at fedoraproject.org,<br />
(We used to maintain this here on the wiki, but for a number of reasons, we now maintain this list privately)<br />
<br />
== Possibly fixed in CURRENTRELEASE (Stick for prodding sleeping bugs with) ==<br />
<br />
If the bug is against a previous point release kernel, and the reporter hasn't re-tested (this type of bugs must be set in NEEDINFO_REPORTER state):<br />
<br />
:''Thank you for taking the time to report this bug. Updates to the kernel have been released since it was first reported. If you have time to update the package and re-test, please do so and report the results here. You can obtain the updated package by typing in Fedora 22 and later versions <code>'dnf upgrade kernel'</code> and in Fedora 21 and earlier versions <code>'yum update kernel'</code>or using the graphical updater, Software Update. If the problem no longer exists then please close this bug or it will be closed in a few weeks if there is no additional information lodged.''<br />
<br />
== Installer bugs ==<br />
If the bug refers to problems when installing Fedora in any of the possible ways CD, DVD, USB, network, etc (this type of bugs must be set in NEEDINFO_REPORTER state):<br />
<br />
:''Thank you for taking the time to report this bug. Bugs involving the installation process cannot usually be resolved after release date. We therefore ask reporters to use one (or both) of the following options:<br />
<br />
:''Test with an Alpha, Beta or Release Candidate for the next version. These can be found at http://fedoraproject.org/get-prerelease and by testing these we can work to resolve any installation issues so that the final release is free of such bugs.''<br />
<br />
:''However if the problem no longer exists then please close this bug or it will be closed in a few weeks if there is no additional information lodged.''<br />
<br />
{{admon/important|get-prerelease link|The ''get-prerelease'' link sometimes is not available or have not updated development releases.}}<br />
<br />
== Video Subsystem bugs ==<br />
<br />
The various video subsystems that have kernel modesetting support would just prefer their bugs to be moved over to the xorg-x11-drv-{intel|nouveau|ati} component. <br />
There, their triagers can gather needed info and debug the issue. If the problem is in the kernel, those maintainers can fix it, no need to leave the bug assigned to <br />
the kernel. <br />
<br />
:''This bug is in a video subsystem that has a kernel part. We track and work on these bugs via the driver package name instead of leaving them assigned to the kernel''<br />
<br />
== Rebase Regressions ==<br />
The kernel is often rebased to the latest stable kernel release and pushed as an update. This fixes a large amount of bugs, but it inevitably introduces a few regressions. If a bug is reported and it is determined that it worked with the previous kernel release, then a rebase regression entry should be added to the whiteboard field in the bug. This entry takes the form of:<br />
<br />
<pre>rebase-regression-<kernel version></pre><br />
<br />
E.g. if there is a regression when moving to the 3.1 kernel, it should be:<br />
<br />
<pre>rebase-regression-3.1</pre><br />
<br />
The latest working Fedora kernel version and the earliest broken version should be noted in the comment section if possible.<br />
<br />
This will allow the kernel developers to track regressions introduced by a rebased kernel. That will also help facilitate our communication with the upstream kernel developers, as we can report these bugs to them to be included in the regression lists that are published upstream.<br />
<br />
== Bugs with TAINTED modules ==<br />
Certain bug reports refer to a kernel module that is not open source software (mark this bugs with the keyword TAINTED):<br />
<br />
:''Thank you for taking the time to report this bug. Sadly, your report contains information about a not open-sourced module. This means you have loaded a module into your kernel that we can't debug, making it difficult to isolate the issue. Can you reproduce the issue without loading the tainted <module-name> module?.<br />
<br />
:''If you cannot duplicate the bug without the tainted module loaded it will be closed.''<br />
<br />
:''However, you can report it to the vendor of your non-free module.''<br />
<br />
== Stale Bugs ==<br />
<br />
If a bug has been in NEEDINFO with no response from the reporter for 2 weeks, close the bug out with INSUFFICIENT_DATA and the following text:<br />
<br />
:''This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.''<br />
<br />
{{Anchor|common_problems}}<br />
<br />
== Common Problems ==<br />
Point reporters to: [[KernelCommonProblems]]<br />
<br />
[[Category:Debugging]]</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=KernelBugTriage&diff=439450KernelBugTriage2016-03-18T16:46:24Z<p>Jwboyer: /* Quick links to bug lists */</p>
<hr />
<div>== Quick links to bug lists ==<br />
If you are looking for bugs to triage, start here:<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=VERIFIED&classification=Fedora&component=kernel&f1=flagtypes.name&keywords=Triaged%2C%20&keywords_type=nowords&list_id=1745711&o1=notsubstring&product=Fedora&query_format=advanced&v1=needinfo&version=22 Untriaged Fedora 22 Kernel Bugs]<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=VERIFIED&classification=Fedora&component=kernel&f1=flagtypes.name&keywords=Triaged%2C%20&keywords_type=nowords&list_id=1745711&o1=notsubstring&product=Fedora&query_format=advanced&v1=needinfo&version=23 Untriaged Fedora 23 Kernel Bugs]<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=VERIFIED&classification=Fedora&component=kernel&f1=flagtypes.name&keywords=Triaged%2C%20&keywords_type=nowords&list_id=1745711&o1=notsubstring&product=Fedora&query_format=advanced&v1=needinfo&version=24 Untriaged Fedora 24 Kernel Bugs]<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=VERIFIED&classification=Fedora&component=kernel&f1=flagtypes.name&keywords=Triaged%2C%20&keywords_type=nowords&list_id=1745711&o1=notsubstring&product=Fedora&query_format=advanced&v1=needinfo&version=rawhide Untriaged Rawhide Kernel Bugs]<br />
<br />
Full Bug Lists:<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&classification=Fedora&component=kernel&product=Fedora&query_format=advanced&version=21&order=bug_id%20DESC&query_based_on= Fedora 21 Kernel Bugs] <br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&classification=Fedora&component=kernel&product=Fedora&query_format=advanced&version=22&order=bug_id%20DESC&query_based_on= Fedora 22 Kernel Bugs] <br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&classification=Fedora&component=kernel&product=Fedora&query_format=advanced&version=23&order=bug_id%20DESC&query_based_on= Fedora 23 Kernel Bugs] <br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&classification=Fedora&component=kernel&product=Fedora&query_format=advanced&version=rawhide&order=bug_id%20DESC&query_based_on= Fedora rawhide Kernel Bugs]<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?keywords=Security&keywords_type=anywords&order=Bug%20Number&classification=Fedora&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&version=14&version=15&version=16&version=17&version=18&version=19&version=20&version=21&version=22&version=23&version=24&version=rawhide&component=kernel&product=Fedora Fedora Kernel Security Bugs (all versions)]<br />
<br />
* [http://bugzilla.kernel.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&kernel_version_type=allwordssubstr&kernel_version=&bug_status=NEW&bug_status=ASSIGNED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&newqueryname=&field0-0-0=noop&type0-0-0=noop&value0-0-0= Upstream Kernel Bugs]<br />
<br />
== Triage Quickstart ==<br />
<br />
So you've decided to do kernel bug triage. AWESOME! We could use the help. If you're already familiar with bugzilla and the kernel, here is a quickstart set of steps to help us triage the existing bugs. If you aren't familiar with kernel bugs, or need a refresher, the rest of the page has some good background on various aspects of kernel triage and we encourage you to read it before diving in.<br />
<br />
Steps (Start at the top, work to the bottom):<br />
<br />
* Read over the bug and come up with a basic classification (kernel panic, boot issue, RFE, missing/broken functionality, etc). Add a comment to the bug that provides this classification.<br />
* Determine which kernel subsystem or driver is involved. Prefix the bug subject with the driver/subsytem (e.g. ALSA, USB, ACPI, etc).<br />
** If it is a bug in the video subsystem, reassign it to xorg-x11-drv-{ati,intel,nouveau}. Although the modesetting drivers live in the kernel, they are maintained by the same people who maintain our userspace graphics drivers. See [[KernelBugTriage#Video_Subsystem_bugs]]<br />
** If it is in one of these categories, please add the matching email address as a "CC" on the bug: <br />
{|<br />
! Subsystem/Driver<br />
! CC<br />
|-<br />
| ACPI || fedora-kernel-acpi@fedoraproject.org<br />
|-<br />
| Audit || fedora-kernel-audit@fedoraproject.org<br />
|-<br />
| block (Issues with block/* OR drivers/block/loop.c) || fedora-kernel-block@fedoraproject.org<br />
|-<br />
| DMAR (Intel IOMMU) || fedora-kernel-dmar@fedoraproject.org<br />
|- <br />
| Ethernet (all issues) || fedora-kernel-ethernet@fedoraproject.org<br />
|-<br />
| Ethernet (atl1*, alx) || fedora-kernel-ethernet-ath@fedoraproject.org<br />
|-<br />
| Ethernet (bnx2, bnx2x, b44, tg3) || fedora-kernel-ethernet-broadcom@fedoraproject.org<br />
|-<br />
| Ethernet (r8169) || fedora-kernel-ethernet-realtek@fedoraproject.org<br />
|-<br />
| Filesystems (AIO, fs/aio.c) || fedora-kernel-aio@fedoraproject.org<br />
|-<br />
| Filesystems (BTRFS) || fedora-kernel-btrfs@fedoraproject.org<br />
|-<br />
| Filesystems (CIFS) || nfs-maint@redhat.com<br />
|-<br />
| Filesystems (DirectIO, fs/direct-io.c) || fedora-kernel-directio@fedoraproject.org<br />
|-<br />
| Filesystems (EXT2/EXT3/EXT4/JBD) || fedora-kernel-extfs@fedoraproject.org<br />
|-<br />
| Filesystems (fs/buffer.c) || fedora-kernel-fsbuffer@fedoraproject.org<br />
|-<br />
| Filesystems (NFS) || nfs-maint@redhat.com<br />
|-<br />
| Filesystems (XFS) || fedora-kernel-xfs@fedoraproject.org<br />
|-<br />
| Firewire || fedora-kernel-firewire@fedoraproject.org<br />
|-<br />
| Graphics (DRM core, but not Radeon/Intel/Nouveau drivers) || fedora-kernel-drm@fedoraproject.org<br />
|-<br />
| HID/Input/Multitouch (but not WACOM) || fedora-kernel-input@fedoraproject.org<br />
|-<br />
| intel-pstate (cpufreq driver) || fedora-kernel-intelpstate@fedoraproject.org<br />
|-<br />
| KVM virtualization || fedora-kernel-kvm@fedoraproject.org<br />
|-<br />
| LVM and device-mapper || lvm-team@redhat.com<br />
|-<br />
| Networking (NFC) || fedora-kernel-nfc@fedoraproject.org<br />
|-<br />
| Networking (TCP, UDP, SCTP, IP) || fedora-kernel-networking@fedoraproject.org<br />
|-<br />
| OpenVSwitch || fedora-kernel-openvswitch@fedoraproject.org<br />
|-<br />
| ptrace and utrace || fedora-kernel-ptrace@fedoraproject.org<br />
|-<br />
| PCI / PnP resource allocation || fedora-kernel-pci@fedoraproject.org<br />
|-<br />
| RAID (drivers/md) || fedora-kernel-raid@fedoraproject.org<br />
|-<br />
| SATA and libata || fedora-kernel-ata@fedoraproject.org<br />
|-<br />
| SCSI and libsas || fedora-kernel-scsi@fedoraproject.org<br />
|-<br />
| SELinux || fedora-kernel-selinux@fedoraproject.org<br />
|-<br />
| UEFI || fedora-kernel-uefi@fedoraproject.org<br />
|-<br />
| USB Video Cameras || fedora-kernel-usb-cameras@fedoraproject.org<br />
|-<br />
| Video4Linux || fedora-kernel-v4l@fedoraproject.org<br />
|-<br />
| Xen virtualization || fedora-kernel-xen@fedoraproject.org<br />
|-<br />
| Wireless (generic issues, or issues that do not match one of the below drivers) || fedora-kernel-wireless@fedoraproject.org<br />
|-<br />
| Wireless (ath*k) || fedora-kernel-wireless-ath@fedoraproject.org<br />
|-<br />
| Wireless (Broadcom (b43)) || fedora-kernel-wireless-b43@fedoraproject.org<br />
|-<br />
| Wireless (brcm80211) || fedora-kernel-wireless-brcm80211@fedoraproject.org<br />
|-<br />
| Wireless (Intel (iwlwifi and iwlegacy (iwl3945 and iwl4965))) || fedora-kernel-wireless-iwl@fedoraproject.org<br />
|-<br />
| Wireless (Ralink (rt2x00)) || fedora-kernel-wireless-ralink@fedoraproject.org<br />
|-<br />
| Wireless (Realtek (rtlwifi, r8712u)) || fedora-kernel-wireless-realtek@fedoraproject.org<br />
|}<br />
* If multiple categories apply, add them each to the CC list.<br />
* For oopses, add the oopsing function to the end of the bug subject. E.g. IP:hci_send_sco. For things like __list_del_entry, which are common kernel functions, try to find the latest function that was called before that and use that as the suffix.<br />
* Look for duplicate bugs across all Fedora releases. If you find a duplicate, use whichever bug has the most information as the "active" bug and duplicate the other in bugzilla. If you duplicate a bug from a newer release against one in an older release, then change the version on the active bug to the newest version the issue has been seen on.<br />
* If the bug is new, try to determine which kernel version it was first seen with. Note this in the bugzilla whiteboard with "first=X.Y.Z" (e.g. first=3.1.0). Also try to determine which kernel version is the latest tested and still having the issue. Note this in the bugzilla whiteboard with "latest=X.Y.Z" (e.g. latest=3.8.7).<br />
* If the bug is missing information, ask for it and put the bug in NEEDINFO. This can include things like dmesg, modules in use, full panic/oops backtraces, or questions as to what was occurring on the machine at the time. Information should be attached as text/plain attachments, or simple comments in the bug if the information is fairly short. In order to avoid information overload, please ask for only relevant missing information (e.g. we don't need /proc/cpuinfo for wifi bugs, etc).<br />
* If the bug looks fairly straightforward, try and see if upstream knows about it.<br />
** Look on the various mailing lists and kernel.org bugzilla to see if something similar has been reported upstream (or google search). If so, add a reference to the Fedora bug in the thread or in the kernel.org bug.<br />
** If it doesn't appear to be reported upstream, use the MAINTAINERS and scripts/get_maintainers.pl files in the kernel tree to narrow down who to report the issue to. Send them an email with all the relevant details from the bug, with kernel-team@fedoraproject.org on CC. Add a link to the mailing list thread archive of the email you sent to the Fedora bug, or use the external references field to pair it with a kernel.org bug.<br />
* Mark the bug as Triaged with the bugzilla Triaged keyword.<br />
<br />
== Kernel Bug Classification ==<br />
[[KernelBugClassification]]<br />
<br />
== Kernel Bugzilla Basics ==<br />
<br />
* If there's an upstream (http://bugzilla.kernel.org) bug that matches<br />
** In the Fedora bug, set 'external bugzilla references' to point to the upstream bug number<br />
** In the upstream kernel.org bugzilla, add a comment along the lines of "also seen in Fedora. http://bugzilla.redhat.com/show_bug.cgi?id=253096"<br />
* If the bug is against an already released Fedora (Ie, Fedora 7) and there isn't much information to go on "my machine locked up" for eg, request that the user try to reproduce the problem using the kernel-debug kernel. The additional debugging checks may trigger some clues.<br />
* If the bug you are triaging contains a patch, please add [PATCH] to the beginning of the summary line of the bugzilla.<br />
* Sometimes a user will attach a kernel panic as a jpeg, or in worst case, as a tarball of their /var/log/messages.<br />
** It saves the kernel team time if the kernel oops parts of these are transcribed/cut out and pasted into the bug as text.<br />
* Additionally, making sure that text attachments of bugs have their MIME type set to text/plain can save some time.<br />
* You can ask reporters to try and duplicate with the latest nightly live composes: http://alt.fedoraproject.org/pub/alt/nightly-composes/<br />
* You can ask reporters to try the newest kernel available in koji: http://koji.fedoraproject.org/koji/packageinfo?packageID=8<br />
* If the bug appears to be video/kernel modesetting related, reassign it to the xorg-x11-drv-{intel,ati,nouveau} component. See [[KernelBugTriage#Video_Subsystem_bugs]]<br />
* If the reporter is using a custom compiled kernel, close the bug as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=126342<br />
<br />
== Bug state transitions ==<br />
<br />
* A bug marked as MODIFIED has patches in testing and should not have their status changed. An exception to this is when a bug has been in MODIFIED state for some time (this usually indicates that the issue was fixed in an update, and no-one ever closed the bug. If in doubt, ping the reporter to retest with the latest build).<br />
* If a bug has been in NEEDINFO for several weeks with no follow-up from the reporter, there's not a great deal we can do. In this situation, closing the bug is the only recourse available (which does actually tend to 'wake up' some reporters who then reopen the bug). See [[KernelBugTriage#Stale_Bugs]] below.<br />
* When marking bugs as duplicates, we want the one with the most information to be the one that remains open, even if this means a higher numbered bug gets closed. Also, the Fedora release branches are kept on essentially the same kernel version. Therefore, if the same bug is reported in both releases then we close one of them as a duplicate of the other following the aforementioned rule. Duplicating bugs across releases is one way to control the bug count.<br />
* Don't close bugs marked beginning with [mmconf] or [msi] (bugs beginning with [$something] are usually specifically marked so developers can quickly see the main issue within the bug)<br />
<br />
== NEW state bugs ==<br />
<br />
If the bug is new and (this type of bug must be key-worded in either WHITEBOARD or BLOCKER):<br />
Hello, <br />
<br />
:''Thank you for taking the time to report this bug. I have added the proper keyword to this bug to bring it to the attention of the <subsystem-name> subsystem maintainer. <br />
<br />
:''Can you attach the following information to this bug: ''<br />
Then pick the info that is useful in this case:<br />
<br />
* dmesg output from boot before issue. <br />
* dmesg output after issue. <br />
* dmesg output from boot with 'quiet' option replaced with 'debug'<br />
* lspci output<br />
* lsusb output<br />
<br />
For other necessary information check:<br />
* X bugs see: http://fedoraproject.org/wiki/How_to_debug_Xorg_problems.<br />
* Other troubleshooting ideas: http://fedoraproject.org/wiki/Common_kernel_problems.<br />
<br />
== Bug assignment ==<br />
Assigning/cc'ing people responsible for the relevant subsystem is a good idea.<br />
<br />
When reassigning bugs to yourself, add kernel-maint@redhat.com to Cc:<br />
<br />
If you are an upstream developer, and would like to be added to the Cc: of relevant bugs, send an email to kernel-team at fedoraproject.org,<br />
(We used to maintain this here on the wiki, but for a number of reasons, we now maintain this list privately)<br />
<br />
== Possibly fixed in CURRENTRELEASE (Stick for prodding sleeping bugs with) ==<br />
<br />
If the bug is against a previous point release kernel, and the reporter hasn't re-tested (this type of bugs must be set in NEEDINFO_REPORTER state):<br />
<br />
:''Thank you for taking the time to report this bug. Updates to the kernel have been released since it was first reported. If you have time to update the package and re-test, please do so and report the results here. You can obtain the updated package by typing in Fedora 22 and later versions <code>'dnf upgrade kernel'</code> and in Fedora 21 and earlier versions <code>'yum update kernel'</code>or using the graphical updater, Software Update. If the problem no longer exists then please close this bug or it will be closed in a few weeks if there is no additional information lodged.''<br />
<br />
== Installer bugs ==<br />
If the bug refers to problems when installing Fedora in any of the possible ways CD, DVD, USB, network, etc (this type of bugs must be set in NEEDINFO_REPORTER state):<br />
<br />
:''Thank you for taking the time to report this bug. Bugs involving the installation process cannot usually be resolved after release date. We therefore ask reporters to use one (or both) of the following options:<br />
<br />
:''Test with an Alpha, Beta or Release Candidate for the next version. These can be found at http://fedoraproject.org/get-prerelease and by testing these we can work to resolve any installation issues so that the final release is free of such bugs.''<br />
<br />
:''However if the problem no longer exists then please close this bug or it will be closed in a few weeks if there is no additional information lodged.''<br />
<br />
{{admon/important|get-prerelease link|The ''get-prerelease'' link sometimes is not available or have not updated development releases.}}<br />
<br />
== Video Subsystem bugs ==<br />
<br />
The various video subsystems that have kernel modesetting support would just prefer their bugs to be moved over to the xorg-x11-drv-{intel|nouveau|ati} component. <br />
There, their triagers can gather needed info and debug the issue. If the problem is in the kernel, those maintainers can fix it, no need to leave the bug assigned to <br />
the kernel. <br />
<br />
:''This bug is in a video subsystem that has a kernel part. We track and work on these bugs via the driver package name instead of leaving them assigned to the kernel''<br />
<br />
== Rebase Regressions ==<br />
The kernel is often rebased to the latest stable kernel release and pushed as an update. This fixes a large amount of bugs, but it inevitably introduces a few regressions. If a bug is reported and it is determined that it worked with the previous kernel release, then a rebase regression entry should be added to the whiteboard field in the bug. This entry takes the form of:<br />
<br />
<pre>rebase-regression-<kernel version></pre><br />
<br />
E.g. if there is a regression when moving to the 3.1 kernel, it should be:<br />
<br />
<pre>rebase-regression-3.1</pre><br />
<br />
The latest working Fedora kernel version and the earliest broken version should be noted in the comment section if possible.<br />
<br />
This will allow the kernel developers to track regressions introduced by a rebased kernel. That will also help facilitate our communication with the upstream kernel developers, as we can report these bugs to them to be included in the regression lists that are published upstream.<br />
<br />
== Bugs with TAINTED modules ==<br />
Certain bug reports refer to a kernel module that is not open source software (mark this bugs with the keyword TAINTED):<br />
<br />
:''Thank you for taking the time to report this bug. Sadly, your report contains information about a not open-sourced module. This means you have loaded a module into your kernel that we can't debug, making it difficult to isolate the issue. Can you reproduce the issue without loading the tainted <module-name> module?.<br />
<br />
:''If you cannot duplicate the bug without the tainted module loaded it will be closed.''<br />
<br />
:''However, you can report it to the vendor of your non-free module.''<br />
<br />
== Stale Bugs ==<br />
<br />
If a bug has been in NEEDINFO with no response from the reporter for 2 weeks, close the bug out with INSUFFICIENT_DATA and the following text:<br />
<br />
:''This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.''<br />
<br />
{{Anchor|common_problems}}<br />
<br />
== Common Problems ==<br />
Point reporters to: [[KernelCommonProblems]]<br />
<br />
[[Category:Debugging]]</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=KernelBugTriage&diff=439449KernelBugTriage2016-03-18T16:45:53Z<p>Jwboyer: Update security link</p>
<hr />
<div>== Quick links to bug lists ==<br />
If you are looking for bugs to triage, start here:<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=VERIFIED&classification=Fedora&component=kernel&f1=flagtypes.name&keywords=Triaged%2C%20&keywords_type=nowords&list_id=1745711&o1=notsubstring&product=Fedora&query_format=advanced&v1=needinfo&version=21 Untriaged Fedora 21 Kernel Bugs]<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=VERIFIED&classification=Fedora&component=kernel&f1=flagtypes.name&keywords=Triaged%2C%20&keywords_type=nowords&list_id=1745711&o1=notsubstring&product=Fedora&query_format=advanced&v1=needinfo&version=22 Untriaged Fedora 22 Kernel Bugs]<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=VERIFIED&classification=Fedora&component=kernel&f1=flagtypes.name&keywords=Triaged%2C%20&keywords_type=nowords&list_id=1745711&o1=notsubstring&product=Fedora&query_format=advanced&v1=needinfo&version=23 Untriaged Fedora 23 Kernel Bugs]<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=VERIFIED&classification=Fedora&component=kernel&f1=flagtypes.name&keywords=Triaged%2C%20&keywords_type=nowords&list_id=1745711&o1=notsubstring&product=Fedora&query_format=advanced&v1=needinfo&version=rawhide Untriaged Rawhide Kernel Bugs]<br />
<br />
Full Bug Lists:<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&classification=Fedora&component=kernel&product=Fedora&query_format=advanced&version=21&order=bug_id%20DESC&query_based_on= Fedora 21 Kernel Bugs] <br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&classification=Fedora&component=kernel&product=Fedora&query_format=advanced&version=22&order=bug_id%20DESC&query_based_on= Fedora 22 Kernel Bugs] <br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&classification=Fedora&component=kernel&product=Fedora&query_format=advanced&version=23&order=bug_id%20DESC&query_based_on= Fedora 23 Kernel Bugs] <br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&classification=Fedora&component=kernel&product=Fedora&query_format=advanced&version=rawhide&order=bug_id%20DESC&query_based_on= Fedora rawhide Kernel Bugs]<br />
<br />
* [https://bugzilla.redhat.com/buglist.cgi?keywords=Security&keywords_type=anywords&order=Bug%20Number&classification=Fedora&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&version=14&version=15&version=16&version=17&version=18&version=19&version=20&version=21&version=22&version=23&version=24&version=rawhide&component=kernel&product=Fedora Fedora Kernel Security Bugs (all versions)]<br />
<br />
* [http://bugzilla.kernel.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&kernel_version_type=allwordssubstr&kernel_version=&bug_status=NEW&bug_status=ASSIGNED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&newqueryname=&field0-0-0=noop&type0-0-0=noop&value0-0-0= Upstream Kernel Bugs]<br />
<br />
== Triage Quickstart ==<br />
<br />
So you've decided to do kernel bug triage. AWESOME! We could use the help. If you're already familiar with bugzilla and the kernel, here is a quickstart set of steps to help us triage the existing bugs. If you aren't familiar with kernel bugs, or need a refresher, the rest of the page has some good background on various aspects of kernel triage and we encourage you to read it before diving in.<br />
<br />
Steps (Start at the top, work to the bottom):<br />
<br />
* Read over the bug and come up with a basic classification (kernel panic, boot issue, RFE, missing/broken functionality, etc). Add a comment to the bug that provides this classification.<br />
* Determine which kernel subsystem or driver is involved. Prefix the bug subject with the driver/subsytem (e.g. ALSA, USB, ACPI, etc).<br />
** If it is a bug in the video subsystem, reassign it to xorg-x11-drv-{ati,intel,nouveau}. Although the modesetting drivers live in the kernel, they are maintained by the same people who maintain our userspace graphics drivers. See [[KernelBugTriage#Video_Subsystem_bugs]]<br />
** If it is in one of these categories, please add the matching email address as a "CC" on the bug: <br />
{|<br />
! Subsystem/Driver<br />
! CC<br />
|-<br />
| ACPI || fedora-kernel-acpi@fedoraproject.org<br />
|-<br />
| Audit || fedora-kernel-audit@fedoraproject.org<br />
|-<br />
| block (Issues with block/* OR drivers/block/loop.c) || fedora-kernel-block@fedoraproject.org<br />
|-<br />
| DMAR (Intel IOMMU) || fedora-kernel-dmar@fedoraproject.org<br />
|- <br />
| Ethernet (all issues) || fedora-kernel-ethernet@fedoraproject.org<br />
|-<br />
| Ethernet (atl1*, alx) || fedora-kernel-ethernet-ath@fedoraproject.org<br />
|-<br />
| Ethernet (bnx2, bnx2x, b44, tg3) || fedora-kernel-ethernet-broadcom@fedoraproject.org<br />
|-<br />
| Ethernet (r8169) || fedora-kernel-ethernet-realtek@fedoraproject.org<br />
|-<br />
| Filesystems (AIO, fs/aio.c) || fedora-kernel-aio@fedoraproject.org<br />
|-<br />
| Filesystems (BTRFS) || fedora-kernel-btrfs@fedoraproject.org<br />
|-<br />
| Filesystems (CIFS) || nfs-maint@redhat.com<br />
|-<br />
| Filesystems (DirectIO, fs/direct-io.c) || fedora-kernel-directio@fedoraproject.org<br />
|-<br />
| Filesystems (EXT2/EXT3/EXT4/JBD) || fedora-kernel-extfs@fedoraproject.org<br />
|-<br />
| Filesystems (fs/buffer.c) || fedora-kernel-fsbuffer@fedoraproject.org<br />
|-<br />
| Filesystems (NFS) || nfs-maint@redhat.com<br />
|-<br />
| Filesystems (XFS) || fedora-kernel-xfs@fedoraproject.org<br />
|-<br />
| Firewire || fedora-kernel-firewire@fedoraproject.org<br />
|-<br />
| Graphics (DRM core, but not Radeon/Intel/Nouveau drivers) || fedora-kernel-drm@fedoraproject.org<br />
|-<br />
| HID/Input/Multitouch (but not WACOM) || fedora-kernel-input@fedoraproject.org<br />
|-<br />
| intel-pstate (cpufreq driver) || fedora-kernel-intelpstate@fedoraproject.org<br />
|-<br />
| KVM virtualization || fedora-kernel-kvm@fedoraproject.org<br />
|-<br />
| LVM and device-mapper || lvm-team@redhat.com<br />
|-<br />
| Networking (NFC) || fedora-kernel-nfc@fedoraproject.org<br />
|-<br />
| Networking (TCP, UDP, SCTP, IP) || fedora-kernel-networking@fedoraproject.org<br />
|-<br />
| OpenVSwitch || fedora-kernel-openvswitch@fedoraproject.org<br />
|-<br />
| ptrace and utrace || fedora-kernel-ptrace@fedoraproject.org<br />
|-<br />
| PCI / PnP resource allocation || fedora-kernel-pci@fedoraproject.org<br />
|-<br />
| RAID (drivers/md) || fedora-kernel-raid@fedoraproject.org<br />
|-<br />
| SATA and libata || fedora-kernel-ata@fedoraproject.org<br />
|-<br />
| SCSI and libsas || fedora-kernel-scsi@fedoraproject.org<br />
|-<br />
| SELinux || fedora-kernel-selinux@fedoraproject.org<br />
|-<br />
| UEFI || fedora-kernel-uefi@fedoraproject.org<br />
|-<br />
| USB Video Cameras || fedora-kernel-usb-cameras@fedoraproject.org<br />
|-<br />
| Video4Linux || fedora-kernel-v4l@fedoraproject.org<br />
|-<br />
| Xen virtualization || fedora-kernel-xen@fedoraproject.org<br />
|-<br />
| Wireless (generic issues, or issues that do not match one of the below drivers) || fedora-kernel-wireless@fedoraproject.org<br />
|-<br />
| Wireless (ath*k) || fedora-kernel-wireless-ath@fedoraproject.org<br />
|-<br />
| Wireless (Broadcom (b43)) || fedora-kernel-wireless-b43@fedoraproject.org<br />
|-<br />
| Wireless (brcm80211) || fedora-kernel-wireless-brcm80211@fedoraproject.org<br />
|-<br />
| Wireless (Intel (iwlwifi and iwlegacy (iwl3945 and iwl4965))) || fedora-kernel-wireless-iwl@fedoraproject.org<br />
|-<br />
| Wireless (Ralink (rt2x00)) || fedora-kernel-wireless-ralink@fedoraproject.org<br />
|-<br />
| Wireless (Realtek (rtlwifi, r8712u)) || fedora-kernel-wireless-realtek@fedoraproject.org<br />
|}<br />
* If multiple categories apply, add them each to the CC list.<br />
* For oopses, add the oopsing function to the end of the bug subject. E.g. IP:hci_send_sco. For things like __list_del_entry, which are common kernel functions, try to find the latest function that was called before that and use that as the suffix.<br />
* Look for duplicate bugs across all Fedora releases. If you find a duplicate, use whichever bug has the most information as the "active" bug and duplicate the other in bugzilla. If you duplicate a bug from a newer release against one in an older release, then change the version on the active bug to the newest version the issue has been seen on.<br />
* If the bug is new, try to determine which kernel version it was first seen with. Note this in the bugzilla whiteboard with "first=X.Y.Z" (e.g. first=3.1.0). Also try to determine which kernel version is the latest tested and still having the issue. Note this in the bugzilla whiteboard with "latest=X.Y.Z" (e.g. latest=3.8.7).<br />
* If the bug is missing information, ask for it and put the bug in NEEDINFO. This can include things like dmesg, modules in use, full panic/oops backtraces, or questions as to what was occurring on the machine at the time. Information should be attached as text/plain attachments, or simple comments in the bug if the information is fairly short. In order to avoid information overload, please ask for only relevant missing information (e.g. we don't need /proc/cpuinfo for wifi bugs, etc).<br />
* If the bug looks fairly straightforward, try and see if upstream knows about it.<br />
** Look on the various mailing lists and kernel.org bugzilla to see if something similar has been reported upstream (or google search). If so, add a reference to the Fedora bug in the thread or in the kernel.org bug.<br />
** If it doesn't appear to be reported upstream, use the MAINTAINERS and scripts/get_maintainers.pl files in the kernel tree to narrow down who to report the issue to. Send them an email with all the relevant details from the bug, with kernel-team@fedoraproject.org on CC. Add a link to the mailing list thread archive of the email you sent to the Fedora bug, or use the external references field to pair it with a kernel.org bug.<br />
* Mark the bug as Triaged with the bugzilla Triaged keyword.<br />
<br />
== Kernel Bug Classification ==<br />
[[KernelBugClassification]]<br />
<br />
== Kernel Bugzilla Basics ==<br />
<br />
* If there's an upstream (http://bugzilla.kernel.org) bug that matches<br />
** In the Fedora bug, set 'external bugzilla references' to point to the upstream bug number<br />
** In the upstream kernel.org bugzilla, add a comment along the lines of "also seen in Fedora. http://bugzilla.redhat.com/show_bug.cgi?id=253096"<br />
* If the bug is against an already released Fedora (Ie, Fedora 7) and there isn't much information to go on "my machine locked up" for eg, request that the user try to reproduce the problem using the kernel-debug kernel. The additional debugging checks may trigger some clues.<br />
* If the bug you are triaging contains a patch, please add [PATCH] to the beginning of the summary line of the bugzilla.<br />
* Sometimes a user will attach a kernel panic as a jpeg, or in worst case, as a tarball of their /var/log/messages.<br />
** It saves the kernel team time if the kernel oops parts of these are transcribed/cut out and pasted into the bug as text.<br />
* Additionally, making sure that text attachments of bugs have their MIME type set to text/plain can save some time.<br />
* You can ask reporters to try and duplicate with the latest nightly live composes: http://alt.fedoraproject.org/pub/alt/nightly-composes/<br />
* You can ask reporters to try the newest kernel available in koji: http://koji.fedoraproject.org/koji/packageinfo?packageID=8<br />
* If the bug appears to be video/kernel modesetting related, reassign it to the xorg-x11-drv-{intel,ati,nouveau} component. See [[KernelBugTriage#Video_Subsystem_bugs]]<br />
* If the reporter is using a custom compiled kernel, close the bug as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=126342<br />
<br />
== Bug state transitions ==<br />
<br />
* A bug marked as MODIFIED has patches in testing and should not have their status changed. An exception to this is when a bug has been in MODIFIED state for some time (this usually indicates that the issue was fixed in an update, and no-one ever closed the bug. If in doubt, ping the reporter to retest with the latest build).<br />
* If a bug has been in NEEDINFO for several weeks with no follow-up from the reporter, there's not a great deal we can do. In this situation, closing the bug is the only recourse available (which does actually tend to 'wake up' some reporters who then reopen the bug). See [[KernelBugTriage#Stale_Bugs]] below.<br />
* When marking bugs as duplicates, we want the one with the most information to be the one that remains open, even if this means a higher numbered bug gets closed. Also, the Fedora release branches are kept on essentially the same kernel version. Therefore, if the same bug is reported in both releases then we close one of them as a duplicate of the other following the aforementioned rule. Duplicating bugs across releases is one way to control the bug count.<br />
* Don't close bugs marked beginning with [mmconf] or [msi] (bugs beginning with [$something] are usually specifically marked so developers can quickly see the main issue within the bug)<br />
<br />
== NEW state bugs ==<br />
<br />
If the bug is new and (this type of bug must be key-worded in either WHITEBOARD or BLOCKER):<br />
Hello, <br />
<br />
:''Thank you for taking the time to report this bug. I have added the proper keyword to this bug to bring it to the attention of the <subsystem-name> subsystem maintainer. <br />
<br />
:''Can you attach the following information to this bug: ''<br />
Then pick the info that is useful in this case:<br />
<br />
* dmesg output from boot before issue. <br />
* dmesg output after issue. <br />
* dmesg output from boot with 'quiet' option replaced with 'debug'<br />
* lspci output<br />
* lsusb output<br />
<br />
For other necessary information check:<br />
* X bugs see: http://fedoraproject.org/wiki/How_to_debug_Xorg_problems.<br />
* Other troubleshooting ideas: http://fedoraproject.org/wiki/Common_kernel_problems.<br />
<br />
== Bug assignment ==<br />
Assigning/cc'ing people responsible for the relevant subsystem is a good idea.<br />
<br />
When reassigning bugs to yourself, add kernel-maint@redhat.com to Cc:<br />
<br />
If you are an upstream developer, and would like to be added to the Cc: of relevant bugs, send an email to kernel-team at fedoraproject.org,<br />
(We used to maintain this here on the wiki, but for a number of reasons, we now maintain this list privately)<br />
<br />
== Possibly fixed in CURRENTRELEASE (Stick for prodding sleeping bugs with) ==<br />
<br />
If the bug is against a previous point release kernel, and the reporter hasn't re-tested (this type of bugs must be set in NEEDINFO_REPORTER state):<br />
<br />
:''Thank you for taking the time to report this bug. Updates to the kernel have been released since it was first reported. If you have time to update the package and re-test, please do so and report the results here. You can obtain the updated package by typing in Fedora 22 and later versions <code>'dnf upgrade kernel'</code> and in Fedora 21 and earlier versions <code>'yum update kernel'</code>or using the graphical updater, Software Update. If the problem no longer exists then please close this bug or it will be closed in a few weeks if there is no additional information lodged.''<br />
<br />
== Installer bugs ==<br />
If the bug refers to problems when installing Fedora in any of the possible ways CD, DVD, USB, network, etc (this type of bugs must be set in NEEDINFO_REPORTER state):<br />
<br />
:''Thank you for taking the time to report this bug. Bugs involving the installation process cannot usually be resolved after release date. We therefore ask reporters to use one (or both) of the following options:<br />
<br />
:''Test with an Alpha, Beta or Release Candidate for the next version. These can be found at http://fedoraproject.org/get-prerelease and by testing these we can work to resolve any installation issues so that the final release is free of such bugs.''<br />
<br />
:''However if the problem no longer exists then please close this bug or it will be closed in a few weeks if there is no additional information lodged.''<br />
<br />
{{admon/important|get-prerelease link|The ''get-prerelease'' link sometimes is not available or have not updated development releases.}}<br />
<br />
== Video Subsystem bugs ==<br />
<br />
The various video subsystems that have kernel modesetting support would just prefer their bugs to be moved over to the xorg-x11-drv-{intel|nouveau|ati} component. <br />
There, their triagers can gather needed info and debug the issue. If the problem is in the kernel, those maintainers can fix it, no need to leave the bug assigned to <br />
the kernel. <br />
<br />
:''This bug is in a video subsystem that has a kernel part. We track and work on these bugs via the driver package name instead of leaving them assigned to the kernel''<br />
<br />
== Rebase Regressions ==<br />
The kernel is often rebased to the latest stable kernel release and pushed as an update. This fixes a large amount of bugs, but it inevitably introduces a few regressions. If a bug is reported and it is determined that it worked with the previous kernel release, then a rebase regression entry should be added to the whiteboard field in the bug. This entry takes the form of:<br />
<br />
<pre>rebase-regression-<kernel version></pre><br />
<br />
E.g. if there is a regression when moving to the 3.1 kernel, it should be:<br />
<br />
<pre>rebase-regression-3.1</pre><br />
<br />
The latest working Fedora kernel version and the earliest broken version should be noted in the comment section if possible.<br />
<br />
This will allow the kernel developers to track regressions introduced by a rebased kernel. That will also help facilitate our communication with the upstream kernel developers, as we can report these bugs to them to be included in the regression lists that are published upstream.<br />
<br />
== Bugs with TAINTED modules ==<br />
Certain bug reports refer to a kernel module that is not open source software (mark this bugs with the keyword TAINTED):<br />
<br />
:''Thank you for taking the time to report this bug. Sadly, your report contains information about a not open-sourced module. This means you have loaded a module into your kernel that we can't debug, making it difficult to isolate the issue. Can you reproduce the issue without loading the tainted <module-name> module?.<br />
<br />
:''If you cannot duplicate the bug without the tainted module loaded it will be closed.''<br />
<br />
:''However, you can report it to the vendor of your non-free module.''<br />
<br />
== Stale Bugs ==<br />
<br />
If a bug has been in NEEDINFO with no response from the reporter for 2 weeks, close the bug out with INSUFFICIENT_DATA and the following text:<br />
<br />
:''This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.''<br />
<br />
{{Anchor|common_problems}}<br />
<br />
== Common Problems ==<br />
Point reporters to: [[KernelCommonProblems]]<br />
<br />
[[Category:Debugging]]</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Building_a_custom_kernel&diff=433976Building a custom kernel2016-02-11T15:47:18Z<p>Jwboyer: Get rid of the dnf download/yumdownloader steps. They're confusing and only work for whatever version is in the updates repo. Just use koji which will work for any build.</p>
<hr />
<div>[[Category:Documentation]][[Category:Tutorials]]<br />
{{autolang|base=yes}}<br />
<br />
This document provides instructions for advanced users who want to rebuild the kernel from some source. Note, however, that when building or running any such kernel, one should NOT expect support from the Fedora kernel team; you're pretty much on your own here if something doesn't work as you'd hoped or expected. But hey, you're an advanced user, so you can handle it, right? Anyway, advanced users build custom kernels for a variety of reasons:<br />
<br />
* To apply patches for testing that they either generated or obtained from another source<br />
* To reconfigure the existing kernel<br />
* To learn more about the kernel and kernel development<br />
<br />
<br />
== Dependencies for building kernels ==<br />
Not all of these will apply to all methods but this provides a good dependency list of items to install<br />
<br />
<code> # sudo dnf install fedpkg fedora-packager rpmdevtools ncurses-devel pesign pesign-rh-test-certs</code><br />
<br />
Give the following command from the top directory of the kernel source tree once you have checked it out<br />
<br />
<code> # sudo dnf builddep kernel.spec</code><br />
<br />
if you plan to run 'make xconfig'<br />
<br />
<code> # sudo dnf install qt3-devel libXi-devel gcc-c++</code><br />
<br />
Also make sure you add the user doing the build to /etc/pesign/users and run the authorize user script:<br />
<br />
<code># sudo /usr/libexec/pesign/pesign-authorize-users</code><br />
<br />
It should be noted that pesign pesign-rh-test-certs gets pulled in automatically for some, but not for everyone, it depends on how you installed pesign. It is best to make sure that you have it installed.<br />
<br />
{{admon/note|dnf versus yum|As of Fedora 22[https://docs.fedoraproject.org/en-US/Fedora/22/html/Release_Notes/] [[dnf]] has replaced [[yum]] as the default package manager. In the event you are building a kernel for an older system you will either have to install dnf or substitute <code>yum</code> for <code>dnf</code> and/or <code>yumdownloader</code> from the <code>yum-utils</code> package.}}<br />
<br />
== Building a Kernel from the Fedora source tree ==<br />
<br />
Make sure you have installed all dependencies<br />
<br />
<code> $ fedpkg clone kernel </code><br />
<br />
you will likely need to checkout the source anonymously unless you have an Fedora developer account<br />
<br />
<code> $ fedpkg clone -a kernel </code><br />
<br />
As of the time of this wiki writing (April 2015), the kernel was managed using git. Each fedora release is a separate branch. rawhide tracks master. To get the tree for a particular release, you can use git checkout from the top of your newly created source tree.<br />
<br />
e.g. for fedora 22,<br />
<br />
<code> $ git checkout origin/f22 </code><br />
<br />
You can now make whatever changes / customizations you need before generating the rpms and installing them. When finished, generate the appropriate rpms with<br />
<br />
<code> $ fedpkg local </code><br />
<br />
The rpms will be generated in a subdirectory $ARCH which can then be installed:<br />
<br />
<code> $ dnf install --nogpgcheck ./x86_64/kernel-$version.rpm </code><br />
<br />
=== Building a non-debugging kernel ===<br />
<br />
Branched kernels are built with debugging enabled by default in the early stages of the release to assist developers. To make a kernel with debugging information disabled, you can follow the above instructions to check out and do:<br />
<br />
<code> $ make release </code><br />
<br />
<code> $ fedpkg local </code><br />
<br />
=== Enabling config options ===<br />
<br />
If there are configuration options that need to be adjusted for your build, you can add changes in the config-local file. This will override anything set in the rest of the defconfigs.<br />
<br />
=== Updating ===<br />
<br />
<br />
* <code> $ cd kernel </code><br />
* <code> kernel $ git status </code><br />
** your tree will be dirty in the configs and kernel.spec <br />
* <code> kernel $ git stash </code><br />
** puts aside your changes so your tree will be clean<br />
* <code> kernel $ git pull origin </code><br />
** update to the latest tree from fedpkg git<br />
<br />
Now you can run whatever other commands you want (e.g. make release)<br />
<br />
== Building a Kernel from the source RPM ==<br />
<br />
Make sure you have installed all dependencies<br />
<br />
=== Get the Source ===<br />
{{Admon/warning |Do Not Build Packages as <code>root</code>. | Configuring and building packages as <code>root</code> is inherently dangerous and not required, even for the kernel. The following instructions allow any normal user to configure and build kernels from the source packages.}}<br />
<br />
# Prepare an RPM package-building environment in your (non-root) home directory by running the following command: <pre>rpmdev-setuptree</pre>This command creates a new directory <code>~/rpmbuild</code>, with several empty subdirectories including <code>SPECS</code>, <code>SOURCES</code>, <code>BUILD</code> and others. It also creates an initial <code>~/.rpmmacros</code> customization file for you.<br />
# Download the <code>kernel-<version>.src.rpm</code> file: <pre>koji download-build --arch=src kernel-<version></pre><br />
<br />
<br />
# Install build dependencies for the kernel source with the <code>dnf builddep</code> command (root is required to install these packages):<pre>su -c 'dnf builddep kernel-<version>.src.rpm'</pre><br />
# Install <code>kernel-<version>.src.rpm</code> with the following command:<pre>rpm -Uvh kernel-<version>.src.rpm</pre>This command writes the RPM contents into <code>${HOME}/rpmbuild/SOURCES</code> and <code>${HOME}/rpmbuild/SPECS</code>, where <code>${HOME}</code> is your home directory. It is safe to ignore any messages similar to the following:<br />
<pre>warning: user kojibuilder does not exist - using root<br />
warning: group kojibuilder does not exist - using root<br />
</pre><br />
<br />
{{Admon/warning | Space Required. The full kernel building process requires several gigabytes of extra space on the file system containing your home directory.}}<br />
<br />
=== Prepare the Kernel Source Tree ===<br />
This step expands all of the source code files for the kernel. This is required to view the code, edit the code, or to generate a patch. (Again, all of this should be done as a regular user, not as root.)<br />
<br />
1. Prepare the kernel source tree using the following commands:<br />
<pre>cd ~/rpmbuild/SPECS<br />
rpmbuild -bp --target=$(uname -m) kernel.spec<br />
</pre><br />
<br />
The unloaded and patched kernel source tree is now located in the <code>~/rpmbuild/BUILD/kernel-<version>/linux-<version>.<arch></code> directory.<br />
<br />
=== Copy the Source Tree and Generate a Patch ===<br />
This step is for applying a patch to the kernel source. If a patch is not needed, proceed to "Configure Kernel Options".<br />
<br />
{{admon/note|Advanced Users|There are tools such as 'quilt' that allow you to avoid copying the source tree. For advanced users, such tools are often a time saver over the steps below|}}<br />
<br />
Copy the source tree to preserve the original tree while making changes to the <br />
<br />
<br />
<pre><br />
export arch=x86_64 # replace x86_64 with your arch<br />
export ver=3.7 # replace 3.1 with your kernel version<br />
export subver=4-204<br />
export fedver=fc16 # replace fc16 with your fedora version <br />
cp -r ~/rpmbuild/BUILD/kernel-$ver.$subver.$fedver ~/rpmbuild/BUILD/kernel-$ver.$fedver.orig<br />
cp -al ~/rpmbuild/BUILD/kernel-$ver.$subver.$fedver.orig ~/rpmbuild/BUILD/kernel-$ver.$fedver.new<br />
</pre><br />
<br />
{{Admon/warning | The second <code>cp</code> command hardlinks the <code>.orig</code> and <code>.new</code> trees to make <code>diff</code> run faster. Most text editors know how to break the hardlink correctly to avoid problems. Vim does not break hard links by default, so don't use 'cp -al' use 'cp -r', or look into the 'breakhardlink' setting.}}<br />
<br />
Using vim on FC14, it treated the hard link as a hard link and thus the above technique failed. It was necessary to repeat the original copy used for the .orig directory for the .new directory. Note that this uses twice the space.<br />
<br />
Make changes directly to the code in the <code>.new</code> source tree, or copy in a modified file. This file might come from a developer who has requested a test, from the upstream kernel sources, or from a different distribution.<br />
<br />
After the <code>.new</code> source tree is modified, generate a patch. To generate the patch, run <code>diff</code> against the entire <code>.new</code> and <code>.orig</code> source trees with the following command:<br />
<br />
<pre><br />
cd ~/rpmbuild/BUILD<br />
diff -uNrp kernel-$ver.$subver.$fedver.orig kernel-$ver.$subver.$fedver.new > ../SOURCES/linux-$ver.$subver.$fedver-mynewpatch.patch<br />
</pre><br />
<br />
Replace 'linux-$ver.$subver.$fedver-mynewpatch.patch' with the desired name for the new patch.<br />
<br />
Lastly edit the patch file to remove the leading directory, this is required because the kernel spec file applies patches with '-p1' only.<br />
<br />
For example the following:<br />
<pre><br />
--- kernel-3.8.fc18.orig/linux-3.8.11-200.bz708406.fc18.x86_64/kernel/kexec.c 2013-02-18 18:58:34.000000000 -0500<br />
+++ kernel-3.8.fc18.new/linux-3.8.11-200.bz708406.fc18.x86_64/kernel/kexec.c 1969-12-31 19:00:00.000000000 -0500<br />
</pre><br />
<br />
Should be changed to:<br />
<pre><br />
--- linux-3.8.11-200.bz708406.fc18.x86_64/kernel/kexec.c 2013-02-18 18:58:34.000000000 -0500<br />
+++ linux-3.8.11-200.bz708406.fc18.x86_64/kernel/kexec.c 1969-12-31 19:00:00.000000000 -0500<br />
</pre><br />
<br />
<br />
{{Admon/warning | For more information on patching refer to the man pages for <code>diff(1)</code> and <code>patch(1)</code>.}}<br />
<br />
=== Configure Kernel Options ===<br />
This step is for modifying the options the kernel is configured with. This step is optional. If no configuration changes are needed, proceed to "Prepare Build Files".<br />
<br />
{{admon/important|Small changes|If you only want to make a small number of configuration changes, you should simply set the options as desired in the config-local file. This will be sourced and override the remaining config-* files and avoids a lot of unnecessary work. You can skip the steps below if you use config-local}}<br />
<br />
# Change to the kernel source tree directory:<pre>cd ~/rpmbuild/BUILD/kernel-$ver.$fedver/linux-$ver.$subver.$fedver.$arch/</pre> If you only want to make minor changes to the default fedora kernel, skip to step 4., and use one of the two configuration tools to edit those minor changes into the default config file.<br />
# Select the desired configuration file from <code>~/rpmbuild/BUILD/kernel-$ver.$fedver/linux-$ver.$subver.$fedver.$arch/configs</code>. Copy the desired config file to <code>~/rpmbuild/BUILD/kernel-$ver.$fedver/linux-$ver.$subver.$fedver.$arch/.config</code>: <pre>cp configs/<desired-config-file> .config</pre><br />
# Run the following command: <pre>make oldconfig</pre><br />
# Then run the following command, selecting and saving the desired kernel options from the text-based UI:<pre>make menuconfig</pre><br />
#* For a graphical UI, instead run: <pre>make xconfig</pre><br />
# Add a new line to the top of the config file that contains the hardware platform the kernel is built for (the output of <code>uname -i</code>). The line is preceded by a <code>#</code> sign. For example, an x86_64 machine would have the following line added to the top of the config file:<pre># x86_64</pre><br />
# Copy the config file to <code>~/rpmbuild/SOURCES/</code>: <pre>cp .config ~/rpmbuild/SOURCES/config-`uname -m`-generic</pre><br />
{{admon/important|32-bit x86 kernels|The 32-bit PAE kernel uses the config-i686-PAE configuration file. If you are building a PAE kernel, you will need to copy your config file to <code>~/rpmbuild/SOURCES/</code>: <pre> cp .config ~/rpmbuild/SOURCES/config-i686-PAE</pre> If you are building a non-PAE kernel, you will need to copy your config file to <pre> cp .config ~/rpmbuild/SOURCES/config-x86-32-generic</pre>. Again, the use of config-local is encouraged unless you are making a large number of configuration changes.}}<br />
<br />
=== Prepare Build Files ===<br />
This step makes the necessary changes to the <code>kernel.spec</code> file. This step is required for building a custom kernel.<br />
<br />
1. Change to the <code>~/rpmbuild/SPECS</code> directory:<br />
<br />
<pre>cd ~/rpmbuild/SPECS<br />
</pre><br />
<br />
2. Open the <code>kernel.spec</code> file for editing.<br><br />
3. Give the kernel a unique name. This is important to ensure the custom kernel is not confused with any released kernel. Add a unique string to the kernel name by changing the 'buildid' line. Optionally, change ".local" to your initials, a bug number, the date or any other unique string.<br />
<br />
Change this line:<br />
<pre><br />
#% define buildid .local<br />
</pre><br />
<br />
To this (note the extra space is removed in addition to the pound sign):<br />
<pre><br />
%define buildid .<custom_text><br />
</pre><br />
<br />
4. If you generated a patch, add the patch to the <code>kernel.spec</code> file, preferably at the end of all the existing patches and clearly commented.<br />
<br />
<pre># cputime accounting is broken, revert to 2.6.22 version<br />
Patch2220: linux-2.6-cputime-fix-accounting.patch<br />
<br />
Patch9999: linux-2.6-samfw-test.patch<br />
</pre><br />
<br />
The patch then needs to be applied in the patch application section of the spec file. Again, at the end of the existing patch applications and clearly commented.<br />
<br />
<pre><br />
ApplyPatch linux-2.6-cputime-fix-accounting.patch<br />
<br />
ApplyPatch linux-2.6-samfw-test.patch<br />
<br />
<br />
</pre><br />
<br />
=== Build the New Kernel ===<br />
This step actually generates the kernel RPM files. This step is required for building a custom kernel.<br />
<br />
Use the <code>rpmbuild</code> utility to build the new kernel:<br />
<br />
* Ensure /usr/sbin is in your path (to pull in /usr/sbin/modinfo):<br />
<pre>export PATH=/usr/sbin:$PATH<br />
</pre><br />
<br />
* To build all kernel flavors:<br />
<pre>rpmbuild -bb --target=`uname -m` kernel.spec<br />
</pre><br />
<br />
* To disable specific kernel flavors from the build (for a faster build):<br />
<br />
<pre>rpmbuild -bb --without <option> --target=`uname -m` kernel.spec<br />
</pre><br />
<br />
Valid values for "option" above include <code>xen</code>, <code>smp</code>, <code>up</code>, <code>pae</code>, <code>kdump</code>, <code>debug</code> and <code>debuginfo</code>. Specifying <code>--without debug</code> strips out some debugging code from the kernels, where specifying <code>--without debuginfo</code> disables the building of the <code>kernel-debuginfo</code> packages.<br />
<br />
* To specify that only a specific kernel should be built:<br />
<br />
<pre>rpmbuild -bb --with <option> --target=`uname -m` kernel.spec<br />
</pre><br />
<br />
Valid values for "option" above include <code>xenonly</code>, <code>smponly</code>, and <code>baseonly</code>.<br />
<br />
* For example, to build just the kernel and kernel-devel packages, the command would be:<br />
<br />
<pre>rpmbuild -bb --with baseonly --without debuginfo --target=`uname -m` kernel.spec<br />
</pre><br />
<br />
The build process takes a long time to complete. A lot of messages will be printed to the screen. These messages can be ignored, unless the build ends with an error. If the build completes successfully, the new kernel packages will be located in the <code>~/rpmbuild/RPMS</code> directory.<br />
<br />
{{Admon/warning | TO DO | add a troubleshooting section}}<br />
<br />
==== Following Generic Textbooks ====<br />
<br />
Many of the tutorials, examples, and textbooks about Linux kernel development assume the kernel sources are installed under the <code>/usr/src/linux/</code> directory. If you make a symbolic link, as shown below, you should be able to use those learning materials with the Fedora packages. Install the appropriate kernel sources, as shown earlier, and then run the following command:<br />
<br />
<pre>su -c 'ln -s /usr/src/kernels/<version>.<release>-<arch> /usr/src/linux'<br />
</pre><br />
<br />
Enter the <code>root</code> password when prompted.<br />
<br />
=== Install the New Kernel ===<br />
This step actually installs the new kernel into the running system.<br />
<br />
To install the new kernel, use the <code>rpm -ivh</code> command, '''not''' the <code>-U</code> or <code>--upgrade</code> options:<br />
<br />
<pre>su -c "rpm -ivh $HOME/rpmbuild/RPMS/<arch>/kernel-<version>.<arch>.rpm"<br />
</pre><br />
<br />
This command will install your kernel in /boot, create a new initramfs to bootstrap your kernel, and automatically add your new kernel to your grub bootloader "menu.lst". At this point, you can reboot to give control to your new kernel.<br />
<br />
== Building Only Kernel Modules (Out Of Tree Modules) ==<br />
<br />
{{Admon/warning | This section needs to be updated and fleshed out}}<br />
<br />
This section is for users who are only interested in working on a kernel module, and who do not wish to build an entire custom kernel. It is not necessary to download and rebuild the entire kernel in order to build a module. To build a module for the currently running kernel, only the matching <code>kernel-devel</code> package is required. Run the following command to install the <code>kernel-devel</code> package using <code>dnf</code>.<br />
<br />
<pre>su -c 'dnf install kernel-devel'<br />
</pre><br />
<br />
{{Admon/note | You may need to install 'kernel-PAE-devel' if you are using the PAE kernel}} <br />
<br />
You can build against any kernel version, as long as you have <code>kernel</code> and <code>kernel-devel</code> packages installed for that version. The rest of this section assumes we're building for the running kernel; if not, replace <code>`uname -r`</code> with the desired version number.<br />
<br />
{{Admon/note | The kernel-doc package contains official Kbuild documentation - see files under Documentation/kbuild, in particular the modules.txt file. }}<br />
<br />
As a simple example, to build the <code>foo.ko</code> module from <code>foo.c</code>, create the following <code>Makefile</code> in the directory containing the <code>foo.c</code> file:<br />
<br />
<pre>obj-m := foo.o<br />
<br />
KDIR := /lib/modules/$(shell uname -r)/build<br />
PWD := $(shell pwd)<br />
<br />
default:<br />
[TAB]$(MAKE) -C $(KDIR) M=$(PWD) modules<br />
</pre><br />
[TAB] Denotes a tab character which must come first for makefile lines containing commands.<br />
<br />
Then, issue the <code>make</code> command to build the <code>foo.ko</code> module.<br />
<br />
The above is a helpful local Makefile wrapper invoking kbuild; in general you can simply do things like<br />
<br />
<pre># make -C /lib/modules/`uname -r`/build M=`pwd` modules<br />
# make -C /lib/modules/`uname -r`/build M=`pwd` clean<br />
# make -C /lib/modules/`uname -r`/build M=`pwd` modules_install<br />
</pre><br />
<br />
etc to build those targets.<br />
<br />
== Building Vanilla upstream kernel ==<br />
<br />
Sometimes a Fedora developer may ask you to try building and installing an upstream kernel (possibly with a patch added) for testing.<br />
If there are multiple iterations, it may be quicker for you to do this than for the developer to turn around several RPMs.<br />
<br />
=== Existing Fedora Vanilla packages ===<br />
<br />
There is an effort underway for packaging vanilla kernels. [[Kernel_Vanilla_Repositories | See if this meets your needs first]]<br />
<br />
=== Getting the sources ===<br />
<br />
Clone a kernel tree from kernel.org <br />
<br />
{{Admon/note | Tips for developing with kernel.org sources|The README file in the top-level directory provides very good build instructions, including how to direct the build to a particular directory, the necessary make targets, and the order in which to issue them. Save time by reviewing the Documentation directory and its sub-directories containing informative ".txt" files. View the top level Makefile for kernel version information.}}<br />
<br />
<code> $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git </code><br />
This will clone the entire upstream tree. This may take a while depending on your connection speed. (While the tree is syncing, why not take the time to update some steps on this wiki that are inevitably out of date?)<br />
<br />
<code> $ cd linux </code><br />
<br />
Double check what baseline is being used and check out a new one if necessary:<br />
<br />
<code> $ git checkout v3.19 </code><br />
<br />
=== Applying patches ===<br />
<br />
==== The patch method ====<br />
If you were asked to apply any patches by the developer, this is the stage at which we would do so.<br />
These would typically be applied using a command something like..<br />
<br />
<code> $ cat ~/testpatch.diff | patch -p1 </code><br />
<br />
If you have to try multiple different patches individually, you can unapply the previous one after testing by adding -R on the end of the above command.<br />
<br />
==== The git method ====<br />
<br />
Most developers these days generate patches using git and you can use git to help apply patches. You can do:<br />
<br />
<code> $ git am -3 <patch file> </code><br />
<br />
This will create a git commit of a single patch in your tree. <br />
<br />
=== Configuring the kernel ===<br />
{{admon/note| Potential options to the instructions below|Consider using the make targets "mrproper" and "menuconfig" as specified in the top-level README file. The "menuconfig" target is an alternative to "oldconfig" and pops up a menu that allows you to easily set virtually all build options. Accepting the defaults is generally fine, although you can use the "General Setup->Local version" option to append a label to your build instead of tweaking "EXTRAVERSION" in the .config file.}}<br />
<br />
Chances are that the kernel you are running is older than the one you are about to configure. This means there will be new options.<br />
There are several possibilities here.<br />
* If the developer has pointed you at a specific config file to use, save it in the linux directory with the filename .config<br />
* You can take your existing .config file by using the command <code>cp /boot/config-`uname -r`* .config</code><br />
When you run the next step, you'll be asked (potentially lots of) questions about all the new options. Just hitting return 'should' always pick the safe decision for each option. However, it's worth taking care and reading each option, as this isn't always the case, and they may introduce new features your distro isn't capable of running, which may result in a non-booting system.<br />
* FIXME how to grab a rawhide config<br />
<br />
With the config in place, you are now ready to move on to the next step.<br />
<br />
=== Building the kernel ===<br />
<code> $EDITOR Makefile </code><br />
Change the EXTRAVERSION line to add something on the end. For example, if it reads "EXTRAVERSION = -rc5" change it to "EXTRAVERSION = -rc5-dave" (what you choose is only relevant for the final part of this procedure)<br />
<br />
<code> $ make oldconfig </code><br />
<br />
<code> $ make bzImage </code><br />
<br />
<code> $ make modules </code><br />
<br />
(become root)<br />
<br />
<code> # make modules_install </code><br />
<code> # make install </code><br />
<br />
You have now built and installed a kernel. It will show up in the grub menu next time you reboot.<br />
<br />
=== Rebuilding ===<br />
If you have been asked to try several different things, the procedure once you have already built the tree once is mostly the same. A <code>make clean</code> is recommended between builds. This will leave the .config in place, so you can skip that step above and proceed straight to the <code>make bzImage</code> part of the steps above. Because we installed ccache in the first step, subsequent builds may go a lot faster as the compiler hits files that haven't changed since the last time it built them.<br />
<br />
=== Cleaning up ===<br />
Once you have tested the kernel, and you've booted back to one of your kernels installed from an RPM, you can clean up the files that the above procedure installed by becoming root, and calling these commands. (Be sure to get the kernel version correct!) Remember above, we changed EXTRAVERSION to add a 'tag' to the kernel ? All the files it installed will have this as part of the filename. So you should be able to use wildcards to delete them safely using commands similar to those below. (Just replace 'dave' with whatever tag you chose)<br />
<pre><br />
rm -f /boot/config-2.6.*dave* /boot/initrd-2.6.*dave* /boot/vmlinuz-*dave* /boot/System.map-*dave*<br />
rm -rf /lib/modules/2.6*dave*<br />
</pre><br />
Finally, you will need to remove the kernel as an option to your bootloader. This will change from architecture to architecture. For x86, (as root), edit /boot/grub2/grub.cfg or /boot/efi/EFI/fedora/grub.cfg if you have EFI enabled and delete the four lines relating to your kernel (They should be easy to spot, they'll be the ones with your tag). They'll look something like this..<br />
<pre><br />
title Fedora Core (2.6.22-rc3-dave)<br />
root (hd0,0)<br />
kernel /vmlinuz-2.6.22-rc3-dave ro root=/dev/md0<br />
initrd /initrd-2.6.22-rc3-dave.img<br />
</pre></div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/Rawhide&diff=422325Kernel/Rawhide2015-09-16T13:32:04Z<p>Jwboyer: Created page with "= Rawhide = The following page will cover how we deal with the kernel in Rawhide. It's a mix of history, policy, and process. Essentially it can be summed up as: It moves ..."</p>
<hr />
<div>= Rawhide =<br />
<br />
The following page will cover how we deal with the kernel in Rawhide. It's a mix of history, policy, and process. Essentially it can be summed up as:<br />
<br />
It moves forward with upstream.<br />
<br />
== What and Why ==<br />
<br />
The Rawhide kernel is essentially the latest git snapshot of Linus' upstream kernel.org tree. On a frequent (often daily) basis, a new snapshot is built. We do this for a variety of reasons, but the main reason is that we are building and testing (via the rawhide repo) the same kernel that upstream is currently developing on. This keeps us current and hopefully catches issues before they make it into a stable Fedora release. Of course, we are limited to the usage of rawhide itself, but we have nothing better at the moment.<br />
<br />
==== Isn't it unstable? ====<br />
<br />
Yes. There are definitely bugs, some of which even prevent machines from booting at times. However, in terms of process and quality, the upstream kernel is actually pretty remarkable. Major issues a fairly rare. Usually we can get a fixed build out within a week after engaging with upstream in these cases, often much faster.<br />
<br />
==== "Policies" ====<br />
<br />
There are a few things we do with rawhide kernels that aren't done at all with the other releases. These aren't set in stone rules, but over the years we've found they tend to help things so we continue to do them.<br />
<br />
The first is that we leave debug options enabled. There's a whole page on this alone: https://fedoraproject.org/wiki/KernelDebugStrategy . However, as a somewhat nice gesture to our users, we turn them off with the first build of every major milestone. So 4.3-rc1, rc2, ... 4.3 final will all have debug options disabled. This brings back some performance. Other than that, debug options tend to stay on.<br />
<br />
The second is that at times Rawhide will carry patches aside from the normal bugfixes that are not in other branches. Rawhide is the experimentation area, so we are slightly more lenient of high value additions that are still working details out upstream. These cases are fairly rare, but they do happen. As of Sept 2015, the kdbus patchset is the only "rawhide only" patchset we are carrying.<br />
<br />
The last policy is around new driver enablement. This has varied over the years from "turn everything on" to "turn nothing on". Neither is really a great choice. Everything on leads to bloat, nothing on leads to no new hardware being supported. So we try and find a balance. Essentially, the breakdown looks like this:<br />
<br />
* Networking drivers and options are almost always enabled and set to =m<br />
* HID and input drivers are typically =m unless it seems like an obscure piece of hardware<br />
* ARM options are handled by the ARM team. The kernel team literally guesses for a first cut. If an option relates to a board/mach the ARM team has enabled, it tends to be enabled in the appropriate section. If not, it tends to be disabled.<br />
* GPIO/I2C/IIO drivers tend to be disabled by default. We somewhat rely on people asking for them to be enabled.<br />
** Of late, accel and ambient light drivers are of more interest.<br />
* New filesystems tend to be disabled. New options to existing filesystems tend to get enabled, but reviewing with the relevant FS teams is good.<br />
* USB is a mixed bag and decisions require reading what the option is actually for.<br />
<br />
When in doubt, disabled or =m are the safe choices.<br />
<br />
== How ==<br />
<br />
OK, so how does one roll out rawhide? It's pretty easy. Here is what you will need:<br />
<br />
* The pkg-git checkout (duh)<br />
* A clone of Linus' kernel tree. The master branch should track Linus' master branch and only that.<br />
* Time<br />
* Some kind of coping mechanism for all the options you will hit over and over during the merge window. Choice is up to you.<br />
<br />
The steps below assume you have your pkg-git checkout in ~/kernel and your git tree in ~/src/linux. Adjust as appropriate.<br />
<br />
==== git snapshot ====<br />
<br />
# Update both of your trees.<br />
##<code> cd ~/kernel/; git checkout master; git pull; pushd ~/src/linux; git checkout master; git remote update; git merge origin/master (or use git pull) ; pushd +1</code><br />
# If you're doing a new git snapshot, use the generate-git-snapshot script in pkg-git to create one.<br />
## <code>LINUX_GIT=~/src/linux ./scripts/generate-git-snapshot.sh</code><br />
##* LINUX_GIT is the env variable that points to the tree to generate the patch from. This is why it is important to keep your exploded tree updated and tracking Linus' master.<br />
##* That script will create a patch-<version>-git<N>.xz file in your local directory, and throw a changelog entry into kernel.spec.<br />
## Upload the file: <code> fedpkg upload patch-4.3-rc1-git1.xz</code><br />
##* Edit the sources file to make sure it only lists the files needed<br />
# Run a prep on the tree<br />
## <code> fedpkg prep </code><br />
##* You are highly likely to run into patches that don't apply any longer, etc. Fix this patches however you feel comfortable. Remember, the tree you're trying to apply them to now matches whatever is in ~/src/linux (which should be Linus' latest master branch).<br />
##* You are also highly likely to run into new config options once all the patches apply. Review these options and edit the appropriate config-* files to add them in.<br />
# Repeat step 3 until all patches apply and all config options are answered<br />
# Do a local build. Fix issues until it completes.<br />
## <code> fedpkg local </code><br />
##* Optionally, do a cross build of arm using <code>scripts/cross-arm</code><br />
# Once everything builds, test the local RPMs on a machine or something.<br />
# Commit, push, and build<br />
##<code> fedpkg commit -c; git push; fedpkg build --nowait; </code><br />
<br />
YAY FOR YOU!<br />
<br />
Ok, so some variations to the above.<br />
<br />
==== -rcX release ====<br />
<br />
If you need to do a build of an upstream -rc release, the steps are mostly the same. However, we don't generate those patches ourselves and use them upstream kernel.org patches. Step 2 above is replaced with:<br />
<br />
* Download the kernel.org -rc patch and upload it with e.g. <code>fedpkg upload patch-4.3-rc1.xz </code><br />
** Update <code>rcrev</code> and <code>gitrev</code> in kernel.spec to match the -rcX release and 0 respectively.<br />
** Disable debugging options by running <code>make release</code> and then fixup <code>baserelease</code> to 1 if necessary.<br />
<br />
Then follow the rest of the steps above. The next time you go to do a gitrev, make sure you reenable debug options with <code> make debug </code><br />
<br />
==== Final release ====<br />
<br />
When Linus cuts a final release, we do a few things different yet again. Step 2 is now replaced with:<br />
<br />
* Download the kernel.org linux-<version>.tar.xz tarball and upload it with e.g.<br />
** <code> fedpkg upload linux-4.3.tar.xz </code><br />
* In kernel.spec edit:<br />
** <code> released_kernel </code> to 1<br />
** <code> rcrev </code> to 0<br />
** <code> gitrev </code> to 0<br />
* Generate the perf-man tarball<br />
** <code> pushd ~/src/linux/; cd tools/perf/Documenation; make </code> (remember, your git tree should be always tracking Linus' so your master branch should be at the cut final release tag.<br />
** <code> tar -czvf ~/kernel/perf-man-4.3.tar.gz *.1 ; make clean </code><br />
** <code> fedpkg upload perf-man-4.3.tar.gz </code><br />
* Disable debugging options by running <code>make release</code> and then fixup <code>baserelease</code> to 1 if necessary.<br />
<br />
Then follow the rest of the steps above. With the opening of the next merge window, make sure you reenable debug options and set <code>released_kernel</code> to 0.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=User:Jwboyer&diff=421143User:Jwboyer2015-08-28T13:29:07Z<p>Jwboyer: /* Contact */</p>
<hr />
<div>= Josh Boyer =<br />
<br />
== Contact ==<br />
<br />
* '''Email''': jwboyer AT fedoraproject DOT org<br />
* '''IRC''': jwb, #fedora-devel, #fedora-kernel, #fedora-<lots of other places><br />
* '''GPG key''': <br />
* '''Fedora Account''': jwboyer</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Development/SteeringCommittee/Nominations&diff=414840Development/SteeringCommittee/Nominations2015-06-04T13:02:10Z<p>Jwboyer: /* Candidate Nominations */</p>
<hr />
<div><!--{{admon/important|The nomination period is CLOSED|The nomination period ended at 23:59:59 UTC on July 7, 2014.}}--><br />
<!--{{admon/important|The nomination period has not yet begun. Please wait for the elections announcement}}--><br />
{{admon/important|We're OPEN!|The nomination period is in progress! Please add your nomination before 23:59:59 UTC on June 14, 2015! }}<br />
<!--{{admon/tip | VOTE FOR YOUR FAVORITE CANDIDATES. | Fedora contributors can elect FESCo at https://admin.fedoraproject.org/voting/about/fesco-december2012.--><br />
<!--<br />DEADLINE: Dec. 9, 23:59:59 UTC}}--><br />
<br />
The following [[Elections|elections]] will take place in June 2015:<br />
<br />
* [[Development/SteeringCommittee/Nominations|FESCo (Engineering)]] (four seats)<br />
<br />
All dates and times noted are UTC time.<br />
<br />
= FESCo Elections June 2015 =<br />
As per the [[FESCo_election_policy|FESCo election policy]], the following finish their terms, and the seats are up for re-election:<br />
<br />
* [[User:Jwboyer| Josh Boyer]] (jwb) - elected for F21/F22 period<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore) - elected for F21/F22 period<br />
* [[User:Mitr| Miloslav Trmač]] (mitr) - elected for F21/F22 period<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh) - elected for F21/F22 period<br />
<br />
More information at the FESCo [[Fedora_Engineering_Steering_Committee|wiki page]].<br />
<br />
<!--{{admon/important|The nomination period is CLOSED. The nomination period ended at 23:59:59 UTC on May 15, 2012.}}--><br />
For the last election, see [https://fedoraproject.org/w/index.php?title=Development/SteeringCommittee/Nominations&oldid=402654 Nominations January 2015]<br />
<br />
{{admon/note|Eligible Voters|Voting eligibility is determined by a community member's Fedora Account System ([https://admin.fedoraproject.org/accounts/ FAS]) memberships.<br/> <br/>To vote for [[Fedora_Engineering_Steering_Committee|FESCo]] you must have cla_done + one other "non-cla" group in FAS.}}<br />
<br />
== Candidate Nominations ==<br />
Please nominate just by Name, IRC nick and FAS account ID. The introduction will be published in Fedora Magazine, at the end of the "Campaign" period.<br />
<br />
* NAME (IRC nick/FAS account ID)<br />
* Stephen Gallagher<br />
** IRC Nick: sgallagh<br />
** FAS: [[User:Sgallagh|sgallagh]]<br />
* Haïkel Guémar<br />
** IRC Nick: number80<br />
** FAS: [[User:Hguemar|hguemar]]<br />
* David King<br />
** IRC Nick: amigadave<br />
** FAS: [[User:Amigadave|amigadave]]<br />
* Josh Boyer<br />
** IRC Nick: jwb<br />
** FAS: [[User:jwboyer|jwboyer]]<br />
[[Category:FESCo]]</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/DayToDay&diff=411639Kernel/DayToDay2015-04-30T19:33:24Z<p>Jwboyer: /* Push a change */</p>
<hr />
<div>The ever exciting day to day tasks that make the Fedora kernel run<br />
<br />
= Getting started =<br />
If you are new to maintaining the fedora kernel, you will need to make sure the following are set up<br />
* Get a [https://admin.fedoraproject.org/accounts/ Fedora Account]<br />
* Create a [http://bugzilla.redhat.com/ Bugzilla Account]<br />
* Ask one of the existing Fedora kernel developers to add you to the appropriate permissions list (TODO: Document what these lists are)<br />
* <code> $ fedora-packager-setup </code> to generate a fedora cert<br />
<br />
= Getting the Fedora kernel sources =<br />
<br />
<code> $ fedpkg clone kernel </code><br />
<br />
If you haven't gotten the appropriate permissions yet, you can clone anonymously<br />
<br />
<code> $ fedpkg clone -a kernel </code><br />
<br />
= Add a new patch to the kernel =<br />
<br />
See [[Kernel/Spec#Individual_patches | this page]] for details about adding individual patches to the spec file. You also need to make sure you [[Kernel/Spec#Actually_applying_individual_patches | actually apply the patches]]. <br />
<br />
Test it with <br />
<br />
<code> $ fedpkg -v prep </code><br />
<br />
to make sure it applies okay. You probably want to make sure it builds as well:<br />
<br />
<code> $ fedpkg local </code><br />
<br />
When you are finished, you can do<br />
<br />
<code> $ rpmdev-bumpspec -c "Fixed that bug (rhbz 123456)" kernel.spec </code><br />
<br />
to update the kernel.spec. <br />
<br />
= Push a change =<br />
<br />
Make sure you add any new files (new patches you are bringing in for the first time etc.)<br />
<br />
<code> $ git add fix-this.patch </code><br />
<code> $ git add fix-that.patch </code><br />
<br />
Commit the result with git commit or fedpkg:<br />
<br />
<code> $ fedpkg commit -m "Fixed that bug (rhbz 123456)" </code><br />
<br />
Once you've made sure the commit is how you want, you can push<br />
<br />
<code> $ git push origin HEAD:<branch name> </code><br />
<br />
If you checked out the source anonymously, you will need to change $PROJECT_DIR/.git/config to use ssh:// instead of git:// e.g.<br />
<br />
<pre><br />
[remote "origin"]<br />
url = git://pkgs.fedoraproject.org/kernel<br />
fetch = +refs/heads/*:refs/remotes/origin/*<br />
</pre><br />
<br />
Change the git:// to ssh://<br />
<br />
Once that is finished, you can do a scratch build<br />
<br />
<code> $ fedpkg build --scratch </code><br />
<br />
= Stable kernel update =<br />
<br />
For going from 4.x.y -> 4.x.z<br />
<br />
Download the patch from kernel.org (not the incremental version)<br />
<br />
Remove the last patch from the sources file e.g.<br />
<br />
<pre><br />
--- a/sources<br />
+++ b/sources<br />
@@ -1,3 +1,3 @@<br />
d3fc8316d4d4d04b65cbc2d70799e763 linux-3.19.tar.xz<br />
15d8d2f97ce056488451a5bfb2944603 perf-man-3.19.tar.gz<br />
-f0f457204a1b286cc2ff04e470b01d64 patch-3.19.5.xz<br />
</pre><br />
<br />
Use fedpkg to upload the patch file to the cache<br />
<br />
<code> $ fedpkg upload patch-x.y.z </code><br />
<br />
fedpkg has now updated the sources file for you in git.<br />
<br />
You can now run<br />
<br />
<code> $ fedpkg prep </code><br />
<br />
to grab the code and apply patches. You will probably find conflicts and patches that no longer apply. Remove them from the .spec file. Repeat until success.<br />
<br />
You can now commit and push like any other commit</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/FY16_Goals&diff=411028Kernel/FY16 Goals2015-04-27T19:30:32Z<p>Jwboyer: /* Work Items */</p>
<hr />
<div>Overall department goals<br />
<br />
* Modernizing release process and deliverables<br />
* Create and improve systems, resources, and upstream efforts that benefit general users, and help draw power users into contribution<br />
* Improve/maintain systems/resources for existing contributors<br />
<br />
=== Team High Level Goals ===<br />
<br />
* Plan for and deliver high quality kernel for upcoming Fedora releases<br />
<br />
* Improve team efficiency and community collaboration<br />
<br />
* Increase participation in upstream kernel community<br />
<br />
=== Goals ===<br />
<br />
Specific action items will be derived from these goals.<br />
<br />
{|<br />
! Description !! Category !! Lead Person !! Target<br />
|-<br />
| '''Retrace kernel issue reduction.''' The retrace server provides a view of the issues that are hitting the broadest subset of Fedora users. We'll use this data to focus our efforts on improving the kernel. || Quality/Upstream || || <br />
|-<br />
| '''Improve kernel task automation.''' A number of common tasks could be automated. We'll investigate which tasks can leverage tools like fedmsg and fmn. This can range from automated nodebug and kernel-playground repos, to a more automated process for creating the actual kernel package.|| Efficiency/Automation || ||<br />
|-<br />
| '''Increase upstream kernel reviews and bugfixes.''' Upstream is continually looking for additional patch reviews. By increasing our participation there we can help avoid bugs. We'll also use this to increase our team's overall knowledge by gaining a deeper understanding of various focus areas within the kernel. || Upstream || ||<br />
|-<br />
| '''Publish various communications about the Fedora kernel.''' The kernel is often a hot topic in various communities. We'll look at continuing the upstream Fedora patch reports, and possibly writing articles for Fedora Magazine. || Collaboration || ||<br />
|-<br />
| '''Kernel test system''' - what's next || Quality/Upstream || [[User:Jforbes | Justin Forbes]] ||<br />
|}<br />
<br />
==== Work Items ====<br />
{|<br />
! Description !! Lead Person !! Target<br />
|-<br />
| Investigate pkg-git creation from exploded git tree || jwb || Q2<br />
|-<br />
| Automated nodebug builds || jforbes || Q2<br />
|-<br />
| Kernel updates in Atomic world || jwb || Q2/Q3<br />
|-<br />
| Linux-next automated testing || jforbes || <br />
|-<br />
| Update/create community focused kernel documentation/wiki || labbott || Q1/Q2<br />
|-<br />
| Focus on retrace issues and signal/noise reduction || labbott || Q1/Q2<br />
|-<br />
| Subsystem focus areas || All || FY<br />
|-<br />
| Upstream patch reviews and bugfixes || All || FY<br />
|-<br />
| Blog/magazine postings on kernel topics || All || FY<br />
|-<br />
| Release maintenance || All || FY<br />
|-<br />
|}<br />
<br />
----<br />
<br />
Problems<br />
<br />
* Retrace is flooded with kernel reports (so is bugzilla but this is always the case)<br />
<br />
* Our team's participation in the upstream kernel community has dwindled<br />
** This means we're considered outsiders more than members<br />
** Decreased visibility can lead to decreased responsiveness from upstream<br />
<br />
* The team's integration within the distro is fairly minimal<br />
** Good and bad<br />
*** Good: We aren't holding anything up. The kernel ships on time and is fairly high quality overall<br />
*** Not so good:<br />
**** We don't necessarily improve the overall release<br />
**** We don't ask for and discuss needs/problems other teams are having (e.g. Desktop)<br />
<br />
* Interaction with Red Hat stakeholders is minimal<br />
** Normally doesn't impact us day to day, but we could help for future items<br />
<br />
* Team efficiency and community participation is pretty stagnant.<br />
** Mostly because we haven't had a full team for a while. Let's figure this out.<br />
** Community members have little insight into how or why we do what we do beyond the wiki pages. Can we make it easier for them to participate?</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/FY16_Goals&diff=410795Kernel/FY16 Goals2015-04-23T18:10:36Z<p>Jwboyer: /* Work Items */</p>
<hr />
<div>Overall department goals<br />
<br />
* Modernizing release process and deliverables<br />
* Create and improve systems, resources, and upstream efforts that benefit general users, and help draw power users into contribution<br />
* Improve/maintain systems/resources for existing contributors<br />
<br />
=== Team High Level Goals ===<br />
<br />
* Plan for and deliver high quality kernel for upcoming Fedora releases<br />
<br />
* Improve team efficiency and community collaboration<br />
<br />
* Increase participation in upstream kernel community<br />
<br />
=== Goals ===<br />
<br />
Specific action items will be derived from these goals.<br />
<br />
{|<br />
! Description !! Category !! Lead Person !! Target<br />
|-<br />
| '''Retrace kernel issue reduction.''' The retrace server provides a view of the issues that are hitting the broadest subset of Fedora users. We'll use this data to focus our efforts on improving the kernel. || Quality/Upstream || || <br />
|-<br />
| '''Improve kernel task automation.''' A number of common tasks could be automated. We'll investigate which tasks can leverage tools like fedmsg and fmn. This can range from automated nodebug and kernel-playground repos, to a more automated process for creating the actual kernel package.|| Efficiency/Automation || ||<br />
|-<br />
| '''Increase upstream kernel reviews and bugfixes.''' Upstream is continually looking for additional patch reviews. By increasing our participation there we can help avoid bugs. We'll also use this to increase our team's overall knowledge by gaining a deeper understanding of various focus areas within the kernel. || Upstream || ||<br />
|-<br />
| '''Publish various communications about the Fedora kernel.''' The kernel is often a hot topic in various communities. We'll look at continuing the upstream Fedora patch reports, and possibly writing articles for Fedora Magazine. || Collaboration || ||<br />
|-<br />
| '''Kernel test system''' - what's next || Quality/Upstream || [[User:Jforbes | Justin Forbes]] ||<br />
|}<br />
<br />
==== Work Items ====<br />
{|<br />
! Description !! Lead Person !! Target<br />
|-<br />
| Investigate pkg-git creation from exploded git tree || jwb || Q2<br />
|-<br />
| Automated nodebug builds || jforbes || Q2<br />
|-<br />
| Kernel updates in Atomic world || jwb || Q2/Q3<br />
|-<br />
| Linux-next automated testing || jforbes || <br />
|-<br />
| Update/create community focused kernel documentation/wiki || labbott || Q1/Q2<br />
|-<br />
| Subsystem focus areas || All || FY<br />
|-<br />
| Upstream patch reviews and bugfixes || All || FY<br />
|-<br />
| Blog/magazine postings on kernel topics || All || FY<br />
|-<br />
| Release maintenance || All || FY<br />
|-<br />
|}<br />
<br />
----<br />
<br />
Problems<br />
<br />
* Retrace is flooded with kernel reports (so is bugzilla but this is always the case)<br />
<br />
* Our team's participation in the upstream kernel community has dwindled<br />
** This means we're considered outsiders more than members<br />
** Decreased visibility can lead to decreased responsiveness from upstream<br />
<br />
* The team's integration within the distro is fairly minimal<br />
** Good and bad<br />
*** Good: We aren't holding anything up. The kernel ships on time and is fairly high quality overall<br />
*** Not so good:<br />
**** We don't necessarily improve the overall release<br />
**** We don't ask for and discuss needs/problems other teams are having (e.g. Desktop)<br />
<br />
* Interaction with Red Hat stakeholders is minimal<br />
** Normally doesn't impact us day to day, but we could help for future items<br />
<br />
* Team efficiency and community participation is pretty stagnant.<br />
** Mostly because we haven't had a full team for a while. Let's figure this out.<br />
** Community members have little insight into how or why we do what we do beyond the wiki pages. Can we make it easier for them to participate?</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/FY16_Goals&diff=410794Kernel/FY16 Goals2015-04-23T18:09:53Z<p>Jwboyer: /* Goals */</p>
<hr />
<div>Overall department goals<br />
<br />
* Modernizing release process and deliverables<br />
* Create and improve systems, resources, and upstream efforts that benefit general users, and help draw power users into contribution<br />
* Improve/maintain systems/resources for existing contributors<br />
<br />
=== Team High Level Goals ===<br />
<br />
* Plan for and deliver high quality kernel for upcoming Fedora releases<br />
<br />
* Improve team efficiency and community collaboration<br />
<br />
* Increase participation in upstream kernel community<br />
<br />
=== Goals ===<br />
<br />
Specific action items will be derived from these goals.<br />
<br />
{|<br />
! Description !! Category !! Lead Person !! Target<br />
|-<br />
| '''Retrace kernel issue reduction.''' The retrace server provides a view of the issues that are hitting the broadest subset of Fedora users. We'll use this data to focus our efforts on improving the kernel. || Quality/Upstream || || <br />
|-<br />
| '''Improve kernel task automation.''' A number of common tasks could be automated. We'll investigate which tasks can leverage tools like fedmsg and fmn. This can range from automated nodebug and kernel-playground repos, to a more automated process for creating the actual kernel package.|| Efficiency/Automation || ||<br />
|-<br />
| '''Increase upstream kernel reviews and bugfixes.''' Upstream is continually looking for additional patch reviews. By increasing our participation there we can help avoid bugs. We'll also use this to increase our team's overall knowledge by gaining a deeper understanding of various focus areas within the kernel. || Upstream || ||<br />
|-<br />
| '''Publish various communications about the Fedora kernel.''' The kernel is often a hot topic in various communities. We'll look at continuing the upstream Fedora patch reports, and possibly writing articles for Fedora Magazine. || Collaboration || ||<br />
|-<br />
| '''Kernel test system''' - what's next || Quality/Upstream || [[User:Jforbes | Justin Forbes]] ||<br />
|}<br />
<br />
==== Work Items ====<br />
{|<br />
! Description !! Lead Person !! Target<br />
|-<br />
| Investigate pkg-git creation from exploded git tree || jwb || Q2<br />
|-<br />
| Automated nodebug builds || jforbes || Q2<br />
|-<br />
| Kernel updates in Atomic world || jwb || Q2/Q3<br />
|-<br />
| Linux-next automated testing || jforbes || <br />
|-<br />
| Update/create community focused kernel documentation/wiki || labbott || Q1/Q2<br />
|-<br />
| Subsystem focus areas || All || FY<br />
|-<br />
| Blog/magazine postings on kernel topics || All || FY<br />
|-<br />
| Release maintenance || All || FY<br />
|-<br />
|}<br />
<br />
----<br />
<br />
Problems<br />
<br />
* Retrace is flooded with kernel reports (so is bugzilla but this is always the case)<br />
<br />
* Our team's participation in the upstream kernel community has dwindled<br />
** This means we're considered outsiders more than members<br />
** Decreased visibility can lead to decreased responsiveness from upstream<br />
<br />
* The team's integration within the distro is fairly minimal<br />
** Good and bad<br />
*** Good: We aren't holding anything up. The kernel ships on time and is fairly high quality overall<br />
*** Not so good:<br />
**** We don't necessarily improve the overall release<br />
**** We don't ask for and discuss needs/problems other teams are having (e.g. Desktop)<br />
<br />
* Interaction with Red Hat stakeholders is minimal<br />
** Normally doesn't impact us day to day, but we could help for future items<br />
<br />
* Team efficiency and community participation is pretty stagnant.<br />
** Mostly because we haven't had a full team for a while. Let's figure this out.<br />
** Community members have little insight into how or why we do what we do beyond the wiki pages. Can we make it easier for them to participate?</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/FY16_Goals&diff=410737Kernel/FY16 Goals2015-04-22T20:15:34Z<p>Jwboyer: soften up the problems a little bit</p>
<hr />
<div>Overall department goals<br />
<br />
* Modernizing release process and deliverables<br />
* Create and improve systems, resources, and upstream efforts that benefit general users, and help draw power users into contribution<br />
* Improve/maintain systems/resources for existing contributors<br />
<br />
=== Team High Level Goals ===<br />
<br />
* Plan for and deliver high quality kernel for upcoming Fedora releases<br />
<br />
* Improve team efficiency and community collaboration<br />
<br />
* Increase participation in upstream kernel community<br />
<br />
=== Goals ===<br />
<br />
Specific action items will be derived from these goals.<br />
<br />
{|<br />
! Description !! Category !! Lead Person !! Target<br />
|-<br />
| '''Retrace kernel issue reduction.''' The retrace server provides a view of the issues that are hitting the broadest subset of Fedora users. We'll use this data to focus our efforts on improving the kernel. || Quality/Upstream || || <br />
|-<br />
| '''Improve kernel task automation.''' A number of common tasks could be automated. We'll investigate which tasks can leverage tools like fedmsg and fmn. This can range from automated nodebug and kernel-playground repos, to a more automated process for creating the actual kernel package.|| Efficiency/Automation || ||<br />
|-<br />
| '''Increase upstream kernel reviews and bugfixes.''' Upstream is continually looking for additional patch reviews. By increasing our participation there we can help avoid bugs. We'll also use this to increase our team's overall knowledge by gaining a deeper understanding of various focus areas within the kernel. || Upstream || ||<br />
|-<br />
| '''Publish various communications about the Fedora kernel.''' The kernel is often a hot topic in various communities. We'll look at continuing the upstream Fedora patch reports, and possibly writing articles for Fedora Magazine. || Collaboration || ||<br />
|-<br />
| '''Kernel test system''' - what's next || Quality/Upstream || [[User:Jforbes | Justin Forbes]] ||<br />
|}<br />
<br />
<br />
----<br />
<br />
Problems<br />
<br />
* Retrace is flooded with kernel reports (so is bugzilla but this is always the case)<br />
<br />
* Our team's participation in the upstream kernel community has dwindled<br />
** This means we're considered outsiders more than members<br />
** Decreased visibility can lead to decreased responsiveness from upstream<br />
<br />
* The team's integration within the distro is fairly minimal<br />
** Good and bad<br />
*** Good: We aren't holding anything up. The kernel ships on time and is fairly high quality overall<br />
*** Not so good:<br />
**** We don't necessarily improve the overall release<br />
**** We don't ask for and discuss needs/problems other teams are having (e.g. Desktop)<br />
<br />
* Interaction with Red Hat stakeholders is minimal<br />
** Normally doesn't impact us day to day, but we could help for future items<br />
<br />
* Team efficiency and community participation is pretty stagnant.<br />
** Mostly because we haven't had a full team for a while. Let's figure this out.<br />
** Community members have little insight into how or why we do what we do beyond the wiki pages. Can we make it easier for them to participate?</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/FY16_Goals&diff=410736Kernel/FY16 Goals2015-04-22T20:13:05Z<p>Jwboyer: /* Goals */</p>
<hr />
<div>Overall department goals<br />
<br />
* Modernizing release process and deliverables<br />
* Create and improve systems, resources, and upstream efforts that benefit general users, and help draw power users into contribution<br />
* Improve/maintain systems/resources for existing contributors<br />
<br />
=== Team High Level Goals ===<br />
<br />
* Plan for and deliver high quality kernel for upcoming Fedora releases<br />
<br />
* Improve team efficiency and community collaboration<br />
<br />
* Increase participation in upstream kernel community<br />
<br />
=== Goals ===<br />
<br />
Specific action items will be derived from these goals.<br />
<br />
{|<br />
! Description !! Category !! Lead Person !! Target<br />
|-<br />
| '''Retrace kernel issue reduction.''' The retrace server provides a view of the issues that are hitting the broadest subset of Fedora users. We'll use this data to focus our efforts on improving the kernel. || Quality/Upstream || || <br />
|-<br />
| '''Improve kernel task automation.''' A number of common tasks could be automated. We'll investigate which tasks can leverage tools like fedmsg and fmn. This can range from automated nodebug and kernel-playground repos, to a more automated process for creating the actual kernel package.|| Efficiency/Automation || ||<br />
|-<br />
| '''Increase upstream kernel reviews and bugfixes.''' Upstream is continually looking for additional patch reviews. By increasing our participation there we can help avoid bugs. We'll also use this to increase our team's overall knowledge by gaining a deeper understanding of various focus areas within the kernel. || Upstream || ||<br />
|-<br />
| '''Publish various communications about the Fedora kernel.''' The kernel is often a hot topic in various communities. We'll look at continuing the upstream Fedora patch reports, and possibly writing articles for Fedora Magazine. || Collaboration || ||<br />
|-<br />
| '''Kernel test system''' - what's next || Quality/Upstream || [[User:Jforbes | Justin Forbes]] ||<br />
|}<br />
<br />
<br />
----<br />
<br />
Problems<br />
<br />
* Retrace is flooded with kernel reports (so is bugzilla but this is always the case)<br />
<br />
* Our team's participation in the upstream kernel community has dwindled significantly<br />
** This means we're considered outsiders more than members<br />
** Decreased visibility can lead to decreased responsiveness from upstream<br />
<br />
* The team's integration within the distro is fairly minimal<br />
** Good and bad<br />
*** Good: We aren't holding anything up. The kernel ships on time and is fairly high quality overall<br />
*** Not so good:<br />
**** We don't necessarily improve the overall release<br />
**** We don't ask for and discuss needs/problems other teams are having (e.g. Desktop)<br />
<br />
* Interaction with Red Hat stakeholders is minimal<br />
** Normally doesn't impact us day to day, but we could help for future items<br />
<br />
* Team efficiency and community participation doesn't exist<br />
** Mostly because we haven't had a full team for a while. Let's figure this out.<br />
** Community members have little insight into how or why we do what we do beyond the wiki pages. Can we make it easier for them to participate?</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/FY16_Goals&diff=410735Kernel/FY16 Goals2015-04-22T19:57:29Z<p>Jwboyer: </p>
<hr />
<div>Overall department goals<br />
<br />
* Modernizing release process and deliverables<br />
* Create and improve systems, resources, and upstream efforts that benefit general users, and help draw power users into contribution<br />
* Improve/maintain systems/resources for existing contributors<br />
<br />
=== Team High Level Goals ===<br />
<br />
* Plan for and deliver high quality kernel for upcoming Fedora releases<br />
<br />
* Improve team efficiency and community collaboration<br />
<br />
* Increase participation in upstream kernel community<br />
<br />
=== Goals ===<br />
<br />
{|<br />
! Description !! Category !! Lead Person !! Target<br />
|-<br />
| Retrace kernel issue reduction || Quality/Upstream || FY || <br />
|-<br />
| Improve kernel task automation || Efficiency/Automation || ||<br />
|-<br />
| Increase upstream kernel reviews and bugfixes || Upstream || ||<br />
|-<br />
| Contribute kernel specific content to Fedora Magazine articles || Collaboration || ||<br />
|-<br />
| Kernel test system - what's next || Quality/Upstream || [[User:Jforbes | Justin Forbes]] ||<br />
|}<br />
<br />
<br />
----<br />
<br />
Problems<br />
<br />
* Retrace is flooded with kernel reports (so is bugzilla but this is always the case)<br />
<br />
* Our team's participation in the upstream kernel community has dwindled significantly<br />
** This means we're considered outsiders more than members<br />
** Decreased visibility can lead to decreased responsiveness from upstream<br />
<br />
* The team's integration within the distro is fairly minimal<br />
** Good and bad<br />
*** Good: We aren't holding anything up. The kernel ships on time and is fairly high quality overall<br />
*** Not so good:<br />
**** We don't necessarily improve the overall release<br />
**** We don't ask for and discuss needs/problems other teams are having (e.g. Desktop)<br />
<br />
* Interaction with Red Hat stakeholders is minimal<br />
** Normally doesn't impact us day to day, but we could help for future items<br />
<br />
* Team efficiency and community participation doesn't exist<br />
** Mostly because we haven't had a full team for a while. Let's figure this out.<br />
** Community members have little insight into how or why we do what we do beyond the wiki pages. Can we make it easier for them to participate?</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/FY16_Goals&diff=410734Kernel/FY16 Goals2015-04-22T19:47:34Z<p>Jwboyer: </p>
<hr />
<div>Overall department goals<br />
<br />
* Modernizing release process and deliverables<br />
* Create and improve systems, resources, and upstream efforts that benefit general users, and help draw power users into contribution<br />
* Improve/maintain systems/resources for existing contributors<br />
<br />
Problems<br />
<br />
* Retrace is flooded with kernel reports (so is bugzilla but this is always the case)<br />
<br />
* Our team's participation in the upstream kernel community has dwindled significantly<br />
** This means we're considered outsiders more than members<br />
** Decreased visibility can lead to decreased responsiveness from upstream<br />
<br />
* The team's integration within the distro is fairly minimal<br />
** Good and bad<br />
*** Good: We aren't holding anything up. The kernel ships on time and is fairly high quality overall<br />
*** Not so good:<br />
**** We don't necessarily improve the overall release<br />
**** We don't ask for and discuss needs/problems other teams are having (e.g. Desktop)<br />
<br />
* Interaction with Red Hat stakeholders is minimal<br />
** Normally doesn't impact us day to day, but we could help for future items<br />
<br />
* Team efficiency and community participation doesn't exist<br />
** Mostly because we haven't had a full team for a while. Let's figure this out.<br />
** Community members have little insight into how or why we do what we do beyond the wiki pages. Can we make it easier for them to participate?<br />
<br />
Team High Level Goals<br />
<br />
* Plan for and deliver high quality kernel for upcoming Fedora releases<br />
<br />
* Improve team efficiency and community collaboration<br />
<br />
* Increase participation in upstream kernel community<br />
<br />
Goals<br />
<br />
{|<br />
! Description !! Lead Person !! Target<br />
|-<br />
| Retrace kernel issue reduction || ||<br />
|-<br />
| Improve kernel task automation || ||<br />
|-<br />
| Increase upstream kernel reviews and bugfixes || ||<br />
|-<br />
| Contribute kernel specific content to Fedora Magazine articles || ||<br />
|-<br />
| Kernel test system - what's next || [[User:Jforbes | Justin Forbes]] ||<br />
|}</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/FY16_Goals&diff=410726Kernel/FY16 Goals2015-04-22T16:05:49Z<p>Jwboyer: </p>
<hr />
<div>Overall department goals<br />
<br />
* Modernizing release process and deliverables<br />
* Create and improve systems, resources, and upstream efforts that benefit general users, and help draw power users into contribution<br />
* Improve/maintain systems/resources for existing contributors<br />
<br />
Problems<br />
<br />
* Retrace is flooded with kernel reports (so is bugzilla but this is always the case)<br />
<br />
* Our team's participation in the upstream kernel community has dwindled significantly<br />
** This means we're considered outsiders more than members<br />
** Decreased visibility can lead to decreased responsiveness from upstream<br />
<br />
* The team's integration within the distro is fairly minimal<br />
** Good and bad<br />
*** Good: We aren't holding anything up. The kernel ships on time and is fairly high quality overall<br />
*** Not so good:<br />
**** We don't necessarily improve the overall release<br />
**** We don't ask for and discuss needs/problems other teams are having (e.g. Desktop)<br />
<br />
* Interaction with Red Hat stakeholders is minimal<br />
** Normally doesn't impact us day to day, but we could help for future items<br />
<br />
* Team efficiency and community participation doesn't exist<br />
** Mostly because we haven't had a full team for a while. Let's figure this out.<br />
** Community members have little insight into how or why we do what we do beyond the wiki pages. Can we make it easier for them to participate?<br />
<br />
Team High Level Goals<br />
<br />
* Plan for and deliver high quality kernel for upcoming Fedora releases<br />
<br />
* Improve team efficiency and community collaboration<br />
<br />
* Increase participation in upstream kernel</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/FY16_Goals&diff=410724Kernel/FY16 Goals2015-04-22T15:30:42Z<p>Jwboyer: Created page with "Overall department goals * Modernizing release process and deliverables * Create and improve systems, resources, and upstream efforts that benefit general users, and help dra..."</p>
<hr />
<div>Overall department goals<br />
<br />
* Modernizing release process and deliverables<br />
* Create and improve systems, resources, and upstream efforts that benefit general users, and help draw power users into contribution<br />
* Improve/maintain systems/resources for existing contributors<br />
<br />
Team High Level Goals<br />
<br />
* Plan for and deliver high quality kernel for upcoming Fedora releases<br />
<br />
* Improve team efficiency and community collaboration<br />
<br />
* Increase participation in upstream kernel</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/Spec&diff=409869Kernel/Spec2015-04-14T17:57:45Z<p>Jwboyer: </p>
<hr />
<div>= The Fedora kernel.spec =<br />
<br />
Like all RPMs, the Fedora kernel starts with a spec file and a set of tarballs and patches. This page will describe some of the sections of the kernel.spec file, what they're used for, and how to modify them.<br />
<br />
=== Macros ===<br />
<br />
There are a few important macros that we modify often. These are listed below.<br />
<br />
<code>%global released_kernel </code><br />
<br />
The released_kernel macro controls whether the rest of the macros and functions are dealing with an upstream released final kernel version. In the stable Fedora branches, this should almost always be set to 1. This will tell the other macros to use the final tarball (e.g. linux-4.0.tar.xz) and base_sublevel as the basis for the version numbers. In rawhide, released_kernel will often be set to 0 as we often ship pre-release git snapshots and -rcX kernels. Having it set to 0 will cause the proper versioning to happen for these non-released kernels.<br />
<br />
<code>%define base_sublevel</code><br />
<br />
The base_sublevel macro sets up the portion of the versioning after the major version number. E.g. base_sublevel of 0 will be 4.0. If it is set to 1, the versioning will be 1. Note, it is a reflection of the actual tarball we are building on top of, so if released_kernel is 0, base_sublevel will still be using the previous version. E.g. 4.1-rc1.git1 starts with the 4.0 tarball, so base_sublevel should be 0.<br />
<br />
<code>%define stable_update</code><br />
<br />
The stable_update macro controls the .y portion of the versioning and is responsible for applying the upstream stable release patches. If it is set to 0, no stable patch will be applied. If it is set to another number, it will apply that .y version number on top of the base_sublevel tarball. E.g. stable_update 2 and base_sublevel 0 would apply patch-4.0.2.xz on top of linux-4.0.tar.xz. This macro is only in use when released_kernel is 1.<br />
<br />
<code>%define rcrev</code><br />
<br />
When released_kernel is 0, we are building RC or merge window kernels. The rcrev macro contains the numeric value of the upstream RC release for the kernel we are targetting. Merge window kernels will have an rcrev of 0. All other -rcX releases will match their upstream release, e.g. 4.1-rc2 would have an rcrev value of 2. This macro is not used when released_kernel is 1.<br />
<br />
<code>%define gitrev</code><br />
<br />
When we build a git snapshot kernel, the gitrev macro contains the value of the git snapshot patch to apply. E.g. 4.1-rc2-git3 would have a gitrev value of 3. This will cause the spec to apply patch-4.1-rc2-git3.xz on top of linux-4.0.xz+patch-4.1-rc2.xz. This is not used when released_kernel is 0.<br />
<br />
Note: We have a script that generated the git snapshot patches and will modify this value in the spec accordingly. Manual modification of this macro does not happen often.<br />
<br />
<code>%global baserelease</code><br />
<br />
The baserelease macro controls the final number in the RPM Release field. E.g a 4.0.0-1.fc23 kernel has a baserelease value of 1. 4.1.0-0.rc2.git1.3.fc23 has a baserelease value of 3. This macro is the most often edited macro we have and should be modified for every commit we do. When we rebase to a new kernel, we reset it back to the value appropriate for that branch. To help with upgrade paths, each Fedora branch has a different starting value for baserelease. These are listed below.<br />
<br />
* rawhide/Branched: Starts at 1 and increments from there.<br />
* Most recent stable release N: Starts at 300 and increments from there<br />
* N-1 release: Starts at 200 and increments from there<br />
* N-2 release: Starts at 100 and increments from there<br />
<br />
This way, the oldest release always has the "oldest" Name-Version-Release combination for that upstream kernel release.<br />
<br />
There are other macros that control some other things, however we'll skip those for now and focus on the main macros used for build output.<br />
<br />
=== Sources ===<br />
===== Tarballs and large patch files =====<br />
The sources file lists the tarballs and large patch files that we used to explode the kernel sources. It will contain the file name and a hash value for that file. The contents will look similar to:<br />
<br />
<pre><br />
a86916bd12798220da9eb4a1eec3616d linux-4.0.tar.xz<br />
d125eecce68ab6fb5f1f23523c2c04b8 perf-man-4.0.tar.gz<br />
</pre><br />
<br />
The perf-man tarball is a self created tarball of the perf man pages. This is generated once per upstream kernel release. As -rcX patches are released and git snapshots are generated, we also add those via the sources file. This is done with the <code>fedpkg upload 'filename'</code> command.<br />
<br />
===== Individual patches =====<br />
<br />
Individual patches are listed in the kernel.spec file in the standalone patches section. These are typically used for bugfixes, however we have a handful of patches we carry for various addons or features. Patches must have a strip level of 1.<br />
<br />
Typically, a new patch is added by searching for the <code># END OF PATCH DEFINITIONS</code> string and adding a new entry above it such as:<br />
<br />
<pre><br />
#rhbz 1196825<br />
Patch26140: security-yama-Remove-unnecessary-selects-from-Kconfi.patch<br />
</pre><br />
<br />
Here we list the Red Hat bugzilla number as a comment above the PatchXXXXX: 'filename' listing. The only stipulation here is that the XXXXX number has to be unique in the spec file. Normally we just increment from the file above it. For security fixes, we tend to use this format:<br />
<br />
<pre><br />
#CVE-2015-2150 rhbz 1196266 1200397<br />
Patch26175: xen-pciback-Don-t-disable-PCI_COMMAND-on-PCI-device-.patch<br />
</pre><br />
<br />
which lists the CVE number, and the two associated Bugzilla numbers (the overall CVE tracking bug, and the Fedora specific instance).<br />
<br />
===== Actually applying individual patches =====<br />
Listing the patch as a definition as describe above is required, but does not automatically get the patch applied to the kernel source tree. To do that, the patch must also be listed in the patch application section. Similar to above, typically this is done by searching for the <code># END OF PATCH APPLICATIONS</code> string and listing the patch as:<br />
<br />
<pre><br />
#rhbz 1201532<br />
ApplyPatch HID-multitouch-add-support-of-clickpads.patch<br />
</pre><br />
<br />
following the same comment format/rules as the definition section. Once those two entries are added to the spec file, the patch application should be visible in the output of the <code>fedpkg prep</code> command.<br />
<br />
=== Functions ===<br />
There are a few functions we use to build the kernel. This section will cover those.<br />
<br />
===== ApplyPatch =====<br />
As noted in the above section, the ApplyPatch function is called to actually apply a patch. This is used for both large patches (e.g. patch-4.1-rc2.xz) and standalone patches. The function verifies that the patch being applied is also defined in the spec file, transparently handles any compression, and then applies the patch via:<br />
<br />
<code> patch -p1 -F1 s </code><br />
<br />
There is a similar ApplyOptionalPatch function that will optionally apply a patch if it is not empty and skip it otherwise. This is seldom used.<br />
<br />
===== BuildKernel =====<br />
This is the function that is primarily responsible for actually building the kernel and modules. It takes 'MakeTarget' 'KernelImage' 'Flavour' and optionally 'InstallName' arguments.<br />
<br />
''MakeTarget'': This is the name of the vmlinux target to build. This can vary among the architectures. On x86, it is bzImage. On powerpc it is vmlinux. The architectures define this in a make_target macro elsewhere in the spec.<br />
<br />
''KernelImage'': This is the relative path to the final 'MakeTarget' binary that is produced during the build. E.g. it is arch/x86_64/boot/bzIMage on x86_64. This is similarly defined via a kernel_image macro elsewhere.<br />
<br />
''Flavour'': This is an optional argument the allows us to build multiple kernel flavors for each rpmbuild invocation. E.g. we will be both a normal and a debug kernel, or on i686 we build i686, i686+PAE, i686+debug, i686+PAEdebug.<br />
<br />
''InstallName'': This is optional and not actually specified anywhere today. The default value of 'vmlinuz' is used. It is the leading portion of the name of the final kernel binary that we install.<br />
<br />
The BuildKernel function takes these arguments and builds the kernel and modules via the kernel's makefile system. It generates the correct .config for the architecture, calls make $MakeTarget and make modules, installs the vmlinux, modules, and vdso binaries in the appropriate paths. It also sets up the proper headers and paths for the kernel-devel and debuginfo packages. Essentially this is where virtually all of the build and installation happens for every rpmbuild.<br />
<br />
=== Other ===<br />
There are a few other sections in the spec file that control various items.<br />
<br />
''perf'': The perf command is build after all of the various kernel flavors are built. This is done via an invocation to the perf make system using the perf_make macro to control various options.<br />
<br />
''Other tools'': Various other tools that are contained within the kernel sources are also built after perf.<br />
<br />
''Signing modules'': Due to the way that rpmbuild and debuginfo interact with binaries, we must sign the modules at a particular time during rpmbuild or it will strip off the signatures of the modules. This is done by creating a __modsign_install_post macro and calling that from an overidden __spec_install_post definition. You shouldn't need to modify this.<br />
<br />
=== Package definitions ===<br />
<br />
The kernel is shipped with items split into various packages and sub-packages. These are listed below. Unless you are modifying how the kernel is actually packaged within Fedora, you shouldn't need to modify any of this.<br />
<br />
'''kernel''': This is a meta-package the Requires kernel-core and kernel-modules<br />
<br />
'''kernel-core''': This is the main vmlinux binary, and a handful of other "core" modules. Essentially this is all that is required to boot a Fedora cloud image or a small KVM guest machine.<br />
<br />
'''kernel-modules''': This package contains the remaining modules that are not in kernel-core that are normally used on real hardware. Things like wireless and ethernet drivers, disk drivers, filesystems, etc. On a Fedora Server, Workstation, or any other install that is intended to work on real hardware, this is required.<br />
<br />
'''kernel-modules-extra''': This is a package that contains seldom used modules. It is optional and not included in a default install.<br />
<br />
'''kernel-devel''': This is the package that provides the appropriate symlinks and header to build out-of-tree modules against the Fedora kernel.<br />
<br />
'''kernel-tools''': This contains various tools found in the kernel sources<br />
<br />
'''kernel-tools-libs''': This contains various libraries the above tools provide/use<br />
<br />
'''perf''': This provides the perf command and modules.<br />
<br />
'''*-debuginfo*''': This provides the stripped out debug information for all the kernels, modules, and tools. It is giant and unless you're doing kernel development and need to load it in gdb to get offsets or backtraces, or better oops information, you do not need it installed.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/Spec&diff=409864Kernel/Spec2015-04-14T17:20:46Z<p>Jwboyer: add more to the sources section</p>
<hr />
<div>= The Fedora kernel.spec =<br />
<br />
Like all RPMs, the Fedora kernel starts with a spec file and a set of tarballs and patches. This page will describe some of the sections of the kernel.spec file, what they're used for, and how to modify them.<br />
<br />
=== Macros ===<br />
<br />
There are a few important macros that we modify often. These are listed below.<br />
<br />
<code>%global released_kernel </code><br />
<br />
The released_kernel macro controls whether the rest of the macros and functions are dealing with an upstream released final kernel version. In the stable Fedora branches, this should almost always be set to 1. This will tell the other macros to use the final tarball (e.g. linux-4.0.tar.xz) and base_sublevel as the basis for the version numbers. In rawhide, released_kernel will often be set to 0 as we often ship pre-release git snapshots and -rcX kernels. Having it set to 0 will cause the proper versioning to happen for these non-released kernels.<br />
<br />
<code>%define base_sublevel</code><br />
<br />
The base_sublevel macro sets up the portion of the versioning after the major version number. E.g. base_sublevel of 0 will be 4.0. If it is set to 1, the versioning will be 1. Note, it is a reflection of the actual tarball we are building on top of, so if released_kernel is 0, base_sublevel will still be using the previous version. E.g. 4.1-rc1.git1 starts with the 4.0 tarball, so base_sublevel should be 0.<br />
<br />
<code>%define stable_update</code><br />
<br />
The stable_update macro controls the .y portion of the versioning and is responsible for applying the upstream stable release patches. If it is set to 0, no stable patch will be applied. If it is set to another number, it will apply that .y version number on top of the base_sublevel tarball. E.g. stable_update 2 and base_sublevel 0 would apply patch-4.0.2.xz on top of linux-4.0.tar.xz. This macro is only in use when released_kernel is 1.<br />
<br />
<code>%define rcrev</code><br />
<br />
When released_kernel is 0, we are building RC or merge window kernels. The rcrev macro contains the numeric value of the upstream RC release for the kernel we are targetting. Merge window kernels will have an rcrev of 0. All other -rcX releases will match their upstream release, e.g. 4.1-rc2 would have an rcrev value of 2. This macro is not used when released_kernel is 1.<br />
<br />
<code>%define gitrev</code><br />
<br />
When we build a git snapshot kernel, the gitrev macro contains the value of the git snapshot patch to apply. E.g. 4.1-rc2-git3 would have a gitrev value of 3. This will cause the spec to apply patch-4.1-rc2-git3.xz on top of linux-4.0.xz+patch-4.1-rc2.xz. This is not used when released_kernel is 0.<br />
<br />
Note: We have a script that generated the git snapshot patches and will modify this value in the spec accordingly. Manual modification of this macro does not happen often.<br />
<br />
<code>%global baserelease</code><br />
<br />
The baserelease macro controls the final number in the RPM Release field. E.g a 4.0.0-1.fc23 kernel has a baserelease value of 1. 4.1.0-0.rc2.git1.3.fc23 has a baserelease value of 3. This macro is the most often edited macro we have and should be modified for every commit we do. When we rebase to a new kernel, we reset it back to the value appropriate for that branch. To help with upgrade paths, each Fedora branch has a different starting value for baserelease. These are listed below.<br />
<br />
* rawhide/Branched: Starts at 1 and increments from there.<br />
* Most recent stable release N: Starts at 300 and increments from there<br />
* N-1 release: Starts at 200 and increments from there<br />
* N-2 release: Starts at 100 and increments from there<br />
<br />
This way, the oldest release always has the "oldest" Name-Version-Release combination for that upstream kernel release.<br />
<br />
There are other macros that control some other things, however we'll skip those for now and focus on the main macros used for build output.<br />
<br />
=== Sources ===<br />
===== Tarballs and large patch files =====<br />
The sources file lists the tarballs and large patch files that we used to explode the kernel sources. It will contain the file name and a hash value for that file. The contents will look similar to:<br />
<br />
<pre><br />
a86916bd12798220da9eb4a1eec3616d linux-4.0.tar.xz<br />
d125eecce68ab6fb5f1f23523c2c04b8 perf-man-4.0.tar.gz<br />
</pre><br />
<br />
The perf-man tarball is a self created tarball of the perf man pages. This is generated once per upstream kernel release. As -rcX patches are released and git snapshots are generated, we also add those via the sources file. This is done with the <code>fedpkg upload 'filename'</code> command.<br />
<br />
===== Individual patches =====<br />
<br />
Individual patches are listed in the kernel.spec file in the standalone patches section. These are typically used for bugfixes, however we have a handful of patches we carry for various addons or features. Typically, a new patch is added by searching for the <code># END OF PATCH DEFINITIONS</code> string and adding a new entry above it such as:<br />
<br />
<pre><br />
#rhbz 1196825<br />
Patch26140: security-yama-Remove-unnecessary-selects-from-Kconfi.patch<br />
</pre><br />
<br />
Here we list the Red Hat bugzilla number as a comment above the PatchXXXXX: 'filename' listing. The only stipulation here is that the XXXXX number has to be unique in the spec file. Normally we just increment from the file above it. For security fixes, we tend to use this format:<br />
<br />
<pre><br />
#CVE-2015-2150 rhbz 1196266 1200397<br />
Patch26175: xen-pciback-Don-t-disable-PCI_COMMAND-on-PCI-device-.patch<br />
</pre><br />
<br />
which lists the CVE number, and the two associated Bugzilla numbers (the overall CVE tracking bug, and the Fedora specific instance).<br />
<br />
===== Actually applying individual patches =====<br />
Listing the patch as a definition as describe above is required, but does not automatically get the patch applied to the kernel source tree. To do that, the patch must also be listed in the patch application section. Similar to above, typically this is done by searching for the <code># END OF PATCH APPLICATIONS</code> string and listing the patch as:<br />
<br />
<pre><br />
#rhbz 1201532<br />
ApplyPatch HID-multitouch-add-support-of-clickpads.patch<br />
</pre><br />
<br />
following the same comment format/rules as the definition section. Once those two entries are added to the spec file, the patch application should be visible in the output of the <code>fedpkg prep</code> command.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/Spec&diff=409858Kernel/Spec2015-04-14T17:09:52Z<p>Jwboyer: Add initial sources section</p>
<hr />
<div>= The Fedora kernel.spec =<br />
<br />
Like all RPMs, the Fedora kernel starts with a spec file and a set of tarballs and patches. This page will describe some of the sections of the kernel.spec file, what they're used for, and how to modify them.<br />
<br />
=== Macros ===<br />
<br />
There are a few important macros that we modify often. These are listed below.<br />
<br />
<code>%global released_kernel </code><br />
<br />
The released_kernel macro controls whether the rest of the macros and functions are dealing with an upstream released final kernel version. In the stable Fedora branches, this should almost always be set to 1. This will tell the other macros to use the final tarball (e.g. linux-4.0.tar.xz) and base_sublevel as the basis for the version numbers. In rawhide, released_kernel will often be set to 0 as we often ship pre-release git snapshots and -rcX kernels. Having it set to 0 will cause the proper versioning to happen for these non-released kernels.<br />
<br />
<code>%define base_sublevel</code><br />
<br />
The base_sublevel macro sets up the portion of the versioning after the major version number. E.g. base_sublevel of 0 will be 4.0. If it is set to 1, the versioning will be 1. Note, it is a reflection of the actual tarball we are building on top of, so if released_kernel is 0, base_sublevel will still be using the previous version. E.g. 4.1-rc1.git1 starts with the 4.0 tarball, so base_sublevel should be 0.<br />
<br />
<code>%define stable_update</code><br />
<br />
The stable_update macro controls the .y portion of the versioning and is responsible for applying the upstream stable release patches. If it is set to 0, no stable patch will be applied. If it is set to another number, it will apply that .y version number on top of the base_sublevel tarball. E.g. stable_update 2 and base_sublevel 0 would apply patch-4.0.2.xz on top of linux-4.0.tar.xz. This macro is only in use when released_kernel is 1.<br />
<br />
<code>%define rcrev</code><br />
<br />
When released_kernel is 0, we are building RC or merge window kernels. The rcrev macro contains the numeric value of the upstream RC release for the kernel we are targetting. Merge window kernels will have an rcrev of 0. All other -rcX releases will match their upstream release, e.g. 4.1-rc2 would have an rcrev value of 2. This macro is not used when released_kernel is 1.<br />
<br />
<code>%define gitrev</code><br />
<br />
When we build a git snapshot kernel, the gitrev macro contains the value of the git snapshot patch to apply. E.g. 4.1-rc2-git3 would have a gitrev value of 3. This will cause the spec to apply patch-4.1-rc2-git3.xz on top of linux-4.0.xz+patch-4.1-rc2.xz. This is not used when released_kernel is 0.<br />
<br />
Note: We have a script that generated the git snapshot patches and will modify this value in the spec accordingly. Manual modification of this macro does not happen often.<br />
<br />
<code>%global baserelease</code><br />
<br />
The baserelease macro controls the final number in the RPM Release field. E.g a 4.0.0-1.fc23 kernel has a baserelease value of 1. 4.1.0-0.rc2.git1.3.fc23 has a baserelease value of 3. This macro is the most often edited macro we have and should be modified for every commit we do. When we rebase to a new kernel, we reset it back to the value appropriate for that branch. To help with upgrade paths, each Fedora branch has a different starting value for baserelease. These are listed below.<br />
<br />
* rawhide/Branched: Starts at 1 and increments from there.<br />
* Most recent stable release N: Starts at 300 and increments from there<br />
* N-1 release: Starts at 200 and increments from there<br />
* N-2 release: Starts at 100 and increments from there<br />
<br />
This way, the oldest release always has the "oldest" Name-Version-Release combination for that upstream kernel release.<br />
<br />
There are other macros that control some other things, however we'll skip those for now and focus on the main macros used for build output.<br />
<br />
=== Sources ===<br />
===== Tarballs and large patch files =====<br />
The sources file lists the tarballs and large patch files that we used to explode the kernel sources. It will contain the file name and a hash value for that file. The contents will look similar to:<br />
<br />
<pre><br />
a86916bd12798220da9eb4a1eec3616d linux-4.0.tar.xz<br />
d125eecce68ab6fb5f1f23523c2c04b8 perf-man-4.0.tar.gz<br />
</pre><br />
<br />
The perf-man tarball is a self created tarball of the perf man pages. This is generated once per upstream kernel release. As -rcX patches are released and git snapshots are generated, we also add those via the sources file. This is done with the <code>fedpkg upload 'filename'</code> command.<br />
<br />
===== Individual patches =====</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel/Spec&diff=409855Kernel/Spec2015-04-14T16:55:59Z<p>Jwboyer: Created page with "= The Fedora kernel.spec = Like all RPMs, the Fedora kernel starts with a spec file and a set of tarballs and patches. This page will describe some of the sections of the ke..."</p>
<hr />
<div>= The Fedora kernel.spec =<br />
<br />
Like all RPMs, the Fedora kernel starts with a spec file and a set of tarballs and patches. This page will describe some of the sections of the kernel.spec file, what they're used for, and how to modify them.<br />
<br />
=== Macros ===<br />
<br />
There are a few important macros that we modify often. These are listed below.<br />
<br />
<code>%global released_kernel </code><br />
<br />
The released_kernel macro controls whether the rest of the macros and functions are dealing with an upstream released final kernel version. In the stable Fedora branches, this should almost always be set to 1. This will tell the other macros to use the final tarball (e.g. linux-4.0.tar.xz) and base_sublevel as the basis for the version numbers. In rawhide, released_kernel will often be set to 0 as we often ship pre-release git snapshots and -rcX kernels. Having it set to 0 will cause the proper versioning to happen for these non-released kernels.<br />
<br />
<code>%define base_sublevel</code><br />
<br />
The base_sublevel macro sets up the portion of the versioning after the major version number. E.g. base_sublevel of 0 will be 4.0. If it is set to 1, the versioning will be 1. Note, it is a reflection of the actual tarball we are building on top of, so if released_kernel is 0, base_sublevel will still be using the previous version. E.g. 4.1-rc1.git1 starts with the 4.0 tarball, so base_sublevel should be 0.<br />
<br />
<code>%define stable_update</code><br />
<br />
The stable_update macro controls the .y portion of the versioning and is responsible for applying the upstream stable release patches. If it is set to 0, no stable patch will be applied. If it is set to another number, it will apply that .y version number on top of the base_sublevel tarball. E.g. stable_update 2 and base_sublevel 0 would apply patch-4.0.2.xz on top of linux-4.0.tar.xz. This macro is only in use when released_kernel is 1.<br />
<br />
<code>%define rcrev</code><br />
<br />
When released_kernel is 0, we are building RC or merge window kernels. The rcrev macro contains the numeric value of the upstream RC release for the kernel we are targetting. Merge window kernels will have an rcrev of 0. All other -rcX releases will match their upstream release, e.g. 4.1-rc2 would have an rcrev value of 2. This macro is not used when released_kernel is 1.<br />
<br />
<code>%define gitrev</code><br />
<br />
When we build a git snapshot kernel, the gitrev macro contains the value of the git snapshot patch to apply. E.g. 4.1-rc2-git3 would have a gitrev value of 3. This will cause the spec to apply patch-4.1-rc2-git3.xz on top of linux-4.0.xz+patch-4.1-rc2.xz. This is not used when released_kernel is 0.<br />
<br />
Note: We have a script that generated the git snapshot patches and will modify this value in the spec accordingly. Manual modification of this macro does not happen often.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel&diff=409854Kernel2015-04-14T16:38:08Z<p>Jwboyer: /* Contributing to the Fedora kernel */</p>
<hr />
<div>{{autolang|base=yes}}<br />
Assorted information related to the Fedora Linux kernel.<br />
<br />
= Current versions =<br />
{| border="1" align="center" style="text-align:center;"<br />
|Release<br />
|Version<br />
|MotM<br />
|Comments<br />
|-<br />
|F20<br />
|3.18.x<br />
|jforbes<br />
|<br />
|-<br />
|F21<br />
|3.19.x<br />
|jforbes<br />
|<br />
|-<br />
|F22<br />
|4.0<br />
|jwb<br />
|Synced with rawhide until 4.1 merge window<br />
|-<br />
|Rawhide<br />
|Latest mainline (4.0)<br />
|jwb<br />
| Pretty much always the latest mainline tree.<br />
|}<br />
<br />
Each branches maintainer rotates each month. The MotM field above refers to the current months active maintainer.<br />
If in doubt, send mail to the kernel list (info below) rather than individuals. The maintainers are part of the [[Fedora_Engineering|Fedora Engineering]] team.<br />
<br />
= Fedora kernel mailing list =<br />
<br />
For discussion about Fedora related kernel package issues only. For "my kernel module doesn't work" type messages, see the http://kernelnewbies.org list, or linux-kernel.<br />
<br />
{{fplist|kernel}}<br />
<br />
= IRC =<br />
<br />
Join the {{fpchat|#fedora-kernel}} channel on freenode.net.<br />
<br />
= Source checkout info =<br />
<br />
<pre><br />
fedpkg co kernel<br />
</pre><br />
<br />
This gets you the git checkout and sets up branches for the current releases and master (devel).<br />
Once you have switched to the branch you care about (with git checkout branchname), fedpkg prep will create a tree.<br />
<br />
You'll then be left with a kernel-3.X.? directory, containing both an unpatched 'vanilla-3.X.?' dir, and a linux-3.X.?-noarch hardlinked dir which has the Fedora patches applied.<br />
<br />
The above command will require you to have SSH access to the Fedora pkg-git archives. If you want to do an anonymous checkout of the sources, you can use:<br />
<br />
<pre><br />
fedpkg co -a kernel<br />
</pre><br />
<br />
= Contributing to the Fedora kernel =<br />
* For one-off fixes, send them to the Fedora kernel mailing list, or if they are relevant upstream, send them directly to linux-kernel@vger.kernel.org and Fedora will inherit them on the next rebase<br />
* If you are sending lots of changes to the Fedora kernel, then it may make more sense for you to get commit access. (Note, for most things, sending them upstream is far more preferable).<br />
* To request commit access to the Fedora kernel:<br />
* Get a [[PackageMaintainers/Join|fedora account]] if you don't already have one<br />
* Visit [https://admin.fedoraproject.org/pkgdb/acls/name/kernel the package db entry for the kernel] and request access for the branch(es) which interest you.<br />
* '''Please''' subscribe to the mailing list above. Important announcements regarding rebases, builds, patches being disabled, and much more happen there.<br />
* If you're interested in adding an out-of-tree driver or similar to the Fedora kernel, please read [[KernelDriverPolicy]] first. See [[KernelStagingPolicy]] also.<br />
* Here is a brief overview of the [[Kernel/Spec|kernel.spec]] file<br />
<br />
= Building =<br />
<br />
Fedora's kernels are signed during the build via the pesign client on a specific set of machines. To limit exposure of officially signed builds, only certain people can successfully submit builds that will be tagged into the various koji target tags. If you are not in this ACL then your build will start, but it will fail in the final tagging step. Scratch builds are not subject to this, so it is recommended to use that. If you want the ability to build kernels that go out to end-users when you 'fedpkg build', you need to be in the ACLs that allow builds to be tagged.<br />
<br />
Please note the caveats on official builds.<br />
* The kernel package currently builds many rpms, which means it ties up the build system for hours at a time. For this reason, coordinate with other developers on irc/fedora-kernel-list to be sure there isn't more than one build happening at once.<br />
* Rawhide gets pushed once a day. If you think a build may occur later in the day for some reason, hold off on building. If in doubt, ask.<br />
* If you are checking in patches for any branch other than rawhide, the build won't automatically go out to users, it needs to be processed through [http://bodhi.fedoraproject.org bodhi] . Consider the negative effect of flooding end-users with too many updates, and coordinate your builds with others so that we push updates containing more than one fix.<br />
* For the end-user who wants to build a custom kernel, we offer a separate wiki page [[Building_a_custom_kernel | with complete instructions]].<br />
<br />
= Updates =<br />
<br />
=== Process ===<br />
As mentioned above, updates have to go through bodhi. Below is the process we use for filing a kernel update in bodhi.<br />
* Fill in the package NVR, the bugs it fixes, and any notes you would like to include. Normally this is simply "The <kver> stable update contains a number of important fixes across the tree", or for a rebase "The <kver> rebase contains improved hardware support, a number of new features, and many important fixes across the tree."<br />
* Ensure 'Suggest Reboot' is selected<br />
* Ensure 'Enable karma automatism' is '''not''' selected<br />
* Watch the commentary on the update, ensure bugs are filed for negative karma, etc<br />
* After the update has been in updates-testing for a decent amount of time and has significantly positive karma (these are relative), push it to stable.<br />
<br />
With the wide variety of hardware and use cases Fedora users have, we have found that enabling auto-karma can be detrimental. Often testers will give positive karma for their use cases, hit the auto-karma limit, and the update will be queued for stable before it even hits updates-testing. That significantly reduces the tester pool and can cause an update that introduces issues for a significant number of people to be pushed to stable. We delay intentionally to try and catch these cases. While we will never achieve a perfect update, it has helped quite a bit.<br />
<br />
=== Schedule ===<br />
For stable Fedora branches, the updates essentially follow the upstream stable release schedule. Those tend to be released once a week or slightly less frequently. We do the minor update, build and submit, making sure that the N-1 update is in stable before pushing that release (unless N-1 is very broken.) E.g. When 3.19.2 is released, we push it to testing and make sure 3.19.1 is at least queued for stable. That way bodhi doesn't obsolete the 3.19.1 update. When we have a major rebase for a stable Fedora branch, we follow the same guidelines as above but simply allow more time for people to test.<br />
<br />
For a Fedora release in [[Releases/Branched|Branched]] state, we tend to file updates at each relevant upstream milestone release. E.g. if that branch is working through the 4.0-rcX releases, we file an update once per -rc. As the Fedora release gets closer to GA, the kernel being shipped will transition to a stable upstream release. Then we essentially follow the same steps as above.<br />
<br />
As mentioned in the previous section, Rawhide does not use bodhi for updates.<br />
<br />
= Policies =<br />
Below are some of the policies we use when it comes to various aspects of the Fedora kernel<br />
<br />
* [[KernelRebases]]<br />
* [[KernelDriverPolicy]]<br />
* [[KernelStagingPolicy]]<br />
* [[KernelBuiltinPolicy]]<br />
* Information on the various debugging options used in Fedora kernels can be found at [[KernelDebugStrategy]]<br />
<br />
= Other handy links =<br />
* [[KernelCommonProblems]]<br />
* [[KernelBugTriage]]<br />
* [[Building a custom kernel]]<br />
* [[Building a non-debugging kernel]]<br />
* [[How to use kdump to debug kernel crashes]]<br />
* Information on building upstream kernels by hand for testing can be found at [[BuildingUpstreamKernel]]<br />
* [https://admin.fedoraproject.org/updates/kernel Kernel Updates]<br />
* [[KernelTestingInitiative]]<br />
* [[RawhideKernelNodebug]] The repository for rawhide kernels built without debugging enabled.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel&diff=406936Kernel2015-03-18T18:57:31Z<p>Jwboyer: we don't do official IRC meetings. they weren't worthwhile.</p>
<hr />
<div>{{autolang|base=yes}}<br />
Assorted information related to the Fedora Linux kernel.<br />
<br />
= Current versions =<br />
{| border="1" align="center" style="text-align:center;"<br />
|Release<br />
|Version<br />
|MotM<br />
|Comments<br />
|-<br />
|F20<br />
|3.18.x<br />
|jforbes<br />
|<br />
|-<br />
|F21<br />
|3.18.x<br />
|jforbes<br />
|3.19 rebase in updates testing<br />
|-<br />
|F22<br />
|4.0<br />
|jwb<br />
|Synced with rawhide until 4.1 merge window<br />
|-<br />
|Rawhide<br />
|Latest mainline (4.0)<br />
|jwb<br />
| Pretty much always the latest mainline tree.<br />
|}<br />
<br />
Each branches maintainer rotates each month. The MotM field above refers to the current months active maintainer.<br />
If in doubt, send mail to the kernel list (info below) rather than individuals. The maintainers are part of the [[Fedora_Engineering|Fedora Engineering]] team.<br />
<br />
= Fedora kernel mailing list =<br />
<br />
For discussion about Fedora related kernel package issues only. For "my kernel module doesn't work" type messages, see the http://kernelnewbies.org list, or linux-kernel.<br />
<br />
{{fplist|kernel}}<br />
<br />
= IRC =<br />
<br />
Join the {{fpchat|#fedora-kernel}} channel on freenode.net.<br />
<br />
= Source checkout info =<br />
<br />
<pre><br />
fedpkg co kernel<br />
</pre><br />
<br />
This gets you the git checkout and sets up branches for the current releases and master (devel).<br />
Once you have switched to the branch you care about (with git checkout branchname), fedpkg prep will create a tree.<br />
<br />
You'll then be left with a kernel-3.X.? directory, containing both an unpatched 'vanilla-3.X.?' dir, and a linux-3.X.?-noarch hardlinked dir which has the Fedora patches applied.<br />
<br />
The above command will require you to have SSH access to the Fedora pkg-git archives. If you want to do an anonymous checkout of the sources, you can use:<br />
<br />
<pre><br />
fedpkg co -a kernel<br />
</pre><br />
<br />
= Contributing to the Fedora kernel =<br />
* For one-off fixes, send them to the Fedora kernel mailing list, or if they are relevant upstream, send them directly to linux-kernel@vger.kernel.org and Fedora will inherit them on the next rebase<br />
* If you are sending lots of changes to the Fedora kernel, then it may make more sense for you to get commit access. (Note, for most things, sending them upstream is far more preferable).<br />
* To request commit access to the Fedora kernel:<br />
* Get a [[PackageMaintainers/Join|fedora account]] if you don't already have one<br />
* Visit [https://admin.fedoraproject.org/pkgdb/acls/name/kernel the package db entry for the kernel] and request access for the branch(es) which interest you.<br />
* '''Please''' subscribe to the mailing list above. Important announcements regarding rebases, builds, patches being disabled, and much more happen there.<br />
* If you're interested in adding an out-of-tree driver or similar to the Fedora kernel, please read [[KernelDriverPolicy]] first. See [[KernelStagingPolicy]] also.<br />
<br />
= Building =<br />
<br />
Fedora's kernels are signed during the build via the pesign client on a specific set of machines. To limit exposure of officially signed builds, only certain people can successfully submit builds that will be tagged into the various koji target tags. If you are not in this ACL then your build will start, but it will fail in the final tagging step. Scratch builds are not subject to this, so it is recommended to use that. If you want the ability to build kernels that go out to end-users when you 'fedpkg build', you need to be in the ACLs that allow builds to be tagged.<br />
<br />
Please note the caveats on official builds.<br />
* The kernel package currently builds many rpms, which means it ties up the build system for hours at a time. For this reason, coordinate with other developers on irc/fedora-kernel-list to be sure there isn't more than one build happening at once.<br />
* Rawhide gets pushed once a day. If you think a build may occur later in the day for some reason, hold off on building. If in doubt, ask.<br />
* If you are checking in patches for any branch other than rawhide, the build won't automatically go out to users, it needs to be processed through [http://bodhi.fedoraproject.org bodhi] . Consider the negative effect of flooding end-users with too many updates, and coordinate your builds with others so that we push updates containing more than one fix.<br />
* For the end-user who wants to build a custom kernel, we offer a separate wiki page [[Building_a_custom_kernel | with complete instructions]].<br />
<br />
= Updates =<br />
<br />
=== Process ===<br />
As mentioned above, updates have to go through bodhi. Below is the process we use for filing a kernel update in bodhi.<br />
* Fill in the package NVR, the bugs it fixes, and any notes you would like to include. Normally this is simply "Update to the latest upstream release, Linux v<whatever>".<br />
* Ensure 'Suggest Reboot' is selected<br />
* Ensure 'Enable karma automatism' is '''not''' selected<br />
* Watch the commentary on the update, ensure bugs are filed for negative karma, etc<br />
* After the update has been in updates-testing for a decent amount of time and has significantly positive karma (these are relative), push it to stable.<br />
<br />
With the wide variety of hardware and use cases Fedora users have, we have found that enabling auto-karma can be detrimental. Often testers will give positive karma for their use cases, hit the auto-karma limit, and the update will be queued for stable before it even hits updates-testing. That significantly reduces the tester pool and can cause an update that introduces issues for a significant number of people to be pushed to stable. We delay intentionally to try and catch these cases. While we will never achieve a perfect update, it has helped quite a bit.<br />
<br />
=== Schedule ===<br />
For stable Fedora branches, the updates essentially follow the upstream stable release schedule. Those tend to be released once a week or slightly less frequently. We do the minor update, build and submit, making sure that the N-1 update is in stable before pushing that release (unless N-1 is very broken.) E.g. When 3.19.2 is released, we push it to testing and make sure 3.19.1 is at least queued for stable. That way bodhi doesn't obsolete the 3.19.1 update. When we have a major rebase for a stable Fedora branch, we follow the same guidelines as above but simply allow more time for people to test.<br />
<br />
For a Fedora release in [[Releases/Branched|Branched]] state, we tend to file updates at each relevant upstream milestone release. E.g. if that branch is working through the 4.0-rcX releases, we file an update once per -rc. As the Fedora release gets closer to GA, the kernel being shipped will transition to a stable upstream release. Then we essentially follow the same steps as above.<br />
<br />
As mentioned in the previous section, Rawhide does not use bodhi for updates.<br />
<br />
= Policies =<br />
Below are some of the policies we use when it comes to various aspects of the Fedora kernel<br />
<br />
* [[KernelRebases]]<br />
* [[KernelDriverPolicy]]<br />
* [[KernelStagingPolicy]]<br />
* [[KernelBuiltinPolicy]]<br />
* Information on the various debugging options used in Fedora kernels can be found at [[KernelDebugStrategy]]<br />
<br />
= Other handy links =<br />
* [[KernelCommonProblems]]<br />
* [[KernelBugTriage]]<br />
* [[Building a custom kernel]]<br />
* [[Building a non-debugging kernel]]<br />
* [[How to use kdump to debug kernel crashes]]<br />
* Information on building upstream kernels by hand for testing can be found at [[BuildingUpstreamKernel]]<br />
* [https://admin.fedoraproject.org/updates/kernel Kernel Updates]<br />
* [[KernelTestingInitiative]]<br />
* [[RawhideKernelNodebug]] The repository for rawhide kernels built without debugging enabled.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel&diff=406934Kernel2015-03-18T17:44:49Z<p>Jwboyer: don't recommend the -B switch. it creates a bunch of branch directories that nobody actually cares about.</p>
<hr />
<div>{{autolang|base=yes}}<br />
Assorted information related to the Fedora Linux kernel.<br />
<br />
= Current versions =<br />
{| border="1" align="center" style="text-align:center;"<br />
|Release<br />
|Version<br />
|MotM<br />
|Comments<br />
|-<br />
|F20<br />
|3.18.x<br />
|jforbes<br />
|<br />
|-<br />
|F21<br />
|3.18.x<br />
|jforbes<br />
|3.19 rebase in updates testing<br />
|-<br />
|F22<br />
|4.0<br />
|jwb<br />
|Synced with rawhide until 4.1 merge window<br />
|-<br />
|Rawhide<br />
|Latest mainline (4.0)<br />
|jwb<br />
| Pretty much always the latest mainline tree.<br />
|}<br />
<br />
Each branches maintainer rotates each month. The MotM field above refers to the current months active maintainer.<br />
If in doubt, send mail to the kernel list (info below) rather than individuals. The maintainers are part of the [[Fedora_Engineering|Fedora Engineering]] team.<br />
<br />
= Fedora kernel mailing list =<br />
<br />
For discussion about Fedora related kernel package issues only. For "my kernel module doesn't work" type messages, see the http://kernelnewbies.org list, or linux-kernel.<br />
<br />
{{fplist|kernel}}<br />
<br />
= IRC =<br />
<br />
Join the {{fpchat|#fedora-kernel}} channel on freenode.net.<br />
<br />
Every two weeks, the fedora kernel team meets in the {{fpchat|#fedora-meeting}} channel on freenode.net for a one hour meeting. (Details on times at [[Meeting_channel]])<br />
<br />
= Source checkout info =<br />
<br />
<pre><br />
fedpkg co kernel<br />
</pre><br />
<br />
This gets you the git checkout and sets up branches for the current releases and master (devel).<br />
Once you have switched to the branch you care about (with git checkout branchname), fedpkg prep will create a tree.<br />
<br />
You'll then be left with a kernel-3.X.? directory, containing both an unpatched 'vanilla-3.X.?' dir, and a linux-3.X.?-noarch hardlinked dir which has the Fedora patches applied.<br />
<br />
The above command will require you to have SSH access to the Fedora pkg-git archives. If you want to do an anonymous checkout of the sources, you can use:<br />
<br />
<pre><br />
fedpkg co -a kernel<br />
</pre><br />
<br />
= Contributing to the Fedora kernel =<br />
* For one-off fixes, send them to the Fedora kernel mailing list, or if they are relevant upstream, send them directly to linux-kernel@vger.kernel.org and Fedora will inherit them on the next rebase<br />
* If you are sending lots of changes to the Fedora kernel, then it may make more sense for you to get commit access. (Note, for most things, sending them upstream is far more preferable).<br />
* To request commit access to the Fedora kernel:<br />
* Get a [[PackageMaintainers/Join|fedora account]] if you don't already have one<br />
* Visit [https://admin.fedoraproject.org/pkgdb/acls/name/kernel the package db entry for the kernel] and request access for the branch(es) which interest you.<br />
* '''Please''' subscribe to the mailing list above. Important announcements regarding rebases, builds, patches being disabled, and much more happen there.<br />
* If you're interested in adding an out-of-tree driver or similar to the Fedora kernel, please read [[KernelDriverPolicy]] first. See [[KernelStagingPolicy]] also.<br />
<br />
= Building =<br />
<br />
Fedora's kernels are signed during the build via the pesign client on a specific set of machines. To limit exposure of officially signed builds, only certain people can successfully submit builds that will be tagged into the various koji target tags. If you are not in this ACL then your build will start, but it will fail in the final tagging step. Scratch builds are not subject to this, so it is recommended to use that. If you want the ability to build kernels that go out to end-users when you 'fedpkg build', you need to be in the ACLs that allow builds to be tagged.<br />
<br />
Please note the caveats on official builds.<br />
* The kernel package currently builds many rpms, which means it ties up the build system for hours at a time. For this reason, coordinate with other developers on irc/fedora-kernel-list to be sure there isn't more than one build happening at once.<br />
* Rawhide gets pushed once a day. If you think a build may occur later in the day for some reason, hold off on building. If in doubt, ask.<br />
* If you are checking in patches for any branch other than rawhide, the build won't automatically go out to users, it needs to be processed through [http://bodhi.fedoraproject.org bodhi] . Consider the negative effect of flooding end-users with too many updates, and coordinate your builds with others so that we push updates containing more than one fix.<br />
* For the end-user who wants to build a custom kernel, we offer a separate wiki page [[Building_a_custom_kernel | with complete instructions]].<br />
<br />
= Updates =<br />
<br />
=== Process ===<br />
As mentioned above, updates have to go through bodhi. Below is the process we use for filing a kernel update in bodhi.<br />
* Fill in the package NVR, the bugs it fixes, and any notes you would like to include. Normally this is simply "Update to the latest upstream release, Linux v<whatever>".<br />
* Ensure 'Suggest Reboot' is selected<br />
* Ensure 'Enable karma automatism' is '''not''' selected<br />
* Watch the commentary on the update, ensure bugs are filed for negative karma, etc<br />
* After the update has been in updates-testing for a decent amount of time and has significantly positive karma (these are relative), push it to stable.<br />
<br />
With the wide variety of hardware and use cases Fedora users have, we have found that enabling auto-karma can be detrimental. Often testers will give positive karma for their use cases, hit the auto-karma limit, and the update will be queued for stable before it even hits updates-testing. That significantly reduces the tester pool and can cause an update that introduces issues for a significant number of people to be pushed to stable. We delay intentionally to try and catch these cases. While we will never achieve a perfect update, it has helped quite a bit.<br />
<br />
=== Schedule ===<br />
For stable Fedora branches, the updates essentially follow the upstream stable release schedule. Those tend to be released once a week or slightly less frequently. We do the minor update, build and submit, making sure that the N-1 update is in stable before pushing that release (unless N-1 is very broken.) E.g. When 3.19.2 is released, we push it to testing and make sure 3.19.1 is at least queued for stable. That way bodhi doesn't obsolete the 3.19.1 update. When we have a major rebase for a stable Fedora branch, we follow the same guidelines as above but simply allow more time for people to test.<br />
<br />
For a Fedora release in [[Releases/Branched|Branched]] state, we tend to file updates at each relevant upstream milestone release. E.g. if that branch is working through the 4.0-rcX releases, we file an update once per -rc. As the Fedora release gets closer to GA, the kernel being shipped will transition to a stable upstream release. Then we essentially follow the same steps as above.<br />
<br />
As mentioned in the previous section, Rawhide does not use bodhi for updates.<br />
<br />
= Policies =<br />
Below are some of the policies we use when it comes to various aspects of the Fedora kernel<br />
<br />
* [[KernelRebases]]<br />
* [[KernelDriverPolicy]]<br />
* [[KernelStagingPolicy]]<br />
* [[KernelBuiltinPolicy]]<br />
* Information on the various debugging options used in Fedora kernels can be found at [[KernelDebugStrategy]]<br />
<br />
= Other handy links =<br />
* [[KernelCommonProblems]]<br />
* [[KernelBugTriage]]<br />
* [[Building a custom kernel]]<br />
* [[Building a non-debugging kernel]]<br />
* [[How to use kdump to debug kernel crashes]]<br />
* Information on building upstream kernels by hand for testing can be found at [[BuildingUpstreamKernel]]<br />
* [https://admin.fedoraproject.org/updates/kernel Kernel Updates]<br />
* [[KernelTestingInitiative]]<br />
* [[RawhideKernelNodebug]] The repository for rawhide kernels built without debugging enabled.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel&diff=406933Kernel2015-03-18T17:43:40Z<p>Jwboyer: Clarify building with new signing requirements.</p>
<hr />
<div>{{autolang|base=yes}}<br />
Assorted information related to the Fedora Linux kernel.<br />
<br />
= Current versions =<br />
{| border="1" align="center" style="text-align:center;"<br />
|Release<br />
|Version<br />
|MotM<br />
|Comments<br />
|-<br />
|F20<br />
|3.18.x<br />
|jforbes<br />
|<br />
|-<br />
|F21<br />
|3.18.x<br />
|jforbes<br />
|3.19 rebase in updates testing<br />
|-<br />
|F22<br />
|4.0<br />
|jwb<br />
|Synced with rawhide until 4.1 merge window<br />
|-<br />
|Rawhide<br />
|Latest mainline (4.0)<br />
|jwb<br />
| Pretty much always the latest mainline tree.<br />
|}<br />
<br />
Each branches maintainer rotates each month. The MotM field above refers to the current months active maintainer.<br />
If in doubt, send mail to the kernel list (info below) rather than individuals. The maintainers are part of the [[Fedora_Engineering|Fedora Engineering]] team.<br />
<br />
= Fedora kernel mailing list =<br />
<br />
For discussion about Fedora related kernel package issues only. For "my kernel module doesn't work" type messages, see the http://kernelnewbies.org list, or linux-kernel.<br />
<br />
{{fplist|kernel}}<br />
<br />
= IRC =<br />
<br />
Join the {{fpchat|#fedora-kernel}} channel on freenode.net.<br />
<br />
Every two weeks, the fedora kernel team meets in the {{fpchat|#fedora-meeting}} channel on freenode.net for a one hour meeting. (Details on times at [[Meeting_channel]])<br />
<br />
= Source checkout info =<br />
<br />
<pre><br />
fedpkg co -B kernel<br />
</pre><br />
<br />
This gets you the git checkout and sets up branches for the current releases and master (devel).<br />
Once you have switched to the branch you care about (with git checkout branchname), fedpkg prep will create a tree.<br />
<br />
You'll then be left with a kernel-3.X.? directory, containing both an unpatched 'vanilla-3.X.?' dir, and a linux-3.X.?-noarch hardlinked dir which has the Fedora patches applied.<br />
<br />
The above command will require you to have SSH access to the Fedora pkg-git archives. If you want to do an anonymous checkout of the sources, you can use:<br />
<br />
<pre><br />
fedpkg co -Ba kernel<br />
</pre><br />
<br />
= Contributing to the Fedora kernel =<br />
* For one-off fixes, send them to the Fedora kernel mailing list, or if they are relevant upstream, send them directly to linux-kernel@vger.kernel.org and Fedora will inherit them on the next rebase<br />
* If you are sending lots of changes to the Fedora kernel, then it may make more sense for you to get commit access. (Note, for most things, sending them upstream is far more preferable).<br />
* To request commit access to the Fedora kernel:<br />
* Get a [[PackageMaintainers/Join|fedora account]] if you don't already have one<br />
* Visit [https://admin.fedoraproject.org/pkgdb/acls/name/kernel the package db entry for the kernel] and request access for the branch(es) which interest you.<br />
* '''Please''' subscribe to the mailing list above. Important announcements regarding rebases, builds, patches being disabled, and much more happen there.<br />
* If you're interested in adding an out-of-tree driver or similar to the Fedora kernel, please read [[KernelDriverPolicy]] first. See [[KernelStagingPolicy]] also.<br />
<br />
= Building =<br />
<br />
Fedora's kernels are signed during the build via the pesign client on a specific set of machines. To limit exposure of officially signed builds, only certain people can successfully submit builds that will be tagged into the various koji target tags. If you are not in this ACL then your build will start, but it will fail in the final tagging step. Scratch builds are not subject to this, so it is recommended to use that. If you want the ability to build kernels that go out to end-users when you 'fedpkg build', you need to be in the ACLs that allow builds to be tagged.<br />
<br />
Please note the caveats on official builds.<br />
* The kernel package currently builds many rpms, which means it ties up the build system for hours at a time. For this reason, coordinate with other developers on irc/fedora-kernel-list to be sure there isn't more than one build happening at once.<br />
* Rawhide gets pushed once a day. If you think a build may occur later in the day for some reason, hold off on building. If in doubt, ask.<br />
* If you are checking in patches for any branch other than rawhide, the build won't automatically go out to users, it needs to be processed through [http://bodhi.fedoraproject.org bodhi] . Consider the negative effect of flooding end-users with too many updates, and coordinate your builds with others so that we push updates containing more than one fix.<br />
* For the end-user who wants to build a custom kernel, we offer a separate wiki page [[Building_a_custom_kernel | with complete instructions]].<br />
<br />
= Updates =<br />
<br />
=== Process ===<br />
As mentioned above, updates have to go through bodhi. Below is the process we use for filing a kernel update in bodhi.<br />
* Fill in the package NVR, the bugs it fixes, and any notes you would like to include. Normally this is simply "Update to the latest upstream release, Linux v<whatever>".<br />
* Ensure 'Suggest Reboot' is selected<br />
* Ensure 'Enable karma automatism' is '''not''' selected<br />
* Watch the commentary on the update, ensure bugs are filed for negative karma, etc<br />
* After the update has been in updates-testing for a decent amount of time and has significantly positive karma (these are relative), push it to stable.<br />
<br />
With the wide variety of hardware and use cases Fedora users have, we have found that enabling auto-karma can be detrimental. Often testers will give positive karma for their use cases, hit the auto-karma limit, and the update will be queued for stable before it even hits updates-testing. That significantly reduces the tester pool and can cause an update that introduces issues for a significant number of people to be pushed to stable. We delay intentionally to try and catch these cases. While we will never achieve a perfect update, it has helped quite a bit.<br />
<br />
=== Schedule ===<br />
For stable Fedora branches, the updates essentially follow the upstream stable release schedule. Those tend to be released once a week or slightly less frequently. We do the minor update, build and submit, making sure that the N-1 update is in stable before pushing that release (unless N-1 is very broken.) E.g. When 3.19.2 is released, we push it to testing and make sure 3.19.1 is at least queued for stable. That way bodhi doesn't obsolete the 3.19.1 update. When we have a major rebase for a stable Fedora branch, we follow the same guidelines as above but simply allow more time for people to test.<br />
<br />
For a Fedora release in [[Releases/Branched|Branched]] state, we tend to file updates at each relevant upstream milestone release. E.g. if that branch is working through the 4.0-rcX releases, we file an update once per -rc. As the Fedora release gets closer to GA, the kernel being shipped will transition to a stable upstream release. Then we essentially follow the same steps as above.<br />
<br />
As mentioned in the previous section, Rawhide does not use bodhi for updates.<br />
<br />
= Policies =<br />
Below are some of the policies we use when it comes to various aspects of the Fedora kernel<br />
<br />
* [[KernelRebases]]<br />
* [[KernelDriverPolicy]]<br />
* [[KernelStagingPolicy]]<br />
* [[KernelBuiltinPolicy]]<br />
* Information on the various debugging options used in Fedora kernels can be found at [[KernelDebugStrategy]]<br />
<br />
= Other handy links =<br />
* [[KernelCommonProblems]]<br />
* [[KernelBugTriage]]<br />
* [[Building a custom kernel]]<br />
* [[Building a non-debugging kernel]]<br />
* [[How to use kdump to debug kernel crashes]]<br />
* Information on building upstream kernels by hand for testing can be found at [[BuildingUpstreamKernel]]<br />
* [https://admin.fedoraproject.org/updates/kernel Kernel Updates]<br />
* [[KernelTestingInitiative]]<br />
* [[RawhideKernelNodebug]] The repository for rawhide kernels built without debugging enabled.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel&diff=406931Kernel2015-03-18T17:38:39Z<p>Jwboyer: modernize this a bit</p>
<hr />
<div>{{autolang|base=yes}}<br />
Assorted information related to the Fedora Linux kernel.<br />
<br />
= Current versions =<br />
{| border="1" align="center" style="text-align:center;"<br />
|Release<br />
|Version<br />
|MotM<br />
|Comments<br />
|-<br />
|F20<br />
|3.18.x<br />
|jforbes<br />
|<br />
|-<br />
|F21<br />
|3.18.x<br />
|jforbes<br />
|3.19 rebase in updates testing<br />
|-<br />
|F22<br />
|4.0<br />
|jwb<br />
|Synced with rawhide until 4.1 merge window<br />
|-<br />
|Rawhide<br />
|Latest mainline (4.0)<br />
|jwb<br />
| Pretty much always the latest mainline tree.<br />
|}<br />
<br />
Each branches maintainer rotates each month. The MotM field above refers to the current months active maintainer.<br />
If in doubt, send mail to the kernel list (info below) rather than individuals. The maintainers are part of the [[Fedora_Engineering|Fedora Engineering]] team.<br />
<br />
= Fedora kernel mailing list =<br />
<br />
For discussion about Fedora related kernel package issues only. For "my kernel module doesn't work" type messages, see the http://kernelnewbies.org list, or linux-kernel.<br />
<br />
{{fplist|kernel}}<br />
<br />
= IRC =<br />
<br />
Join the {{fpchat|#fedora-kernel}} channel on freenode.net.<br />
<br />
Every two weeks, the fedora kernel team meets in the {{fpchat|#fedora-meeting}} channel on freenode.net for a one hour meeting. (Details on times at [[Meeting_channel]])<br />
<br />
= Source checkout info =<br />
<br />
<pre><br />
fedpkg co -B kernel<br />
</pre><br />
<br />
This gets you the git checkout and sets up branches for the current releases and master (devel).<br />
Once you have switched to the branch you care about (with git checkout branchname), fedpkg prep will create a tree.<br />
<br />
You'll then be left with a kernel-3.X.? directory, containing both an unpatched 'vanilla-3.X.?' dir, and a linux-3.X.?-noarch hardlinked dir which has the Fedora patches applied.<br />
<br />
The above command will require you to have SSH access to the Fedora pkg-git archives. If you want to do an anonymous checkout of the sources, you can use:<br />
<br />
<pre><br />
fedpkg co -Ba kernel<br />
</pre><br />
<br />
= Contributing to the Fedora kernel =<br />
* For one-off fixes, send them to the Fedora kernel mailing list, or if they are relevant upstream, send them directly to linux-kernel@vger.kernel.org and Fedora will inherit them on the next rebase<br />
* If you are sending lots of changes to the Fedora kernel, then it may make more sense for you to get commit access. (Note, for most things, sending them upstream is far more preferable).<br />
* To request commit access to the Fedora kernel:<br />
* Get a [[PackageMaintainers/Join|fedora account]] if you don't already have one<br />
* Visit [https://admin.fedoraproject.org/pkgdb/acls/name/kernel the package db entry for the kernel] and request access for the branch(es) which interest you.<br />
* '''Please''' subscribe to the mailing list above. Important announcements regarding rebases, builds, patches being disabled, and much more happen there.<br />
* If you're interested in adding an out-of-tree driver or similar to the Fedora kernel, please read [[KernelDriverPolicy]] first. See [[KernelStagingPolicy]] also.<br />
<br />
= Building =<br />
<br />
Commit access also gives you the ability to build kernels that go out to end-users when you 'fedpkg build'. Please note the caveats.<br />
* The kernel package currently builds many rpms, which means it ties up the build system for hours at a time. For this reason, coordinate with other developers on irc/fedora-kernel-list to be sure there isn't more than one build happening at once.<br />
* Rawhide gets pushed once a day. If you think a build may occur later in the day for some reason, hold off on building. If in doubt, ask.<br />
* If you are checking in patches for any branch other than rawhide, the build won't automatically go out to users, it needs to be processed through [http://bodhi.fedoraproject.org bodhi] . Consider the negative effect of flooding end-users with too many updates, and coordinate your builds with others so that we push updates containing more than one fix.<br />
* For the end-user who wants to build a custom kernel, we offer a separate wiki page [[Building_a_custom_kernel | with complete instructions]].<br />
<br />
= Updates =<br />
<br />
=== Process ===<br />
As mentioned above, updates have to go through bodhi. Below is the process we use for filing a kernel update in bodhi.<br />
* Fill in the package NVR, the bugs it fixes, and any notes you would like to include. Normally this is simply "Update to the latest upstream release, Linux v<whatever>".<br />
* Ensure 'Suggest Reboot' is selected<br />
* Ensure 'Enable karma automatism' is '''not''' selected<br />
* Watch the commentary on the update, ensure bugs are filed for negative karma, etc<br />
* After the update has been in updates-testing for a decent amount of time and has significantly positive karma (these are relative), push it to stable.<br />
<br />
With the wide variety of hardware and use cases Fedora users have, we have found that enabling auto-karma can be detrimental. Often testers will give positive karma for their use cases, hit the auto-karma limit, and the update will be queued for stable before it even hits updates-testing. That significantly reduces the tester pool and can cause an update that introduces issues for a significant number of people to be pushed to stable. We delay intentionally to try and catch these cases. While we will never achieve a perfect update, it has helped quite a bit.<br />
<br />
=== Schedule ===<br />
For stable Fedora branches, the updates essentially follow the upstream stable release schedule. Those tend to be released once a week or slightly less frequently. We do the minor update, build and submit, making sure that the N-1 update is in stable before pushing that release (unless N-1 is very broken.) E.g. When 3.19.2 is released, we push it to testing and make sure 3.19.1 is at least queued for stable. That way bodhi doesn't obsolete the 3.19.1 update. When we have a major rebase for a stable Fedora branch, we follow the same guidelines as above but simply allow more time for people to test.<br />
<br />
For a Fedora release in [[Releases/Branched|Branched]] state, we tend to file updates at each relevant upstream milestone release. E.g. if that branch is working through the 4.0-rcX releases, we file an update once per -rc. As the Fedora release gets closer to GA, the kernel being shipped will transition to a stable upstream release. Then we essentially follow the same steps as above.<br />
<br />
As mentioned in the previous section, Rawhide does not use bodhi for updates.<br />
<br />
= Policies =<br />
Below are some of the policies we use when it comes to various aspects of the Fedora kernel<br />
<br />
* [[KernelRebases]]<br />
* [[KernelDriverPolicy]]<br />
* [[KernelStagingPolicy]]<br />
* [[KernelBuiltinPolicy]]<br />
* Information on the various debugging options used in Fedora kernels can be found at [[KernelDebugStrategy]]<br />
<br />
= Other handy links =<br />
* [[KernelCommonProblems]]<br />
* [[KernelBugTriage]]<br />
* [[Building a custom kernel]]<br />
* [[Building a non-debugging kernel]]<br />
* [[How to use kdump to debug kernel crashes]]<br />
* Information on building upstream kernels by hand for testing can be found at [[BuildingUpstreamKernel]]<br />
* [https://admin.fedoraproject.org/updates/kernel Kernel Updates]<br />
* [[KernelTestingInitiative]]<br />
* [[RawhideKernelNodebug]] The repository for rawhide kernels built without debugging enabled.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel&diff=406924Kernel2015-03-18T14:23:57Z<p>Jwboyer: Add link to Fedora Engineering page</p>
<hr />
<div>{{autolang|base=yes}}<br />
Assorted information related to the Fedora Linux kernel.<br />
<br />
= Current versions =<br />
{| border="1" align="center" style="text-align:center;"<br />
|Release<br />
|Version<br />
|MotM<br />
|Comments<br />
|-<br />
|F20<br />
|3.18.x<br />
|jforbes<br />
|<br />
|-<br />
|F21<br />
|3.18.x<br />
|jforbes<br />
|3.19 rebase in updates testing<br />
|-<br />
|F22<br />
|4.0<br />
|jwb<br />
|Synced with rawhide until 4.1 merge window<br />
|-<br />
|Rawhide<br />
|Latest mainline (4.0)<br />
|jwb<br />
| Pretty much always the latest mainline tree.<br />
|}<br />
<br />
Each branches maintainer rotates each month. The MotM field above refers to the current months active maintainer.<br />
If in doubt, send mail to the kernel list (info below) rather than individuals. The maintainers are part of the [[Fedora_Engineering|Fedora Engineering]] team.<br />
<br />
= Fedora kernel mailing list =<br />
<br />
For discussion about Fedora related kernel package issues only. For "my kernel module doesn't work" type messages, see the http://kernelnewbies.org list, or linux-kernel.<br />
<br />
{{fplist|kernel}}<br />
<br />
= IRC =<br />
<br />
Join the {{fpchat|#fedora-kernel}} channel on freenode.net.<br />
<br />
Every two weeks, the fedora kernel team meets in the {{fpchat|#fedora-meeting}} channel on freenode.net for a one hour meeting. (Details on times at [[Meeting_channel]])<br />
<br />
= Source checkout info =<br />
<br />
<pre><br />
fedpkg co -B kernel<br />
</pre><br />
<br />
This gets you the git checkout and sets up branches for f13, f14, and master (devel).<br />
Once you have switched to the branch you care about (with git checkout branchname), fedpkg prep will create a tree.<br />
<br />
You'll then be left with a kernel-2.6.? directory, containing both an unpatched 'vanilla-2.6.?' dir, and a linux-2.6.?-noarch hardlinked dir which has the Fedora patches applied.<br />
<br />
The above command will require you to have SSH access to the Fedora pkg-git archives. If you want to do an anonymous checkout of the sources, you can use:<br />
<br />
<pre><br />
fedpkg co -Ba kernel<br />
</pre><br />
<br />
= Contributing to the Fedora kernel =<br />
* For one-off fixes, send them to the Fedora kernel mailing list, or if they are relevant upstream, send them directly to linux-kernel@vger.kernel.org and Fedora will inherit them on the next rebase<br />
* If you are sending lots of changes to the Fedora kernel, then it may make more sense for you to get commit access. (Note, for most things, sending them upstream is far more preferable).<br />
* To request commit access to the Fedora kernel:<br />
* Get a [[PackageMaintainers/Join|fedora account]] if you don't already have one<br />
* Visit [https://admin.fedoraproject.org/pkgdb/acls/name/kernel the package db entry for the kernel] and request access for the branch(es) which interest you.<br />
* '''Please''' subscribe to the mailing list above. Important announcements regarding rebases, builds, patches being disabled, and much more happen there.<br />
* If you're interested in adding an out-of-tree driver or similar to the Fedora kernel, please read [[KernelDriverPolicy]] first. See [[KernelStagingPolicy]] also.<br />
<br />
= Building =<br />
<br />
Commit access also gives you the ability to build kernels that go out to end-users when you 'fedpkg build'. Please note the caveats.<br />
* The kernel package currently builds many rpms, which means it ties up the build system for hours at a time. For this reason, coordinate with other developers on irc/fedora-kernel-list to be sure there isn't more than one build happening at once.<br />
* Rawhide gets pushed once a day. If you think a build may occur later in the day for some reason, hold off on building. If in doubt, ask.<br />
* If you are checking in patches for any branch other than rawhide, the build won't automatically go out to users, it needs to be processed through [http://bodhi.fedoraproject.org bodhi] . Consider the negative effect of flooding end-users with too many updates, and coordinate your builds with others so that we push updates containing more than one fix.<br />
* For the end-user who wants to build a custom kernel, we offer a separate wiki page [[Building_a_custom_kernel | with complete instructions]].<br />
<br />
= Updates =<br />
<br />
=== Process ===<br />
As mentioned above, updates have to go through bodhi. Below is the process we use for filing a kernel update in bodhi.<br />
* Fill in the package NVR, the bugs it fixes, and any notes you would like to include. Normally this is simply "Update to the latest upstream release, Linux v<whatever>".<br />
* Ensure 'Suggest Reboot' is selected<br />
* Ensure 'Enable karma automatism' is '''not''' selected<br />
* Watch the commentary on the update, ensure bugs are filed for negative karma, etc<br />
* After the update has been in updates-testing for a decent amount of time and has significantly positive karma (these are relative), push it to stable.<br />
<br />
With the wide variety of hardware and use cases Fedora users have, we have found that enabling auto-karma can be detrimental. Often testers will give positive karma for their use cases, hit the auto-karma limit, and the update will be queued for stable before it even hits updates-testing. That significantly reduces the tester pool and can cause an update that introduces issues for a significant number of people to be pushed to stable. We delay intentionally to try and catch these cases. While we will never achieve a perfect update, it has helped quite a bit.<br />
<br />
=== Schedule ===<br />
For stable Fedora branches, the updates essentially follow the upstream stable release schedule. Those tend to be released once a week or slightly less frequently. We do the minor update, build and submit, making sure that the N-1 update is in stable before pushing that release (unless N-1 is very broken.) E.g. When 3.19.2 is released, we push it to testing and make sure 3.19.1 is at least queued for stable. That way bodhi doesn't obsolete the 3.19.1 update. When we have a major rebase for a stable Fedora branch, we follow the same guidelines as above but simply allow more time for people to test.<br />
<br />
For a Fedora release in [[Releases/Branched|Branched]] state, we tend to file updates at each relevant upstream milestone release. E.g. if that branch is working through the 4.0-rcX releases, we file an update once per -rc. As the Fedora release gets closer to GA, the kernel being shipped will transition to a stable upstream release. Then we essentially follow the same steps as above.<br />
<br />
As mentioned in the previous section, Rawhide does not use bodhi for updates.<br />
<br />
= Policies =<br />
Below are some of the policies we use when it comes to various aspects of the Fedora kernel<br />
<br />
* [[KernelRebases]]<br />
* [[KernelDriverPolicy]]<br />
* [[KernelStagingPolicy]]<br />
* [[KernelBuiltinPolicy]]<br />
* Information on the various debugging options used in Fedora kernels can be found at [[KernelDebugStrategy]]<br />
<br />
= Other handy links =<br />
* [[KernelCommonProblems]]<br />
* [[KernelBugTriage]]<br />
* [[Building a custom kernel]]<br />
* [[Building a non-debugging kernel]]<br />
* [[How to use kdump to debug kernel crashes]]<br />
* Information on building upstream kernels by hand for testing can be found at [[BuildingUpstreamKernel]]<br />
* [https://admin.fedoraproject.org/updates/kernel Kernel Updates]<br />
* [[KernelTestingInitiative]]<br />
* [[RawhideKernelNodebug]] The repository for rawhide kernels built without debugging enabled.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel&diff=406923Kernel2015-03-18T14:15:10Z<p>Jwboyer: Add updates process/schedule</p>
<hr />
<div>{{autolang|base=yes}}<br />
Assorted information related to the Fedora Linux kernel.<br />
<br />
= Current versions =<br />
{| border="1" align="center" style="text-align:center;"<br />
|Release<br />
|Version<br />
|MotM<br />
|Comments<br />
|-<br />
|F20<br />
|3.18.x<br />
|jforbes<br />
|<br />
|-<br />
|F21<br />
|3.18.x<br />
|jforbes<br />
|3.19 rebase in updates testing<br />
|-<br />
|F22<br />
|4.0<br />
|jwb<br />
|Synced with rawhide until 4.1 merge window<br />
|-<br />
|Rawhide<br />
|Latest mainline (4.0)<br />
|jwb<br />
| Pretty much always the latest mainline tree.<br />
|}<br />
<br />
Each branches maintainer rotates each month. The MotM field above refers to the current months active maintainer.<br />
If in doubt, send mail to the kernel list (info below) rather than individuals.<br />
<br />
= Fedora kernel mailing list =<br />
<br />
For discussion about Fedora related kernel package issues only. For "my kernel module doesn't work" type messages, see the http://kernelnewbies.org list, or linux-kernel.<br />
<br />
{{fplist|kernel}}<br />
<br />
= IRC =<br />
<br />
Join the {{fpchat|#fedora-kernel}} channel on freenode.net.<br />
<br />
Every two weeks, the fedora kernel team meets in the {{fpchat|#fedora-meeting}} channel on freenode.net for a one hour meeting. (Details on times at [[Meeting_channel]])<br />
<br />
= Source checkout info =<br />
<br />
<pre><br />
fedpkg co -B kernel<br />
</pre><br />
<br />
This gets you the git checkout and sets up branches for f13, f14, and master (devel).<br />
Once you have switched to the branch you care about (with git checkout branchname), fedpkg prep will create a tree.<br />
<br />
You'll then be left with a kernel-2.6.? directory, containing both an unpatched 'vanilla-2.6.?' dir, and a linux-2.6.?-noarch hardlinked dir which has the Fedora patches applied.<br />
<br />
The above command will require you to have SSH access to the Fedora pkg-git archives. If you want to do an anonymous checkout of the sources, you can use:<br />
<br />
<pre><br />
fedpkg co -Ba kernel<br />
</pre><br />
<br />
= Contributing to the Fedora kernel =<br />
* For one-off fixes, send them to the Fedora kernel mailing list, or if they are relevant upstream, send them directly to linux-kernel@vger.kernel.org and Fedora will inherit them on the next rebase<br />
* If you are sending lots of changes to the Fedora kernel, then it may make more sense for you to get commit access. (Note, for most things, sending them upstream is far more preferable).<br />
* To request commit access to the Fedora kernel:<br />
* Get a [[PackageMaintainers/Join|fedora account]] if you don't already have one<br />
* Visit [https://admin.fedoraproject.org/pkgdb/acls/name/kernel the package db entry for the kernel] and request access for the branch(es) which interest you.<br />
* '''Please''' subscribe to the mailing list above. Important announcements regarding rebases, builds, patches being disabled, and much more happen there.<br />
* If you're interested in adding an out-of-tree driver or similar to the Fedora kernel, please read [[KernelDriverPolicy]] first. See [[KernelStagingPolicy]] also.<br />
<br />
= Building =<br />
<br />
Commit access also gives you the ability to build kernels that go out to end-users when you 'fedpkg build'. Please note the caveats.<br />
* The kernel package currently builds many rpms, which means it ties up the build system for hours at a time. For this reason, coordinate with other developers on irc/fedora-kernel-list to be sure there isn't more than one build happening at once.<br />
* Rawhide gets pushed once a day. If you think a build may occur later in the day for some reason, hold off on building. If in doubt, ask.<br />
* If you are checking in patches for any branch other than rawhide, the build won't automatically go out to users, it needs to be processed through [http://bodhi.fedoraproject.org bodhi] . Consider the negative effect of flooding end-users with too many updates, and coordinate your builds with others so that we push updates containing more than one fix.<br />
* For the end-user who wants to build a custom kernel, we offer a separate wiki page [[Building_a_custom_kernel | with complete instructions]].<br />
<br />
= Updates =<br />
<br />
=== Process ===<br />
As mentioned above, updates have to go through bodhi. Below is the process we use for filing a kernel update in bodhi.<br />
* Fill in the package NVR, the bugs it fixes, and any notes you would like to include. Normally this is simply "Update to the latest upstream release, Linux v<whatever>".<br />
* Ensure 'Suggest Reboot' is selected<br />
* Ensure 'Enable karma automatism' is '''not''' selected<br />
* Watch the commentary on the update, ensure bugs are filed for negative karma, etc<br />
* After the update has been in updates-testing for a decent amount of time and has significantly positive karma (these are relative), push it to stable.<br />
<br />
With the wide variety of hardware and use cases Fedora users have, we have found that enabling auto-karma can be detrimental. Often testers will give positive karma for their use cases, hit the auto-karma limit, and the update will be queued for stable before it even hits updates-testing. That significantly reduces the tester pool and can cause an update that introduces issues for a significant number of people to be pushed to stable. We delay intentionally to try and catch these cases. While we will never achieve a perfect update, it has helped quite a bit.<br />
<br />
=== Schedule ===<br />
For stable Fedora branches, the updates essentially follow the upstream stable release schedule. Those tend to be released once a week or slightly less frequently. We do the minor update, build and submit, making sure that the N-1 update is in stable before pushing that release (unless N-1 is very broken.) E.g. When 3.19.2 is released, we push it to testing and make sure 3.19.1 is at least queued for stable. That way bodhi doesn't obsolete the 3.19.1 update. When we have a major rebase for a stable Fedora branch, we follow the same guidelines as above but simply allow more time for people to test.<br />
<br />
For a Fedora release in [[Releases/Branched|Branched]] state, we tend to file updates at each relevant upstream milestone release. E.g. if that branch is working through the 4.0-rcX releases, we file an update once per -rc. As the Fedora release gets closer to GA, the kernel being shipped will transition to a stable upstream release. Then we essentially follow the same steps as above.<br />
<br />
As mentioned in the previous section, Rawhide does not use bodhi for updates.<br />
<br />
= Policies =<br />
Below are some of the policies we use when it comes to various aspects of the Fedora kernel<br />
<br />
* [[KernelRebases]]<br />
* [[KernelDriverPolicy]]<br />
* [[KernelStagingPolicy]]<br />
* [[KernelBuiltinPolicy]]<br />
* Information on the various debugging options used in Fedora kernels can be found at [[KernelDebugStrategy]]<br />
<br />
= Other handy links =<br />
* [[KernelCommonProblems]]<br />
* [[KernelBugTriage]]<br />
* [[Building a custom kernel]]<br />
* [[Building a non-debugging kernel]]<br />
* [[How to use kdump to debug kernel crashes]]<br />
* Information on building upstream kernels by hand for testing can be found at [[BuildingUpstreamKernel]]<br />
* [https://admin.fedoraproject.org/updates/kernel Kernel Updates]<br />
* [[KernelTestingInitiative]]<br />
* [[RawhideKernelNodebug]] The repository for rawhide kernels built without debugging enabled.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel&diff=406921Kernel2015-03-18T13:53:16Z<p>Jwboyer: /* Contributing to the Fedora kernel */</p>
<hr />
<div>{{autolang|base=yes}}<br />
Assorted information related to the Fedora Linux kernel.<br />
<br />
= Current versions =<br />
{| border="1" align="center" style="text-align:center;"<br />
|Release<br />
|Version<br />
|MotM<br />
|Comments<br />
|-<br />
|F20<br />
|3.18.x<br />
|jforbes<br />
|<br />
|-<br />
|F21<br />
|3.18.x<br />
|jforbes<br />
|3.19 rebase in updates testing<br />
|-<br />
|F22<br />
|4.0<br />
|jwb<br />
|Synced with rawhide until 4.1 merge window<br />
|-<br />
|Rawhide<br />
|Latest mainline (4.0)<br />
|jwb<br />
| Pretty much always the latest mainline tree.<br />
|}<br />
<br />
Each branches maintainer rotates each month. The MotM field above refers to the current months active maintainer.<br />
If in doubt, send mail to the kernel list (info below) rather than individuals.<br />
<br />
= Fedora kernel mailing list =<br />
<br />
For discussion about Fedora related kernel package issues only. For "my kernel module doesn't work" type messages, see the http://kernelnewbies.org list, or linux-kernel.<br />
<br />
{{fplist|kernel}}<br />
<br />
= IRC =<br />
<br />
Join the {{fpchat|#fedora-kernel}} channel on freenode.net.<br />
<br />
Every two weeks, the fedora kernel team meets in the {{fpchat|#fedora-meeting}} channel on freenode.net for a one hour meeting. (Details on times at [[Meeting_channel]])<br />
<br />
= Source checkout info =<br />
<br />
<pre><br />
fedpkg co -B kernel<br />
</pre><br />
<br />
This gets you the git checkout and sets up branches for f13, f14, and master (devel).<br />
Once you have switched to the branch you care about (with git checkout branchname), fedpkg prep will create a tree.<br />
<br />
You'll then be left with a kernel-2.6.? directory, containing both an unpatched 'vanilla-2.6.?' dir, and a linux-2.6.?-noarch hardlinked dir which has the Fedora patches applied.<br />
<br />
The above command will require you to have SSH access to the Fedora pkg-git archives. If you want to do an anonymous checkout of the sources, you can use:<br />
<br />
<pre><br />
fedpkg co -Ba kernel<br />
</pre><br />
<br />
= Contributing to the Fedora kernel =<br />
* For one-off fixes, send them to the Fedora kernel mailing list, or if they are relevant upstream, send them directly to linux-kernel@vger.kernel.org and Fedora will inherit them on the next rebase<br />
* If you are sending lots of changes to the Fedora kernel, then it may make more sense for you to get commit access. (Note, for most things, sending them upstream is far more preferable).<br />
* To request commit access to the Fedora kernel:<br />
* Get a [[PackageMaintainers/Join|fedora account]] if you don't already have one<br />
* Visit [https://admin.fedoraproject.org/pkgdb/acls/name/kernel the package db entry for the kernel] and request access for the branch(es) which interest you.<br />
* '''Please''' subscribe to the mailing list above. Important announcements regarding rebases, builds, patches being disabled, and much more happen there.<br />
* If you're interested in adding an out-of-tree driver or similar to the Fedora kernel, please read [[KernelDriverPolicy]] first. See [[KernelStagingPolicy]] also.<br />
<br />
= Building =<br />
<br />
Commit access also gives you the ability to build kernels that go out to end-users when you 'fedpkg build'. Please note the caveats.<br />
* The kernel package currently builds many rpms, which means it ties up the build system for hours at a time. For this reason, coordinate with other developers on irc/fedora-kernel-list to be sure there isn't more than one build happening at once.<br />
* Rawhide gets pushed once a day. If you think a build may occur later in the day for some reason, hold off on building. If in doubt, ask.<br />
* If you are checking in patches for any branch other than rawhide, the build won't automatically go out to users, it needs to be processed through [http://bodhi.fedoraproject.org bodhi] . Consider the negative effect of flooding end-users with too many updates, and coordinate your builds with others so that we push updates containing more than one fix.<br />
* For the end-user who wants to build a custom kernel, we offer a separate wiki page [[Building_a_custom_kernel | with complete instructions]].<br />
<br />
= Policies =<br />
Below are some of the policies we use when it comes to various aspects of the Fedora kernel<br />
<br />
* [[KernelRebases]]<br />
* [[KernelDriverPolicy]]<br />
* [[KernelStagingPolicy]]<br />
* [[KernelBuiltinPolicy]]<br />
* Information on the various debugging options used in Fedora kernels can be found at [[KernelDebugStrategy]]<br />
<br />
= Other handy links =<br />
* [[KernelCommonProblems]]<br />
* [[KernelBugTriage]]<br />
* [[Building a custom kernel]]<br />
* [[Building a non-debugging kernel]]<br />
* [[How to use kdump to debug kernel crashes]]<br />
* Information on building upstream kernels by hand for testing can be found at [[BuildingUpstreamKernel]]<br />
* [https://admin.fedoraproject.org/updates/kernel Kernel Updates]<br />
* [[KernelTestingInitiative]]<br />
* [[RawhideKernelNodebug]] The repository for rawhide kernels built without debugging enabled.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel&diff=406920Kernel2015-03-18T13:51:41Z<p>Jwboyer: s/make/fedpkg for building. The makefile doesn't have a build target</p>
<hr />
<div>{{autolang|base=yes}}<br />
Assorted information related to the Fedora Linux kernel.<br />
<br />
= Current versions =<br />
{| border="1" align="center" style="text-align:center;"<br />
|Release<br />
|Version<br />
|MotM<br />
|Comments<br />
|-<br />
|F20<br />
|3.18.x<br />
|jforbes<br />
|<br />
|-<br />
|F21<br />
|3.18.x<br />
|jforbes<br />
|3.19 rebase in updates testing<br />
|-<br />
|F22<br />
|4.0<br />
|jwb<br />
|Synced with rawhide until 4.1 merge window<br />
|-<br />
|Rawhide<br />
|Latest mainline (4.0)<br />
|jwb<br />
| Pretty much always the latest mainline tree.<br />
|}<br />
<br />
Each branches maintainer rotates each month. The MotM field above refers to the current months active maintainer.<br />
If in doubt, send mail to the kernel list (info below) rather than individuals.<br />
<br />
= Fedora kernel mailing list =<br />
<br />
For discussion about Fedora related kernel package issues only. For "my kernel module doesn't work" type messages, see the http://kernelnewbies.org list, or linux-kernel.<br />
<br />
{{fplist|kernel}}<br />
<br />
= IRC =<br />
<br />
Join the {{fpchat|#fedora-kernel}} channel on freenode.net.<br />
<br />
Every two weeks, the fedora kernel team meets in the {{fpchat|#fedora-meeting}} channel on freenode.net for a one hour meeting. (Details on times at [[Meeting_channel]])<br />
<br />
= Source checkout info =<br />
<br />
<pre><br />
fedpkg co -B kernel<br />
</pre><br />
<br />
This gets you the git checkout and sets up branches for f13, f14, and master (devel).<br />
Once you have switched to the branch you care about (with git checkout branchname), fedpkg prep will create a tree.<br />
<br />
You'll then be left with a kernel-2.6.? directory, containing both an unpatched 'vanilla-2.6.?' dir, and a linux-2.6.?-noarch hardlinked dir which has the Fedora patches applied.<br />
<br />
The above command will require you to have SSH access to the Fedora pkg-git archives. If you want to do an anonymous checkout of the sources, you can use:<br />
<br />
<pre><br />
fedpkg co -Ba kernel<br />
</pre><br />
<br />
= Contributing to the Fedora kernel =<br />
* For one-off fixes, send them to the fedora-kernel mailing list, or if they are relevant upstream, send them directly to linux-kernel@vger.kernel.org and Fedora will inherit them on the next rebase<br />
* If you are sending lots of changes to the Fedora kernel, then it may make more sense for you to get commit access. (Note, for most things, sending them upstream is far more preferable).<br />
* To request commit access to the Fedora kernel:<br />
* Get a [[PackageMaintainers/Join|fedora account]] if you don't already have one<br />
* Visit [https://admin.fedoraproject.org/pkgdb/acls/name/kernel the package db entry for the kernel] and request access for the branch(es) which interest you.<br />
* '''Please''' subscribe to the mailing list above. Important announcements regarding rebases, builds, patches being disabled, and much more happen there.<br />
* If you're interested in adding an out-of-tree driver or similar to the Fedora kernel, please read [[KernelDriverPolicy]] first. See [[KernelStagingPolicy]] also.<br />
<br />
= Building =<br />
<br />
Commit access also gives you the ability to build kernels that go out to end-users when you 'fedpkg build'. Please note the caveats.<br />
* The kernel package currently builds many rpms, which means it ties up the build system for hours at a time. For this reason, coordinate with other developers on irc/fedora-kernel-list to be sure there isn't more than one build happening at once.<br />
* Rawhide gets pushed once a day. If you think a build may occur later in the day for some reason, hold off on building. If in doubt, ask.<br />
* If you are checking in patches for any branch other than rawhide, the build won't automatically go out to users, it needs to be processed through [http://bodhi.fedoraproject.org bodhi] . Consider the negative effect of flooding end-users with too many updates, and coordinate your builds with others so that we push updates containing more than one fix.<br />
* For the end-user who wants to build a custom kernel, we offer a separate wiki page [[Building_a_custom_kernel | with complete instructions]].<br />
<br />
= Policies =<br />
Below are some of the policies we use when it comes to various aspects of the Fedora kernel<br />
<br />
* [[KernelRebases]]<br />
* [[KernelDriverPolicy]]<br />
* [[KernelStagingPolicy]]<br />
* [[KernelBuiltinPolicy]]<br />
* Information on the various debugging options used in Fedora kernels can be found at [[KernelDebugStrategy]]<br />
<br />
= Other handy links =<br />
* [[KernelCommonProblems]]<br />
* [[KernelBugTriage]]<br />
* [[Building a custom kernel]]<br />
* [[Building a non-debugging kernel]]<br />
* [[How to use kdump to debug kernel crashes]]<br />
* Information on building upstream kernels by hand for testing can be found at [[BuildingUpstreamKernel]]<br />
* [https://admin.fedoraproject.org/updates/kernel Kernel Updates]<br />
* [[KernelTestingInitiative]]<br />
* [[RawhideKernelNodebug]] The repository for rawhide kernels built without debugging enabled.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Kernel&diff=406918Kernel2015-03-18T13:34:35Z<p>Jwboyer: /* Current versions */</p>
<hr />
<div>{{autolang|base=yes}}<br />
Assorted information related to the Fedora Linux kernel.<br />
<br />
= Current versions =<br />
{| border="1" align="center" style="text-align:center;"<br />
|Release<br />
|Version<br />
|MotM<br />
|Comments<br />
|-<br />
|F20<br />
|3.18.x<br />
|jforbes<br />
|<br />
|-<br />
|F21<br />
|3.18.x<br />
|jforbes<br />
|3.19 rebase in updates testing<br />
|-<br />
|F22<br />
|4.0<br />
|jwb<br />
|Synced with rawhide until 4.1 merge window<br />
|-<br />
|Rawhide<br />
|Latest mainline (4.0)<br />
|jwb<br />
| Pretty much always the latest mainline tree.<br />
|}<br />
<br />
Each branches maintainer rotates each month. The MotM field above refers to the current months active maintainer.<br />
If in doubt, send mail to the kernel list (info below) rather than individuals.<br />
<br />
= Fedora kernel mailing list =<br />
<br />
For discussion about Fedora related kernel package issues only. For "my kernel module doesn't work" type messages, see the http://kernelnewbies.org list, or linux-kernel.<br />
<br />
{{fplist|kernel}}<br />
<br />
= IRC =<br />
<br />
Join the {{fpchat|#fedora-kernel}} channel on freenode.net.<br />
<br />
Every two weeks, the fedora kernel team meets in the {{fpchat|#fedora-meeting}} channel on freenode.net for a one hour meeting. (Details on times at [[Meeting_channel]])<br />
<br />
= Source checkout info =<br />
<br />
<pre><br />
fedpkg co -B kernel<br />
</pre><br />
<br />
This gets you the git checkout and sets up branches for f13, f14, and master (devel).<br />
Once you have switched to the branch you care about (with git checkout branchname), fedpkg prep will create a tree.<br />
<br />
You'll then be left with a kernel-2.6.? directory, containing both an unpatched 'vanilla-2.6.?' dir, and a linux-2.6.?-noarch hardlinked dir which has the Fedora patches applied.<br />
<br />
The above command will require you to have SSH access to the Fedora pkg-git archives. If you want to do an anonymous checkout of the sources, you can use:<br />
<br />
<pre><br />
fedpkg co -Ba kernel<br />
</pre><br />
<br />
= Contributing to the Fedora kernel =<br />
* For one-off fixes, send them to the fedora-kernel mailing list, or if they are relevant upstream, send them directly to linux-kernel@vger.kernel.org and Fedora will inherit them on the next rebase<br />
* If you are sending lots of changes to the Fedora kernel, then it may make more sense for you to get commit access. (Note, for most things, sending them upstream is far more preferable).<br />
* To request commit access to the Fedora kernel:<br />
* Get a [[PackageMaintainers/Join|fedora account]] if you don't already have one<br />
* Visit [https://admin.fedoraproject.org/pkgdb/acls/name/kernel the package db entry for the kernel] and request access for the branch(es) which interest you.<br />
* '''Please''' subscribe to the mailing list above. Important announcements regarding rebases, builds, patches being disabled, and much more happen there.<br />
* If you're interested in adding an out-of-tree driver or similar to the Fedora kernel, please read [[KernelDriverPolicy]] first. See [[KernelStagingPolicy]] also.<br />
<br />
= Building =<br />
<br />
Commit access also gives you the ability to build kernels that go out to end-users when you 'make build'. Please note the caveats.<br />
* The kernel package currently builds many rpms, which means it ties up the build system for hours at a time. For this reason, coordinate with other developers on irc/fedora-kernel-list to be sure there isn't more than one build happening at once.<br />
* Rawhide gets pushed once a day. If you think a build may occur later in the day for some reason, hold off on building. If in doubt, ask.<br />
* If you are checking in patches for any branch other than rawhide, the build won't automatically go out to users, it needs to be processed through [http://bodhi.fedoraproject.org bodhi] . Consider the negative effect of flooding end-users with too many updates, and coordinate your builds with others so that we push updates containing more than one fix.<br />
* For the end-user who wants to build a custom kernel, we offer a separate wiki page [[Building_a_custom_kernel | with complete instructions]].<br />
<br />
= Policies =<br />
Below are some of the policies we use when it comes to various aspects of the Fedora kernel<br />
<br />
* [[KernelRebases]]<br />
* [[KernelDriverPolicy]]<br />
* [[KernelStagingPolicy]]<br />
* [[KernelBuiltinPolicy]]<br />
* Information on the various debugging options used in Fedora kernels can be found at [[KernelDebugStrategy]]<br />
<br />
= Other handy links =<br />
* [[KernelCommonProblems]]<br />
* [[KernelBugTriage]]<br />
* [[Building a custom kernel]]<br />
* [[Building a non-debugging kernel]]<br />
* [[How to use kdump to debug kernel crashes]]<br />
* Information on building upstream kernels by hand for testing can be found at [[BuildingUpstreamKernel]]<br />
* [https://admin.fedoraproject.org/updates/kernel Kernel Updates]<br />
* [[KernelTestingInitiative]]<br />
* [[RawhideKernelNodebug]] The repository for rawhide kernels built without debugging enabled.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Council&diff=406225Council2015-03-11T15:22:52Z<p>Jwboyer: Contact info, now with links</p>
<hr />
<div>{{message|This charter was approved by the Fedora Project Board on [https://fedorahosted.org/council/ticket/13 Oct. 9th, 2014] and is in effect as of Nov. 26th, 2014.}}<br />
<br />
[[File:Fedora_council.svg|right|500px]]<br />
<br />
= Introduction =<br />
<br />
The Fedora Council is our top-level community leadership and governance body. It is responsible for stewardship of the Fedora Project as a whole, and supports the health and growth of the Fedora Community.<br />
<br />
The Council is composed of a mix of representatives from different areas of the project, named roles appointed by Red Hat, and a variable number of seats connected to medium-term project goals. Decisions are made by a '''consensus process''', in which we work together as a common team to find shared solutions and address concerns, with a focus on giving voice rather than on balance of power.<br />
<br />
The Council is ultimately accountable for the Fedora Project as a whole, and is responsible for providing advice to and oversight of other Fedora governance bodies and teams as needed.<br />
<br />
<br />
<br />
= Responsibilities =<br />
<br />
The Council is responsible for issues of strategic importance for Fedora that require leadership and coordination across the various teams and subprojects to achieve.<br />
<br />
'''Its primary role is to identify the short, medium, and long term goals of the Fedora community and to organize and enable the project to best achieve them.''' This is done in consultation with the entire Fedora community through transparent, public discussion.<br />
<br />
The Council '''governs Fedora's financial resources''', working with our sponsor(s) to establish an annual budget allocated to support Fedora initiatives, including Fedora Ambassadors, Fedora Premiere Events, and other activities which advance the project's goals.<br />
<br />
The Council also decides on issues regarding use of the Fedora '''trademarks''', is responsible for final '''arbitration of complaints''' related to project policies and for '''settling disputes''' escalated from other committees or subgroups, and may handle '''sensitive legal or personnel issues''' which require research and discussion to protect the interests of the Fedora Project or its sponsor(s).<br />
<br />
= Making Decisions =<br />
<br />
{{side box|<br />
Consensus decision-making aims to be:<br />
<br />
*'''Agreement Seeking:''' A consensus decision-making process attempts to help everyone get what they need.<br />
*'''Collaborative:''' Participants contribute to a shared proposal and shape it into a decision that meets the concerns of all group members as much as possible.<br />
*'''Cooperative:''' Participants in an effective consensus process should strive to reach the best possible decision for the group and all of its members, rather than competing for personal preferences.<br />
*'''Egalitarian:''' All members of a consensus decision-making body should be afforded, as much as possible, equal input into the process. All members have the opportunity to present, and amend proposals.<br />
*'''Inclusive:''' As many [[wiktionary:stakeholder|stakeholders]] as possible should be involved in the consensus decision-making process.<br />
*'''Participatory:''' The consensus process should actively solicit the input and participation of all decision-makers<br />
<br />
— from [https://en.wikipedia.org/wiki/Consensus_decision-making#Objectives Wikipedia on Consensus decision-making]<br />
<br />
}}<br />
Many basic decisions are made through a process known as &quot;'''lazy approval'''&quot;, in which general consent is assumed unless valid objections are raised within a period of time — generally three to seven days, although the timeframe should be stated each time and should be proportionate to the impact of the action. This process is used for decisions with short-term consequences and which can be easily reversed. Any project member can ask for the deadline to be extended or the decision escalated to require full consensus.<br />
<br />
More significant decisions are made through a process of '''full consensus'''. In order to pass, these decisions need three positive votes (+3) and ''no'' negative votes (-1). A negative vote immediately halts the process and requires discussion. Therefore, in order to remain valid, negative votes must be supported with a specific concerns about the poposal, and suggestions for what could be changed in order to make the proposal acceptable. A vote of &quot;0&quot; is sometimes used to indicate a disagreement but willingness to stand aside; this should also be accompanied with an explanation.<br />
<br />
This model matches Fedora's &quot;Friends&quot; foundation, which calls for finding acceptable consensus to serve the interests of advancing free software. It works because we work together in a community of mutual respect even when we disagree.<br />
<br />
In general, the Council conducts business in public discussion, and any Fedora project member can make negative or positive votes. It is the duty of the Council to take concerns raised in this way into serious consideration, but only Council members' votes are binding in the final tally.<br />
<br />
When consensus can't be reached, the Council may ask the Fedora Project Leader to decide on a resolution. Such a request can be made when issues leading to negative votes are outstanding and all Council members agree that the Council is deadlocked, or if the dispute is unresolved after fourteen days and a simple majority of Council members are in favor of the request.<br />
<br />
{{clear}}<br />
<br />
= Composition =<br />
<br />
== Objective Leads ==<br />
<br />
On an ongoing basis, including sessions at Flock and in public online meetings, the Council will identify two to four key community objectives with a timeframe of approximately eighteen months, and appoint '''Objective Leads''' for each goal. These will serve as auxiliary Council members, with binding votes only over concerns relevant to their particular area.<br />
<br />
Each objective will be documented with measurable goals, and the objective lead is responsible for coordinating efforts to reach those goals, evaluating and reporting on progress, and working regularly with all relevant groups in Fedora to ensure that progress is made.<br />
<br />
== Representatives ==<br />
<br />
The Council also includes four representative seats, an '''Engineering Representative''', an '''Outreach Representative''', and two '''Elected Representatives'''.<br />
<br />
&quot;Engineering&quot; and &quot;Outreach&quot; are broad areas roughly encompassing two of the major areas of activity in Fedora. ''Engineering'' is the technical work related to building and releasing the Fedora operating system and the infrastructure related to that. ''Outreach'' includes marketing, support, and Fedora Ambassadors — largely activities that happen between Fedora and the world at large, with the distribution release cycle serving as a fuel source, not the thing that's being worked on.<br />
<br />
The engineering and outreach representatives' responsibility is to represent their areas collectively, ''not'' to be just an individual voice that happens to be voted-in by some subset of Fedora. They are selected by the people active in those areas, coordinated by the Fedora Engineering Steering Committee (FESCo) and the Fedora Ambassadors Steering Committee (FAmSCo) respectively, and serve for terms to be determined by those committees.<br />
<br />
The elected positions cover Fedora's subprojects not under the engineering or outreach banners (Documentation, Translation, etc.), and the community at large. One specific responsibility is to represent the voice of individual contributors to the Fedora project. Each representative will also work on specific goals which she or he brings to the Council as highlighted during the election process.<br />
<br />
Elections are held twice a year, in concert with the joint Fedora election cycle. One seat is selected at each election, and each position has a two-election (approximately one year) term. No person who currently holds another Council seat can be elected. If a seat becomes vacant, the Council will arrange for a temporary replacement.<br />
<br />
== Appointed Leadership Positions ==<br />
<br />
'''Fedora Project Leader'''<br />
<br />
The Fedora Project Leader serves as the chair of the Council, organizing discussion agendas, bringing issues to the table, and facilitating the consensus process. He or she is accountable for success in all areas of the project, but is not a dictator, benevolent or otherwise. The FPL often serves as the public face and collective voice of the project, and has a corresponding duty to listen to, understand, and fairly represent the collective views and needs of project contributors and stakeholders.<br />
<br />
The Fedora Project Leader is hired by Red Hat with the advice and consent of the Council.<br />
<br />
'''Fedora Community Action and Impact Coordinator'''<br />
<br />
Red Hat's Open Source and Standards group funds a full-time position to lead initiatives to grow the Fedora user and developer communities, and to make Red Hat / Fedora interactions even more transparent and positive. The Fedora community budget comes to us through OSAS, and this position facilitates decision-making on how to best focus that to meet our collective objectives.<br />
<br />
== Auxiliary Seats ==<br />
<br />
As with the objective leads, the next two appointed positions are auxiliary seats. They are intended to have significant positive impact on the project as a whole, but in order to minimize the overall influence of appointed positions vs. those selected by the community, their votes in the consensus process are expected to be related to the scope of the respective role.<br />
<br />
'''Diversity Advisor'''<br />
<br />
Fedora's Diversity Advisor works on initiatives to assess and promote equality and inclusion within the Fedora contributor and user communities, and helps develop project strategy on diversity issues. Additionally, the Diversity Advisor administers and is the point of contact for Fedora's participation in third-party outreach programs and events.<br />
<br />
This position is appointed by the Fedora Project Leader, with the approval of the Council.<br />
<br />
'''Fedora Program Manager'''<br />
<br />
The FPgM coordinates the planning and scheduling of Fedora releases, and tracks changes and features during the development and testing cycle. He or she also assists with the creation, maintenance, and execution of formal, repeatable Fedora processes. Additionally, the FPgM serves as record keeper and secretary for Fedora Council Meetings.<br />
<br />
This position is funded by and hired for by Red Hat, with the approval of the Council.<br />
<br />
== Current Members ==<br />
<br />
<br />
* Elected Representative: '''Rex Dieter''' ''(f22, f23)''<br />
* Elected Representative: '''Langdon White''' ''(f22)''<br />
* Engineering Representative: '''Josh Boyer'''<br />
* Outreach Representative: '''Christoph Wickert'''<br />
* Fedora Project Leader: ''' Matthew Miller'''<br />
* Fedora Community Action and Impact Coordinator: '''Remy DeCausemaker'''<br />
* Fedora Program Manager: '''Jaroslav Reznik'''<br />
* Objective Lead: '''Stephen Gallagher'''<br />
<br />
== Contact Info ==<br />
The Fedora Council uses two mailing lists.<br />
<br />
'''{{fplist|council-discuss}}''' (formerly "board-discuss") is a public list. Subscription is open to anyone, as are the archives. This list is the main discussion point for the Fedora Council, and the goal of the list is to either reach a decision, or to delegate the thread to a more appropriate location. For example, engineering-specific threads may get some comments on council-discuss, before being redirected to the devel list for in-depth discussion.<br />
<br />
'''{{fplist|council-private}}''' is a private list. Its membership is restricted to the current Council members, and its archives are private. This list is only used for topics that cannot be discussed on the public council-discuss list.<br />
<br />
Council members are also often present on the '''#fedora-council''' IRC channel on '''irc.freenode.net'''<br />
<br />
If you have an issue to be worked on by the Council you can also open a ticket on the [https://fedorahosted.org/council/ Council trac instance]. This is a public issue tracker. If you have a particularly privacy- or security-sensitive issue, you may use the [https://fedorahosted.org/council-private/ council-private trac instance] instead. If an issue is not sensitive the discussion should be in the open, in the public trac or the council-discuss list.<br />
<br />
= Coda =<br />
<br />
== Meetings ==<br />
<br />
The Fedora Council is not driven by meetings or by tickets, but does hold semi-regular public IRC meetings to discuss current issues, to clear through anything outstanding which can be quickly resolved, and to ensure that nothing important is left in limbo. All members are be expected to regularly communicate what's going on in their area, through blog posts or other public updates.<br />
<br />
Additionally, the Fedora Project Leader will set aside regular times on IRC to meet with the community. Attendance is not mandatory for all members but is encouraged.<br />
<br />
== Transparency ==<br />
<br />
The general policy of the Fedora Council is to default to open. Meetings are held in public IRC channels, and open to all Fedora users and contributors. Discussion is held in on a [https://lists.fedoraproject.org/mailman/listinfo/council-discuss public mailing list] open to all subscribers, and formal decisions will be recorded in a public ticket tracking system.<br />
<br />
Occasionally, when personal, private, or sensitive issues need to be discussed, a phone call might be used. A private mailing list and ticket tracking instance also exist for these situations, but will also only be used when dealing with these uncommon issues.<br />
<br />
== Time Commitment ==<br />
<br />
Serving on the Fedora Council is a significant commitment of time and energy. Workload for the various roles will vary, but each will require a number of hours every week, and in most cases, the more, the better a Council member is able to do the job fully.<br />
<br />
We recognize that most Fedora community members do not have the luxury of working on Fedora full-time or as part of a paid position. The time commitment required for these roles comes simply from what is required to lead a large project like Fedora, and is not intended to be an artificial limit on who can participate. We know that that it can be a ''pragmatic'' limit, and for that reason, the Council is responsible for extra effort to receive, recognize, be responsive to, and meaningfully reward the input of contributors offering their individual time.<br />
<br />
== Governance Philosophy ==<br />
<br />
To advance free software, we need to provide a sustainable integration of free software without cutting corners. By providing a positive first impression before and during installation and real use, we support Fedora's reputation as a leading and reliable product that attracts future users and contributors. To provide that integration and experience we must have a clear set of priorities to help all contributors decide how to allocate resources and resolve conflicts. These priorities are not meant to be exclusive, or to keep contributors from working on the parts of Fedora that matter to them.<br />
<br />
These priorities will sometimes expose gaps where contributors need additional assistance, and allow them to seek it both within the community and by bringing in additional contributors to help, exclusively on their particular interest area if desired. While narrowing our focus in some areas, though, we must provide opportunities for exploration to all contributors within the framework of our core values and without impeding progress.<br />
<br />
== History ==<br />
<br />
The previous [[Board|previous governance structure (Fedora Board)]] had five members directly appointed by Red Hat and five elected at large. The current structure is more complicated but has a much greater proportion of members selected by the community by election or merit. In the previous board structure, the Fedora Project leader had a special veto power; in the current model, all voting members can block on issues, with a valid reason. The FPL does not have a special veto, but does have a limited power to "unstick" things if consensus genuinely can't be reached and a decision needs to be made.<br />
<br />
== Initial Selection of Elected Seats ==<br />
<br />
The initial elected representatives will be selected in a single election, with the candidate with the most votes selected for a full term (through the release of F23) and the runner-up for a half term (through the release of F22). As with the Fedora Board archive, we'll establish a history page and this paragraph will move to that page after the first election.<br />
<br />
== tl;dr? ==<br />
{{admon/important|<br />
# Active body tasked with identifying and enabling strategic objectives.<br />
# Handles governance issues like budget and project structure as well.<br />
# Consensus-based decision-making ensures that all voices are heard.<br />
# 6 members with full voting:<br />
#* 2 appointed by community for engineering and outreach project areas,<br />
#* 2 elected by community at large, and<br />
#* 2 appointed and paid by Red Hat (FPL and FCAI).<br />
<br />
# 4-6 members with binding votes in areas related to their role:<br />
#* 2-4 appointed by the Council<br />
#* 1 hired by Red Hat, and<br />
#* 1 appointed by the Council <br />
}}<br />
<br />
<br />
<br />
<br />
[[Category:Board]]<br />
[[Category:Fedora_leadership]]</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Council&diff=406223Council2015-03-11T15:18:25Z<p>Jwboyer: Add contact info</p>
<hr />
<div>{{message|This charter was approved by the Fedora Project Board on [https://fedorahosted.org/council/ticket/13 Oct. 9th, 2014] and is in effect as of Nov. 26th, 2014.}}<br />
<br />
[[File:Fedora_council.svg|right|500px]]<br />
<br />
= Introduction =<br />
<br />
The Fedora Council is our top-level community leadership and governance body. It is responsible for stewardship of the Fedora Project as a whole, and supports the health and growth of the Fedora Community.<br />
<br />
The Council is composed of a mix of representatives from different areas of the project, named roles appointed by Red Hat, and a variable number of seats connected to medium-term project goals. Decisions are made by a '''consensus process''', in which we work together as a common team to find shared solutions and address concerns, with a focus on giving voice rather than on balance of power.<br />
<br />
The Council is ultimately accountable for the Fedora Project as a whole, and is responsible for providing advice to and oversight of other Fedora governance bodies and teams as needed.<br />
<br />
<br />
<br />
= Responsibilities =<br />
<br />
The Council is responsible for issues of strategic importance for Fedora that require leadership and coordination across the various teams and subprojects to achieve.<br />
<br />
'''Its primary role is to identify the short, medium, and long term goals of the Fedora community and to organize and enable the project to best achieve them.''' This is done in consultation with the entire Fedora community through transparent, public discussion.<br />
<br />
The Council '''governs Fedora's financial resources''', working with our sponsor(s) to establish an annual budget allocated to support Fedora initiatives, including Fedora Ambassadors, Fedora Premiere Events, and other activities which advance the project's goals.<br />
<br />
The Council also decides on issues regarding use of the Fedora '''trademarks''', is responsible for final '''arbitration of complaints''' related to project policies and for '''settling disputes''' escalated from other committees or subgroups, and may handle '''sensitive legal or personnel issues''' which require research and discussion to protect the interests of the Fedora Project or its sponsor(s).<br />
<br />
= Making Decisions =<br />
<br />
{{side box|<br />
Consensus decision-making aims to be:<br />
<br />
*'''Agreement Seeking:''' A consensus decision-making process attempts to help everyone get what they need.<br />
*'''Collaborative:''' Participants contribute to a shared proposal and shape it into a decision that meets the concerns of all group members as much as possible.<br />
*'''Cooperative:''' Participants in an effective consensus process should strive to reach the best possible decision for the group and all of its members, rather than competing for personal preferences.<br />
*'''Egalitarian:''' All members of a consensus decision-making body should be afforded, as much as possible, equal input into the process. All members have the opportunity to present, and amend proposals.<br />
*'''Inclusive:''' As many [[wiktionary:stakeholder|stakeholders]] as possible should be involved in the consensus decision-making process.<br />
*'''Participatory:''' The consensus process should actively solicit the input and participation of all decision-makers<br />
<br />
— from [https://en.wikipedia.org/wiki/Consensus_decision-making#Objectives Wikipedia on Consensus decision-making]<br />
<br />
}}<br />
Many basic decisions are made through a process known as &quot;'''lazy approval'''&quot;, in which general consent is assumed unless valid objections are raised within a period of time — generally three to seven days, although the timeframe should be stated each time and should be proportionate to the impact of the action. This process is used for decisions with short-term consequences and which can be easily reversed. Any project member can ask for the deadline to be extended or the decision escalated to require full consensus.<br />
<br />
More significant decisions are made through a process of '''full consensus'''. In order to pass, these decisions need three positive votes (+3) and ''no'' negative votes (-1). A negative vote immediately halts the process and requires discussion. Therefore, in order to remain valid, negative votes must be supported with a specific concerns about the poposal, and suggestions for what could be changed in order to make the proposal acceptable. A vote of &quot;0&quot; is sometimes used to indicate a disagreement but willingness to stand aside; this should also be accompanied with an explanation.<br />
<br />
This model matches Fedora's &quot;Friends&quot; foundation, which calls for finding acceptable consensus to serve the interests of advancing free software. It works because we work together in a community of mutual respect even when we disagree.<br />
<br />
In general, the Council conducts business in public discussion, and any Fedora project member can make negative or positive votes. It is the duty of the Council to take concerns raised in this way into serious consideration, but only Council members' votes are binding in the final tally.<br />
<br />
When consensus can't be reached, the Council may ask the Fedora Project Leader to decide on a resolution. Such a request can be made when issues leading to negative votes are outstanding and all Council members agree that the Council is deadlocked, or if the dispute is unresolved after fourteen days and a simple majority of Council members are in favor of the request.<br />
<br />
{{clear}}<br />
<br />
= Composition =<br />
<br />
== Objective Leads ==<br />
<br />
On an ongoing basis, including sessions at Flock and in public online meetings, the Council will identify two to four key community objectives with a timeframe of approximately eighteen months, and appoint '''Objective Leads''' for each goal. These will serve as auxiliary Council members, with binding votes only over concerns relevant to their particular area.<br />
<br />
Each objective will be documented with measurable goals, and the objective lead is responsible for coordinating efforts to reach those goals, evaluating and reporting on progress, and working regularly with all relevant groups in Fedora to ensure that progress is made.<br />
<br />
== Representatives ==<br />
<br />
The Council also includes four representative seats, an '''Engineering Representative''', an '''Outreach Representative''', and two '''Elected Representatives'''.<br />
<br />
&quot;Engineering&quot; and &quot;Outreach&quot; are broad areas roughly encompassing two of the major areas of activity in Fedora. ''Engineering'' is the technical work related to building and releasing the Fedora operating system and the infrastructure related to that. ''Outreach'' includes marketing, support, and Fedora Ambassadors — largely activities that happen between Fedora and the world at large, with the distribution release cycle serving as a fuel source, not the thing that's being worked on.<br />
<br />
The engineering and outreach representatives' responsibility is to represent their areas collectively, ''not'' to be just an individual voice that happens to be voted-in by some subset of Fedora. They are selected by the people active in those areas, coordinated by the Fedora Engineering Steering Committee (FESCo) and the Fedora Ambassadors Steering Committee (FAmSCo) respectively, and serve for terms to be determined by those committees.<br />
<br />
The elected positions cover Fedora's subprojects not under the engineering or outreach banners (Documentation, Translation, etc.), and the community at large. One specific responsibility is to represent the voice of individual contributors to the Fedora project. Each representative will also work on specific goals which she or he brings to the Council as highlighted during the election process.<br />
<br />
Elections are held twice a year, in concert with the joint Fedora election cycle. One seat is selected at each election, and each position has a two-election (approximately one year) term. No person who currently holds another Council seat can be elected. If a seat becomes vacant, the Council will arrange for a temporary replacement.<br />
<br />
== Appointed Leadership Positions ==<br />
<br />
'''Fedora Project Leader'''<br />
<br />
The Fedora Project Leader serves as the chair of the Council, organizing discussion agendas, bringing issues to the table, and facilitating the consensus process. He or she is accountable for success in all areas of the project, but is not a dictator, benevolent or otherwise. The FPL often serves as the public face and collective voice of the project, and has a corresponding duty to listen to, understand, and fairly represent the collective views and needs of project contributors and stakeholders.<br />
<br />
The Fedora Project Leader is hired by Red Hat with the advice and consent of the Council.<br />
<br />
'''Fedora Community Action and Impact Coordinator'''<br />
<br />
Red Hat's Open Source and Standards group funds a full-time position to lead initiatives to grow the Fedora user and developer communities, and to make Red Hat / Fedora interactions even more transparent and positive. The Fedora community budget comes to us through OSAS, and this position facilitates decision-making on how to best focus that to meet our collective objectives.<br />
<br />
== Auxiliary Seats ==<br />
<br />
As with the objective leads, the next two appointed positions are auxiliary seats. They are intended to have significant positive impact on the project as a whole, but in order to minimize the overall influence of appointed positions vs. those selected by the community, their votes in the consensus process are expected to be related to the scope of the respective role.<br />
<br />
'''Diversity Advisor'''<br />
<br />
Fedora's Diversity Advisor works on initiatives to assess and promote equality and inclusion within the Fedora contributor and user communities, and helps develop project strategy on diversity issues. Additionally, the Diversity Advisor administers and is the point of contact for Fedora's participation in third-party outreach programs and events.<br />
<br />
This position is appointed by the Fedora Project Leader, with the approval of the Council.<br />
<br />
'''Fedora Program Manager'''<br />
<br />
The FPgM coordinates the planning and scheduling of Fedora releases, and tracks changes and features during the development and testing cycle. He or she also assists with the creation, maintenance, and execution of formal, repeatable Fedora processes. Additionally, the FPgM serves as record keeper and secretary for Fedora Council Meetings.<br />
<br />
This position is funded by and hired for by Red Hat, with the approval of the Council.<br />
<br />
== Current Members ==<br />
<br />
<br />
* Elected Representative: '''Rex Dieter''' ''(f22, f23)''<br />
* Elected Representative: '''Langdon White''' ''(f22)''<br />
* Engineering Representative: '''Josh Boyer'''<br />
* Outreach Representative: '''Christoph Wickert'''<br />
* Fedora Project Leader: ''' Matthew Miller'''<br />
* Fedora Community Action and Impact Coordinator: '''Remy DeCausemaker'''<br />
* Fedora Program Manager: '''Jaroslav Reznik'''<br />
* Objective Lead: '''Stephen Gallagher'''<br />
<br />
== Contact Info ==<br />
The Fedora Council uses two mailing lists.<br />
<br />
council-discuss (formerly "board-discuss") is a public list. Subscription is open to anyone, as are the archives. This list is the main discussion point for the Fedora Council, and the goal of the list is to either reach a decision, or to delegate the thread to a more appropriate location. For example, engineering-specific threads may get some comments on council-discuss, before being redirected to the devel list for in-depth discussion.<br />
<br />
council-private is a private list. Its membership is restricted to the current Council members, and its archives are private. This list is only used for topics that cannot be discussed on the public council-discuss list.<br />
<br />
Council members are also often present on the #fedora-council IRC channel on irc.freenode.net<br />
<br />
If you have an issue to be worked on by the Council you can also open a ticket on the Council trac instance. This is a public issue tracker. If you have a particularly privacy- or security-sensitive issue, you may use the council-private trac instance instead. If an issue is not sensitive the discussion should be in the open, in the public trac or the council-discuss list. <br />
<br />
= Coda =<br />
<br />
== Meetings ==<br />
<br />
The Fedora Council is not driven by meetings or by tickets, but does hold semi-regular public IRC meetings to discuss current issues, to clear through anything outstanding which can be quickly resolved, and to ensure that nothing important is left in limbo. All members are be expected to regularly communicate what's going on in their area, through blog posts or other public updates.<br />
<br />
Additionally, the Fedora Project Leader will set aside regular times on IRC to meet with the community. Attendance is not mandatory for all members but is encouraged.<br />
<br />
== Transparency ==<br />
<br />
The general policy of the Fedora Council is to default to open. Meetings are held in public IRC channels, and open to all Fedora users and contributors. Discussion is held in on a [https://lists.fedoraproject.org/mailman/listinfo/council-discuss public mailing list] open to all subscribers, and formal decisions will be recorded in a public ticket tracking system.<br />
<br />
Occasionally, when personal, private, or sensitive issues need to be discussed, a phone call might be used. A private mailing list and ticket tracking instance also exist for these situations, but will also only be used when dealing with these uncommon issues.<br />
<br />
== Time Commitment ==<br />
<br />
Serving on the Fedora Council is a significant commitment of time and energy. Workload for the various roles will vary, but each will require a number of hours every week, and in most cases, the more, the better a Council member is able to do the job fully.<br />
<br />
We recognize that most Fedora community members do not have the luxury of working on Fedora full-time or as part of a paid position. The time commitment required for these roles comes simply from what is required to lead a large project like Fedora, and is not intended to be an artificial limit on who can participate. We know that that it can be a ''pragmatic'' limit, and for that reason, the Council is responsible for extra effort to receive, recognize, be responsive to, and meaningfully reward the input of contributors offering their individual time.<br />
<br />
== Governance Philosophy ==<br />
<br />
To advance free software, we need to provide a sustainable integration of free software without cutting corners. By providing a positive first impression before and during installation and real use, we support Fedora's reputation as a leading and reliable product that attracts future users and contributors. To provide that integration and experience we must have a clear set of priorities to help all contributors decide how to allocate resources and resolve conflicts. These priorities are not meant to be exclusive, or to keep contributors from working on the parts of Fedora that matter to them.<br />
<br />
These priorities will sometimes expose gaps where contributors need additional assistance, and allow them to seek it both within the community and by bringing in additional contributors to help, exclusively on their particular interest area if desired. While narrowing our focus in some areas, though, we must provide opportunities for exploration to all contributors within the framework of our core values and without impeding progress.<br />
<br />
== History ==<br />
<br />
The previous [[Board|previous governance structure (Fedora Board)]] had five members directly appointed by Red Hat and five elected at large. The current structure is more complicated but has a much greater proportion of members selected by the community by election or merit. In the previous board structure, the Fedora Project leader had a special veto power; in the current model, all voting members can block on issues, with a valid reason. The FPL does not have a special veto, but does have a limited power to "unstick" things if consensus genuinely can't be reached and a decision needs to be made.<br />
<br />
== Initial Selection of Elected Seats ==<br />
<br />
The initial elected representatives will be selected in a single election, with the candidate with the most votes selected for a full term (through the release of F23) and the runner-up for a half term (through the release of F22). As with the Fedora Board archive, we'll establish a history page and this paragraph will move to that page after the first election.<br />
<br />
== tl;dr? ==<br />
{{admon/important|<br />
# Active body tasked with identifying and enabling strategic objectives.<br />
# Handles governance issues like budget and project structure as well.<br />
# Consensus-based decision-making ensures that all voices are heard.<br />
# 6 members with full voting:<br />
#* 2 appointed by community for engineering and outreach project areas,<br />
#* 2 elected by community at large, and<br />
#* 2 appointed and paid by Red Hat (FPL and FCAI).<br />
<br />
# 4-6 members with binding votes in areas related to their role:<br />
#* 2-4 appointed by the Council<br />
#* 1 hired by Red Hat, and<br />
#* 1 appointed by the Council <br />
}}<br />
<br />
<br />
<br />
<br />
[[Category:Board]]<br />
[[Category:Fedora_leadership]]</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=F22_Alpha_release_announcement&diff=405375F22 Alpha release announcement2015-03-04T16:21:28Z<p>Jwboyer: s/products/editions/ sigh.</p>
<hr />
<div>= Fedora 22 Alpha Release Announcement = <br />
<br />
The Fedora 22 Alpha release has arrived, with a preview of the latest free and open source technology under development. Take a peek inside! <br />
<br />
[http://fedoraproject.org/get-prerelease http://fedoraproject.org/get-prerelease]<br />
<br />
== What is the Alpha release? ==<br />
<br />
The Alpha release contains all the exciting features of Fedora 22's editions in a form that anyone can help test. This testing, guided by the [[QA|Fedora QA team]], helps us target and identify bugs. When these bugs are fixed, we make a Beta release available. A Beta release is code-complete and bears a very strong resemblance to the third and final release. The final release of Fedora 22 is [[Releases/22/Schedule|expected]] in May.<br />
<br />
We need your help to make Fedora 22 the best release yet, so please take some time to download and try out the Alpha and make sure the things that are important to you are working. If you find a bug, [[How_to_file_a_bug_report|please report it]] &ndash; every bug you uncover is a chance to improve the experience for millions of Fedora users worldwide. Together, we can make Fedora a rock-solid distribution. We have a culture of coordinating new features and pushing fixes [[Staying_close_to_upstream_projects|upstream]] as much as feasible and your feedback will help improve not only Fedora but Linux and free software on the whole. <br />
<br />
=== Fedora 22 Cloud ===<br />
* Atomic Host image for bare metal Project Atomic deployments.<br />
* Latest version of rpm-ostree and rpm-ostree-toolbox<br />
* Cloud and Atomic Vagrant boxes<br />
* A new CI tool called Tunir for rapid testing of cloud images<br />
<br />
=== Fedora 22 Server ===<br />
* The rolekit package has been updated to include support for creating a Database Server Role<br />
* The cockpit package has been updated to the latest upstream release which adds many new features as well as a modular design for adding new functionality.<br />
<br />
=== Fedora 22 Workstation ===<br />
''NOTE: This is just a tracking list, but will be fleshed out in the next day or two, in plenty of time for the announcement. --[[User:Pfrields|pfrields]] ([[User talk:Pfrields|talk]]) 13:53, 4 March 2015 (UTC)''<br />
Enhancements:<br />
* Notification improvements<br />
* Terminal - long running job notifications<br />
* Wayland - login screen running on Wayland, input configuration works<br />
* Software - codec installation in totem<br />
* ABRT - better notifications, uses privacy panel<br />
Appearance:<br />
* Nautilus - UI improvements<br />
* GNOME Shell - fresh theme<br />
* Qt/Adwaita theme done<br />
* Qt notifications?<br />
Under the covers<br />
* Use libinput for both X11 and Wayland<br />
<br />
=== Spins ===<br />
* Plasma 5, the successor to KDE Plasma 4, is now the default workspace in the Fedora KDE spin<br />
<br />
== Issues and Details ==<br />
<br />
This is an Alpha release. As such, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the {{fplist|test}} mailing list or in #fedora-qa on freenode.<br />
<br />
As testing progresses, common issues are tracked on the [[Common_F22_bugs|Common F22 Bugs]] page.<br />
<br />
For tips on reporting a bug effectively, read "[[How_to_file_a_bug_report|how to file a bug report]]."<br />
<br />
== Release Schedule ==<br />
<br />
The [[Releases/22/Schedule|full release schedule]] is available on the Fedora wiki. The current schedule calls for a beta release in the middle of April, and a final release in the second half of May.<br />
<br />
These dates are subject to change, pending any major bugs or issues found during the development process.</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=Council&diff=404793Council2015-02-25T20:15:59Z<p>Jwboyer: Add Remy. LOL at the title length.</p>
<hr />
<div>{{message|This charter was approved by the Fedora Project Board on [https://fedorahosted.org/council/ticket/13 Oct. 9th, 2014] and is in effect as of Nov. 26th, 2014.}}<br />
<br />
[[File:Fedora_council.svg|right|500px]]<br />
<br />
= Introduction =<br />
<br />
The Fedora Council is our top-level community leadership and governance body. It is responsible for stewardship of the Fedora Project as a whole, and supports the health and growth of the Fedora Community.<br />
<br />
The Council is composed of a mix of representatives from different areas of the project, named roles appointed by Red Hat, and a variable number of seats connected to medium-term project goals. Decisions are made by a '''consensus process''', in which we work together as a common team to find shared solutions and address concerns, with a focus on giving voice rather than on balance of power.<br />
<br />
The Council is ultimately accountable for the Fedora Project as a whole, and is responsible for providing advice to and oversight of other Fedora governance bodies and teams as needed.<br />
<br />
<br />
<br />
= Responsibilities =<br />
<br />
The Council is responsible for issues of strategic importance for Fedora that require leadership and coordination across the various teams and subprojects to achieve.<br />
<br />
'''Its primary role is to identify the short, medium, and long term goals of the Fedora community and to organize and enable the project to best achieve them.''' This is done in consultation with the entire Fedora community through transparent, public discussion.<br />
<br />
The Council '''governs Fedora's financial resources''', working with our sponsor(s) to establish an annual budget allocated to support Fedora initiatives, including Fedora Ambassadors, Fedora Premiere Events, and other activities which advance the project's goals.<br />
<br />
The Council also decides on issues regarding use of the Fedora '''trademarks''', is responsible for final '''arbitration of complaints''' related to project policies and for '''settling disputes''' escalated from other committees or subgroups, and may handle '''sensitive legal or personnel issues''' which require research and discussion to protect the interests of the Fedora Project or its sponsor(s).<br />
<br />
= Making Decisions =<br />
<br />
{{side box|<br />
Consensus decision-making aims to be:<br />
<br />
*'''Agreement Seeking:''' A consensus decision-making process attempts to help everyone get what they need.<br />
*'''Collaborative:''' Participants contribute to a shared proposal and shape it into a decision that meets the concerns of all group members as much as possible.<br />
*'''Cooperative:''' Participants in an effective consensus process should strive to reach the best possible decision for the group and all of its members, rather than competing for personal preferences.<br />
*'''Egalitarian:''' All members of a consensus decision-making body should be afforded, as much as possible, equal input into the process. All members have the opportunity to present, and amend proposals.<br />
*'''Inclusive:''' As many [[wiktionary:stakeholder|stakeholders]] as possible should be involved in the consensus decision-making process.<br />
*'''Participatory:''' The consensus process should actively solicit the input and participation of all decision-makers<br />
<br />
— from [https://en.wikipedia.org/wiki/Consensus_decision-making#Objectives Wikipedia on Consensus decision-making]<br />
<br />
}}<br />
Many basic decisions are made through a process known as &quot;'''lazy approval'''&quot;, in which general consent is assumed unless valid objections are raised within a period of time — generally three to seven days, although the timeframe should be stated each time and should be proportionate to the impact of the action. This process is used for decisions with short-term consequences and which can be easily reversed. Any project member can ask for the deadline to be extended or the decision escalated to require full consensus.<br />
<br />
More significant decisions are made through a process of '''full consensus'''. In order to pass, these decisions need three positive votes (+3) and ''no'' negative votes (-1). A negative vote immediately halts the process and requires discussion. Therefore, in order to remain valid, negative votes must be supported with a specific concerns about the poposal, and suggestions for what could be changed in order to make the proposal acceptable. A vote of &quot;0&quot; is sometimes used to indicate a disagreement but willingness to stand aside; this should also be accompanied with an explanation.<br />
<br />
This model matches Fedora's &quot;Friends&quot; foundation, which calls for finding acceptable consensus to serve the interests of advancing free software. It works because we work together in a community of mutual respect even when we disagree.<br />
<br />
In general, the Council conducts business in public discussion, and any Fedora project member can make negative or positive votes. It is the duty of the Council to take concerns raised in this way into serious consideration, but only Council members' votes are binding in the final tally.<br />
<br />
When consensus can't be reached, the Council may ask the Fedora Project Leader to decide on a resolution. Such a request can be made when issues leading to negative votes are outstanding and all Council members agree that the Council is deadlocked, or if the dispute is unresolved after fourteen days and a simple majority of Council members are in favor of the request.<br />
<br />
{{clear}}<br />
<br />
= Composition =<br />
<br />
== Objective Leads ==<br />
<br />
On an ongoing basis, including sessions at Flock and in public online meetings, the Council will identify two to four key community objectives with a timeframe of approximately eighteen months, and appoint '''Objective Leads''' for each goal. These will serve as auxiliary Council members, with binding votes only over concerns relevant to their particular area.<br />
<br />
Each objective will be documented with measurable goals, and the objective lead is responsible for coordinating efforts to reach those goals, evaluating and reporting on progress, and working regularly with all relevant groups in Fedora to ensure that progress is made.<br />
<br />
== Representatives ==<br />
<br />
The Council also includes four representative seats, an '''Engineering Representative''', an '''Outreach Representative''', and two '''Elected Representatives'''.<br />
<br />
&quot;Engineering&quot; and &quot;Outreach&quot; are broad areas roughly encompassing two of the major areas of activity in Fedora. ''Engineering'' is the technical work related to building and releasing the Fedora operating system and the infrastructure related to that. ''Outreach'' includes marketing, support, and Fedora Ambassadors — largely activities that happen between Fedora and the world at large, with the distribution release cycle serving as a fuel source, not the thing that's being worked on.<br />
<br />
The engineering and outreach representatives' responsibility is to represent their areas collectively, ''not'' to be just an individual voice that happens to be voted-in by some subset of Fedora. They are selected by the people active in those areas, coordinated by the Fedora Engineering Steering Committee (FESCo) and the Fedora Ambassadors Steering Committee (FAmSCo) respectively, and serve for terms to be determined by those committees.<br />
<br />
The elected positions cover Fedora's subprojects not under the engineering or outreach banners (Documentation, Translation, etc.), and the community at large. One specific responsibility is to represent the voice of individual contributors to the Fedora project. Each representative will also work on specific goals which she or he brings to the Council as highlighted during the election process.<br />
<br />
Elections are held twice a year, in concert with the joint Fedora election cycle. One seat is selected at each election, and each position has a two-election (approximately one year) term. No person who currently holds another Council seat can be elected. If a seat becomes vacant, the Council will arrange for a temporary replacement.<br />
<br />
== Appointed Leadership Positions ==<br />
<br />
'''Fedora Project Leader'''<br />
<br />
The Fedora Project Leader serves as the chair of the Council, organizing discussion agendas, bringing issues to the table, and facilitating the consensus process. He or she is accountable for success in all areas of the project, but is not a dictator, benevolent or otherwise. The FPL often serves as the public face and collective voice of the project, and has a corresponding duty to listen to, understand, and fairly represent the collective views and needs of project contributors and stakeholders.<br />
<br />
The Fedora Project Leader is hired by Red Hat with the advice and consent of the Council.<br />
<br />
'''Fedora Community Action and Impact Coordinator'''<br />
<br />
Red Hat's Open Source and Standards group funds a full-time position to lead initiatives to grow the Fedora user and developer communities, and to make Red Hat / Fedora interactions even more transparent and positive. The Fedora community budget comes to us through OSAS, and this position facilitates decision-making on how to best focus that to meet our collective objectives.<br />
<br />
== Auxiliary Seats ==<br />
<br />
As with the objective leads, the next two appointed positions are auxiliary seats. They are intended to have significant positive impact on the project as a whole, but in order to minimize the overall influence of appointed positions vs. those selected by the community, their votes in the consensus process are expected to be related to the scope of the respective role.<br />
<br />
'''Diversity Advisor'''<br />
<br />
Fedora's Diversity Advisor works on initiatives to assess and promote equality and inclusion within the Fedora contributor and user communities, and helps develop project strategy on diversity issues. Additionally, the Diversity Advisor administers and is the point of contact for Fedora's participation in third-party outreach programs and events.<br />
<br />
This position is appointed by the Fedora Project Leader, with the approval of the Council.<br />
<br />
'''Fedora Program Manager'''<br />
<br />
The FPgM coordinates the planning and scheduling of Fedora releases, and tracks changes and features during the development and testing cycle. He or she also assists with the creation, maintenance, and execution of formal, repeatable Fedora processes. Additionally, the FPgM serves as record keeper and secretary for Fedora Council Meetings.<br />
<br />
This position is funded by and hired for by Red Hat, with the approval of the Council.<br />
<br />
== Current Members ==<br />
<br />
<br />
* Elected Representative: '''Rex Dieter''' ''(f22, f23)''<br />
* Elected Representative: '''Langdon White''' ''(f22)''<br />
* Engineering Representative: '''Josh Boyer'''<br />
* Outreach Representative: '''Christoph Wickert'''<br />
* Fedora Project Leader: ''' Matthew Miller'''<br />
* Fedora Community Action and Impact Coordinator: '''Remy DeCausemaker'''<br />
* Fedora Program Manager: '''Jaroslav Reznik'''<br />
* Objective Lead: '''Stephen Gallagher'''<br />
<br />
= Coda =<br />
<br />
== Meetings ==<br />
<br />
The Fedora Council is not driven by meetings or by tickets, but does hold semi-regular public IRC meetings to discuss current issues, to clear through anything outstanding which can be quickly resolved, and to ensure that nothing important is left in limbo. All members are be expected to regularly communicate what's going on in their area, through blog posts or other public updates.<br />
<br />
Additionally, the Fedora Project Leader will set aside regular times on IRC to meet with the community. Attendance is not mandatory for all members but is encouraged.<br />
<br />
== Transparency ==<br />
<br />
The general policy of the Fedora Council is to default to open. Meetings are held in public IRC channels, and open to all Fedora users and contributors. Discussion is held in on a [https://lists.fedoraproject.org/mailman/listinfo/council-discuss public mailing list] open to all subscribers, and formal decisions will be recorded in a public ticket tracking system.<br />
<br />
Occasionally, when personal, private, or sensitive issues need to be discussed, a phone call might be used. A private mailing list and ticket tracking instance also exist for these situations, but will also only be used when dealing with these uncommon issues.<br />
<br />
== Time Commitment ==<br />
<br />
Serving on the Fedora Council is a significant commitment of time and energy. Workload for the various roles will vary, but each will require a number of hours every week, and in most cases, the more, the better a Council member is able to do the job fully.<br />
<br />
We recognize that most Fedora community members do not have the luxury of working on Fedora full-time or as part of a paid position. The time commitment required for these roles comes simply from what is required to lead a large project like Fedora, and is not intended to be an artificial limit on who can participate. We know that that it can be a ''pragmatic'' limit, and for that reason, the Council is responsible for extra effort to receive, recognize, be responsive to, and meaningfully reward the input of contributors offering their individual time.<br />
<br />
== Governance Philosophy ==<br />
<br />
To advance free software, we need to provide a sustainable integration of free software without cutting corners. By providing a positive first impression before and during installation and real use, we support Fedora's reputation as a leading and reliable product that attracts future users and contributors. To provide that integration and experience we must have a clear set of priorities to help all contributors decide how to allocate resources and resolve conflicts. These priorities are not meant to be exclusive, or to keep contributors from working on the parts of Fedora that matter to them.<br />
<br />
These priorities will sometimes expose gaps where contributors need additional assistance, and allow them to seek it both within the community and by bringing in additional contributors to help, exclusively on their particular interest area if desired. While narrowing our focus in some areas, though, we must provide opportunities for exploration to all contributors within the framework of our core values and without impeding progress.<br />
<br />
== History ==<br />
<br />
The previous [[Board|previous governance structure (Fedora Board)]] had five members directly appointed by Red Hat and five elected at large. The current structure is more complicated but has a much greater proportion of members selected by the community by election or merit. In the previous board structure, the Fedora Project leader had a special veto power; in the current model, all voting members can block on issues, with a valid reason. The FPL does not have a special veto, but does have a limited power to "unstick" things if consensus genuinely can't be reached and a decision needs to be made.<br />
<br />
== Initial Selection of Elected Seats ==<br />
<br />
The initial elected representatives will be selected in a single election, with the candidate with the most votes selected for a full term (through the release of F23) and the runner-up for a half term (through the release of F22). As with the Fedora Board archive, we'll establish a history page and this paragraph will move to that page after the first election.<br />
<br />
== tl;dr? ==<br />
{{admon/important|<br />
# Active body tasked with identifying and enabling strategic objectives.<br />
# Handles governance issues like budget and project structure as well.<br />
# Consensus-based decision-making ensures that all voices are heard.<br />
# 6 members with full voting:<br />
#* 2 appointed by community for engineering and outreach project areas,<br />
#* 2 elected by community at large, and<br />
#* 2 appointed and paid by Red Hat (FPL and FCAI).<br />
<br />
# 4-6 members with binding votes in areas related to their role:<br />
#* 2-4 appointed by the Council<br />
#* 1 hired by Red Hat, and<br />
#* 1 appointed by the Council <br />
}}<br />
<br />
<br />
<br />
<br />
[[Category:Board]]<br />
[[Category:Fedora_leadership]]</div>Jwboyerhttps://fedoraproject.org/w/index.php?title=User:Pfrields/DevConf.cz_2015_travel&diff=398940User:Pfrields/DevConf.cz 2015 travel2014-12-19T18:14:29Z<p>Jwboyer: /* Attendees from Fedora Engineering */</p>
<hr />
<div>== Attendees from [[Fedora Engineering]] ==<br />
<br />
{|<br />
! Name !! Arrival !! Departure !! [http://goo.gl/forms/TBt4YURXjd Hotel signup] !! Notes<br />
|-<br />
| Josh Boyer || 2015-Feb-05, PRG 13:30 (DL9533) || 2015-Feb-09, PRG 06:50 (DL 9597) || Y || Roomshare Paul <br />
|-<br />
| Pierre-Yves Chibon || || || || Roomshare Patrick<br />
|-<br />
| Kushal Das || 2015-Feb-05, PRG 09:45 (LH 1688) || 2015-Feb-10, PRG 09:45 (LH 1689) || || Roomshare TBA (DevConf staff)<br />
|-<br />
| Paul Frields || 2015-Feb-02, PRG 13:30 (DL 9533) || 2015-Feb-10, PRG 09:30 (DL 9504) || Y || Roomshare Josh<br />
|-<br />
| Patrick Uiterwijk || 2015-Feb-05, PRG 13:30 (KL 1355) || 2015-Feb-09, PRG 15:50 (AF 1983) || Y || Room share Pierre<br />
|}<br />
<br />
== Other Info / Plans ==<br />
<br />
* Patrick/Simo: Federated Identity Providers: the Ipsilon project - Fri 2015-Feb-06, 10:40-11:20 Room D206<br />
* Patrick: How do I implement centralized authentication? - Sat 2015-Feb-07, 09:00-09:40 Room E105<br />
* Paul: Fedora Workstation Roadmap - Sun 2015-Feb-08, 09:50-10:30 Room D105<br />
* List other scheduled talks here...</div>Jwboyer