https://fedoraproject.org/w/api.php?action=feedcontributions&user=Ausil&feedformat=atomFedora Project Wiki - User contributions [en]2024-03-19T01:46:38ZUser contributionsMediaWiki 1.39.4https://fedoraproject.org/w/index.php?title=Thinkpad_X13s&diff=698431Thinkpad X13s2024-01-10T17:35:58Z<p>Ausil: update steps for modem unlocking</p>
<hr />
<div>Page to keep track of Linux support development for Thinkpad X13s (SoC codename sc8280xp), the first Thinkpad with ARM CPU.<br />
<br />
Most of the following information comes from #aarch64-laptops on OFTC, #fedora-arm on Libera.chat and arm[AT]lists.fedoraproject.org. Upstream information changes daily, so this page may be outdated.<br />
<br />
==== Bootable images ====<br />
Fedora Rawhide images are bootable as of the 15th of December, 2023, with some additional user interaction.<br />
* The kernel must be booted with `arm64.nopauth clk_ignore_unused pd_ignore_unused rd.driver.blacklist=msm`<br />
* A recent firmware must be on the machine, and the linux/DT mode must be selected in the FW menus.<br />
** Recommend minimum version:<br />
*** Version: N3HET84W (1.56 )<br />
* A 6.5 or newer device tree must be placed on the ESP of the internal NVMe disk and named sc8280xp-lenovo-thinkpad-x13s.dtb<br />
** ex: /boot/efi/sc8280xp-lenovo-thinkpad-x13s.dtb<br />
** As a workaround, add a devicetree line in grub to load the DTB until it can be put in place on the ESP<br />
** [https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s#Install_Device_Tree_Blob_on_the_EFI_System_Partition Debian has instructions on how to do this from windows]<br />
* To boot from USB, `modprobe.blacklist=qcom_q6v5_pas` must be added to the boot arguments. This keeps the USB from being reset and the storage device from being renamed mid-boot.<br />
<br />
*Once the system is running, installing the [https://copr.fedorainfracloud.org/coprs/jlinton/x13s/ x13s copr], will pull in the remaining dependencies and correct a few configuration items:<br />
** <pre>dnf copr enable jlinton/x13s; dnf install x13s</pre><br />
*** Reboot<br />
<br />
* After major kernel updates, it is probably wise for the time being to run<br />
** <pre>cp /boot/dtb-`uname -r`/qcom/sc8280xp-lenovo-thinkpad-x13s.dtb /boot/efi </pre><br />
<br />
==== Known Problems ====<br />
* Audio works but is quiet<br />
* TPM support is missing<br />
* 5G Modem <br />
** Need to have ModemManager-1.22.0-1.fc40.aarch64 or newer installed, then follow the [https://modemmanager.org/docs/modemmanager/fcc-unlock/ documented] steps to unlock the modem<br />
* Virtualization is not yet available. The UEFI is not yet exposing [https://developer.arm.com/documentation/102412/0102/Privilege-and-Exception-levels the EL2 (exception level)], which is required to run VMs<br />
* The system does not suspend correctly so you need to poweroff if leaving unused <br />
<br />
<br />
==== Similar pages ====<br />
* https://github.com/jhovold/linux/wiki/X13s<br />
* https://github.com/ironrobin/archiso-x13s/wiki/Feature-Support<br />
* https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s<br />
* https://en.opensuse.org/HCL:ThinkpadX13s</div>Ausilhttps://fedoraproject.org/w/index.php?title=Thinkpad_X13s&diff=698068Thinkpad X13s2024-01-03T18:20:46Z<p>Ausil: </p>
<hr />
<div>Page to keep track of Linux support development for Thinkpad X13s (SoC codename sc8280xp), the first Thinkpad with ARM CPU.<br />
<br />
Most of the following information comes from #aarch64-laptops on OFTC, #fedora-arm on Libera.chat and arm[AT]lists.fedoraproject.org. Upstream information changes daily, so this page may be outdated.<br />
<br />
==== Bootable images ====<br />
Fedora Rawhide images are bootable as of the 15th of December, 2023, with some additional user interaction.<br />
* The kernel must be booted with `arm64.nopauth clk_ignore_unused pd_ignore_unused rd.driver.blacklist=msm`<br />
* A recent firmware must be on the machine, and the linux/DT mode must be selected in the FW menus.<br />
** Recommend minimum version:<br />
*** Version: N3HET84W (1.56 )<br />
* A 6.5 or newer device tree must be placed on the ESP of the internal NVMe disk and named sc8280xp-lenovo-thinkpad-x13s.dtb<br />
** ex: /boot/efi/sc8280xp-lenovo-thinkpad-x13s.dtb<br />
** As a workaround, add a devicetree line in grub to load the DTB until it can be put in place on the ESP<br />
** [https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s#Install_Device_Tree_Blob_on_the_EFI_System_Partition Debian has instructions on how to do this from windows]<br />
* To boot from USB, `modprobe.blacklist=qcom_q6v5_pas` must be added to the boot arguments. This keeps the USB from being reset and the storage device from being renamed mid-boot.<br />
<br />
*Once the system is running, installing the [https://copr.fedorainfracloud.org/coprs/jlinton/x13s/ x13s copr], will pull in the remaining dependencies and correct a few configuration items:<br />
** <pre>dnf copr enable jlinton/x13s; dnf install x13s</pre><br />
*** Reboot<br />
<br />
* After major kernel updates, it is probably wise for the time being to run<br />
** <pre>cp /boot/dtb-`uname -r`/qcom/sc8280xp-lenovo-thinkpad-x13s.dtb /boot/efi </pre><br />
<br />
==== Known Problems ====<br />
* Audio works but is quiet<br />
* TPM support is missing<br />
* 5G Modem <br />
** While waiting on a new release of ModemManager we can take the following steps<br />
<pre><br />
sudo ln -s 105b /usr/share/ModemManager/fcc-unlock.available.d/105b\:e0c3<br />
sudo mkdir -p /etc/ModemManager/fcc-unlock.d<br />
sudo ln -sft /etc/ModemManager/fcc-unlock.d /usr/share/ModemManager/fcc-unlock.available.d/*<br />
</pre><br />
* Virtualization is not yet available. The UEFI is not yet exposing [https://developer.arm.com/documentation/102412/0102/Privilege-and-Exception-levels the EL2 (exception level)], which is required to run VMs<br />
* The system does not suspend correctly so you need to poweroff if leaving unused <br />
<br />
<br />
==== Similar pages ====<br />
* https://github.com/ironrobin/archiso-x13s/wiki/Feature-Support<br />
* https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s<br />
* https://en.opensuse.org/HCL:ThinkpadX13s</div>Ausilhttps://fedoraproject.org/w/index.php?title=Thinkpad_X13s&diff=697020Thinkpad X13s2023-12-17T22:43:00Z<p>Ausil: update now that rawhide is bootable without filesystem modifications</p>
<hr />
<div>Page to keep track of Linux support development for Thinkpad X13s (SoC codename sc8280xp), the first Thinkpad with ARM CPU.<br />
<br />
Most of following informations come from #aarch64-laptops on OFTC, #fedora-arm on Libera.chat and arm[AT]lists.fedoraproject.org. Upstream infos change on daily basis, so this page may be outdated, therefore read it with pinch of salt / cum grano salis.<br />
<br />
==== Bootable images ====<br />
Fedora Rawhide images are bootable as of the 15th of December, 2023. There are, unfortunately some boot arguments that need to be added to boot successfully<br />
* The kernel must be booted with `arm64.nopauth clk_ignore_unused pd_ignore_unused rd.driver.blacklist=msm`<br />
* A recent firmware must be on the machine, and the linux/DT mode must be selected in the FW menus.<br />
** Recommend minimum version:<br />
*** Version: N3HET84W (1.56 )<br />
* A 6.5 or newer device tree must be placed on the ESP of the internal NVMe disk and named sc8280xp-lenovo-thinkpad-x13s.dtb<br />
** ex: /boot/efi/sc8280xp-lenovo-thinkpad-x13s.dtb<br />
** as a workaround you can add a devicetree line in grub to load the dtb until it can be put in place on the ESP<br />
* to boot from USB you need to add `modprobe.blacklist=qcom_q6v5_pas` to the boot arguments, this keeps the USB from being reset and the storage device being renamed mid boot.<br />
<br />
Once the system is installed you need to install pd-mapper and enable the pd-mapper service to get battery charge reporting working <br />
* `sudo dnf install -y pd-mapper; sudo systemctl enable --now pd-mapper.service`<br />
** Charging may not work at all though any number of USB-C hubs<br />
Anaconda persists module.blacklist boot arguments to the installed system in order for pd-mapper to run properly we need to remove `/etc/modprobe.d/anaconda-denylist.conf` and regenerate the initrd with `sudo dracut-f` to enable qcom_q6v5_pas to be loaded automatically. <br />
* Audio works but is quiet<br />
* TPM support is missing<br />
* Try the https://fedoraproject.org/wiki/Thinkpad_X13s#Similar_pages link to get a few more things working.<br />
==== Bluetooth ====<br />
By default there is no Bluetooth mac address set. You can manually set an address with btmgmt. e.g., `sudo btmgmt public-addr F4:A8:0D:30:A3:47`<br />
<br />
To make it just work, copy this file to `/etc/systemd/system/bluetooth.service.d/override.conf` (It is courteous to use your own public-addr, put a random string of numbers to make it unique.)<br />
<br />
<pre><br />
[Service]<br />
ExecStartPre=/bin/bash -c 'sleep 5 && yes | btmgmt public-addr 00:24:81:17:62:36'<br />
# Blank ExecStart line to clear the service file, overrides are additive.<br />
ExecStart=<br />
ExecStart=/usr/lib/bluetooth/bluetoothd<br />
</pre><br />
==== Touch Screen ====<br />
There is some probe defer issue to get touch screen bound to i2c_hid_of driver. To workaround temporarily run `sudo echo 4-0010 > /sys/bus/i2c/drivers/i2c_hid_of/bind` to make it persit install the file at https://github.com/ironrobin/x13s-alarm/blob/trunk/x13s-touchscreen-udev/72-x13s-touchscreen.rules in `/etc/udev/rules.d/`<br />
==== 5G Modem ====<br />
While waiting on a new release of ModemManager we can take the following steps<br />
<pre><br />
sudo ln -s 105b /usr/share/ModemManager/fcc-unlock.available.d/105b\:e0c3<br />
sudo mkdir -p /etc/ModemManager/fcc-unlock.d<br />
sudo ln -sft /etc/ModemManager/fcc-unlock.d /usr/share/ModemManager/fcc-unlock.available.d/*<br />
</pre><br />
==== Virtualization ====<br />
Virtualization is not yet available. The UEFI is not yet exposing [https://developer.arm.com/documentation/102412/0102/Privilege-and-Exception-levels the EL2 (exception level)] which is required to run VMs<br />
<br />
==== Webcam ====<br />
Not working<br />
<br />
==== Similar pages ====<br />
https://github.com/ironrobin/archiso-x13s/wiki/Feature-Support</div>Ausilhttps://fedoraproject.org/w/index.php?title=Thinkpad_X13s&diff=690088Thinkpad X13s2023-09-24T23:04:26Z<p>Ausil: update that GPU firmware is correctly handled as of linux kernel 6.5.3</p>
<hr />
<div>Page to keep track of Linux support development for Thinkpad X13s (SoC codename sc8280xp), the first Thinkpad with ARM CPU.<br />
<br />
Most of following informations come from #aarch64-laptops on OFTC, #fedora-arm on Libera.chat and arm[AT]lists.fedoraproject.org. Upstream infos change on daily basis, so this page may be outdated, therefore read it with pinch of salt / cum grano salis.<br />
<br />
==== Bootable images ====<br />
Fedora developers are aiming for it being supportable/usable in time for Fedora 38, at some point before that, some consumable images will be released for testing.<br />
<br />
A Linaro's Debian image is available at [https://forums.lenovo.com/t5/Other-Linux-Discussions/Does-anybody-know-if-there-is-work-being-done-to-integrate-X13s-ARM-processor-with-linux/m-p/5175315?page=1#5771660 this link]. It provides a decent user experience, despite missing audio and suspension capabilities.<br />
Power usage not yet optimized, so expect high battery drain<br />
<br />
==== Kernel development ====<br />
Some of work on the kernel can be seen in https://github.com/jhovold/linux repository, branches wip/sc8280xp<br />
<br />
==== GPU ====<br />
GPU hardware acceleration not yet available<br />
<br />
==== Sound ====<br />
Kernel side implementation at [https://lore.kernel.org/lkml/20221121130403.161817-3-srinivas.kandagatla@linaro.org/T/ this link]<br />
Userland code still to be implemented<br />
<br />
==== Virtualization ====<br />
Virtualization is not yet available. The UEFI is not yet exposing [https://developer.arm.com/documentation/102412/0102/Privilege-and-Exception-levels the EL2 (exception level)] which is required to run VMs<br />
<br />
==== Webcam ====<br />
Not working<br />
<br />
==== Wi-Fi ====<br />
Working<br />
<br />
==== Similar pages ====<br />
https://github.com/ironrobin/archiso-x13s/wiki/Feature-Support<br />
<br />
==== Rawhide hacking ====<br />
As of the 6.5RC series, official rawhide will boot given the following changes:<br />
* <strike>Grub2 must have this patch applied https://src.fedoraproject.org/rpms/grub2/pull-request/27</strike> Should be in rawhide now, assure grub2 >= 2.06-100<br />
* The kernel must be booted with 'arm64.nopauth clk_ignore_unused pd_ignore_unused` <br />
* A recent firmware must be on the machine, and the linux/DT mode must be selected in the FW menus.<br />
** Recommend minimum version:<br />
*** Version: N3HET84W (1.56 )<br />
*** Release Date: 06/26/2023<br />
* A 6.5 device tree must be placed on the ESP of the internal NVMe disk and named sc8280xp-lenovo-thinkpad-x13s.dtb<br />
** ex: /boot/efi/sc8280xp-lenovo-thinkpad-x13s.dtb<br />
* USB boot is possible if qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn is removed from the USB boot image<br />
** And add_drivers+=" qrtr " is added during initrd build<br />
** Otherwise leave it alone if booting from NVMe<br />
* GPU firmware is provided in fedora as of kernel 6.5.3<br />
* <strike>Appropriate GPU firmware is placed in /lib/firmware/qcom/a660_sqe.fw, and /lib/firmware/qcom/a690_gmu.bin </strike><br />
** <strike>Acquire from: https://github.com/ironrobin/x13s-alarm/tree/trunk/x13s-firmware</strike><br />
* Due to the mainline nature of this kernel the following things may not work correctly:<br />
** Battery monitor in gnome<br />
*** Install the latest, pd-mapper https://github.com/andersson/pd-mapper, and qrtr-ns https://github.com/andersson/qrtr to fix this.<br />
** Proper USB-C charging negotiation, may result in slow charging, or battery drain while plugged in.<br />
*** Charging may not work at all though any number of USB-C hubs<br />
*** Make sure pd-mapper is installed to fix some of the more glaring problems.<br />
** Keyboard rollover<br />
** Bluetooth<br />
** CPU cache size reporting<br />
** Keyboard LEDs (depends on HW revision?, fn-f1 may enable the mute + capslock at which point both leds will be toggled by caps lock)<br />
** Audio<br />
** External Displays<br />
** efi variables<br />
** USB device may drop offline following: arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0xffffd081, fsynr=0x350013, cbfrsynra=0x563, cb=1<br />
** Screen may blank for a few seconds during boot<br />
** TPM support is missing<br />
** USB may not run at superspeed+ rates.<br />
* All the above subject to change as patches are merged, this list is approximately correct as of the middle of August 2023<br />
** Try the https://fedoraproject.org/wiki/Thinkpad_X13s#Similar_pages link to get a few more things working.</div>Ausilhttps://fedoraproject.org/w/index.php?title=Thinkpad_X13s&diff=689525Thinkpad X13s2023-09-16T16:11:30Z<p>Ausil: fix up the add_drivers line, remove .ko and add space before "</p>
<hr />
<div>Page to keep track of Linux support development for Thinkpad X13s (SoC codename sc8280xp), the first Thinkpad with ARM CPU.<br />
<br />
Most of following informations come from #aarch64-laptops on OFTC, #fedora-arm on Libera.chat and arm[AT]lists.fedoraproject.org. Upstream infos change on daily basis, so this page may be outdated, therefore read it with pinch of salt / cum grano salis.<br />
<br />
==== Bootable images ====<br />
Fedora developers are aiming for it being supportable/usable in time for Fedora 38, at some point before that, some consumable images will be released for testing.<br />
<br />
A Linaro's Debian image is available at [https://forums.lenovo.com/t5/Other-Linux-Discussions/Does-anybody-know-if-there-is-work-being-done-to-integrate-X13s-ARM-processor-with-linux/m-p/5175315?page=1#5771660 this link]. It provides a decent user experience, despite missing audio and suspension capabilities.<br />
Power usage not yet optimized, so expect high battery drain<br />
<br />
==== Kernel development ====<br />
Some of work on the kernel can be seen in https://github.com/jhovold/linux repository, branches wip/sc8280xp<br />
<br />
==== GPU ====<br />
GPU hardware acceleration not yet available<br />
<br />
==== Sound ====<br />
Kernel side implementation at [https://lore.kernel.org/lkml/20221121130403.161817-3-srinivas.kandagatla@linaro.org/T/ this link]<br />
Userland code still to be implemented<br />
<br />
==== Virtualization ====<br />
Virtualization is not yet available. The UEFI is not yet exposing [https://developer.arm.com/documentation/102412/0102/Privilege-and-Exception-levels the EL2 (exception level)] which is required to run VMs<br />
<br />
==== Webcam ====<br />
Not working<br />
<br />
==== Wi-Fi ====<br />
Working<br />
<br />
==== Similar pages ====<br />
https://github.com/ironrobin/archiso-x13s/wiki/Feature-Support<br />
<br />
==== Rawhide hacking ====<br />
As of the 6.5RC series, official rawhide will boot given the following changes:<br />
* Grub2 must have this patch applied https://src.fedoraproject.org/rpms/grub2/pull-request/27<br />
* The kernel must be booted with 'arm64.nopauth clk_ignore_unused pd_ignore_unused` <br />
* A recent firmware must be on the machine, and the linux/DT mode must be selected in the FW menus.<br />
** Recommend minimum version:<br />
*** Version: N3HET84W (1.56 )<br />
*** Release Date: 06/26/2023<br />
* A 6.5 device tree must be placed on the ESP of the internal NVMe disk and named sc8280xp-lenovo-thinkpad-x13s.dtb<br />
** ex: /boot/efi/sc8280xp-lenovo-thinkpad-x13s.dtb<br />
* USB boot is possible if qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn is removed from the USB boot image<br />
** And add_drivers+=" qrtr " is added during initrd build<br />
** Otherwise leave it alone if booting from NVMe<br />
* Appropriate GPU firmware is placed in /lib/firmware/qcom/a660_sqe.fw, and /lib/firmware/qcom/a690_gmu.bin<br />
** Acquire from: https://github.com/ironrobin/x13s-alarm/tree/trunk/x13s-firmware<br />
* Due to the mainline nature of this kernel the following things may not work correctly:<br />
** Battery monitor in gnome<br />
*** Install the latest, pd-mapper https://github.com/andersson/pd-mapper, and qrtr-ns https://github.com/andersson/qrtr to fix this.<br />
** Proper USB-C charging negotiation, may result in slow charging, or battery drain while plugged in.<br />
*** Charging may not work at all though any number of USB-C hubs<br />
*** Make sure pd-mapper is installed to fix some of the more glaring problems.<br />
** Keyboard rollover<br />
** Bluetooth<br />
** CPU cache size reporting<br />
** Keyboard LEDs (depends on HW revision?, fn-f1 may enable the mute + capslock at which point both leds will be toggled by caps lock)<br />
** Audio<br />
** External Displays<br />
** efi variables<br />
** USB device may drop offline following: arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0xffffd081, fsynr=0x350013, cbfrsynra=0x563, cb=1<br />
** Screen may blank for a few seconds during boot<br />
** TPM support is missing<br />
** USB may not run at superspeed+ rates.<br />
* All the above subject to change as patches are merged, this list is approximately correct as of the middle of August 2023<br />
** Try the https://fedoraproject.org/wiki/Thinkpad_X13s#Similar_pages link to get a few more things working.</div>Ausilhttps://fedoraproject.org/w/index.php?title=LiberaCloaks&diff=616672LiberaCloaks2021-06-02T18:40:03Z<p>Ausil: </p>
<hr />
<div>= libera.chat Cloaks =<br />
<br />
{{Admon/caution | To avoid overwhelming libera.chat staff, we are only issuing cloaks in batches. Please note that it may be a few days or weeks before your cloak is granted}}<br />
<br />
This is the list of contributors who have requested Fedora IRC cloaks for the [http://libera.chat/ libera.chat] network.<br />
<br />
In order to receive a cloak, you must have completed the following steps:<br />
<br />
* You need to have registered your nick with <code>NickServ</code>.<br />
* You need to have set an email address with <code>NickServ</code>.<br />
* You need to have created an alternate nick and linked it to your primary nick with <code>NickServ</code>.<br />
* You must be in the [[Infrastructure/AccountSystem| Fedora Account System]] and should have completed the [[Legal:Fedora Project Contributor Agreement| FPCA]] before you are eligible for a cloak.<br />
* The nick you list here does not need to be your primary nick, but must be linked to your primary nick.<br />
<br />
{{Admon/tip | If you need instructions for using <code>NickServ</code>, try "<code>/msg NickServ HELP</code>" from the chatline of your IRC client after you have connected to libera.chat.}}<br />
<br />
If you have not done these things, libera.chat will not allow us to create your cloak.<br />
If you don't know how to do these things, follow the instructions here: https://libera.chat/guides/registration<br />
<br />
Your cloak will be: <code>*@fedora/yourIRCnick</code> <br />
If you want something different from that (e.g. @fedora/FASUSERNAME), please specify it in the comments field.<br />
<br />
Note that libera.chat does not support the use of underscores "_" in cloaks. Other non-alphanumeric characters may also not be supported and will be omitted from the cloak. If you have a preference of how you want your cloak to look, please put it in the comment field.<br />
<br />
After adding your entry, please be patient until the next round of cloak creations. This is a manual process.<br />
<br />
{{Admon/caution | Please do not delete example line. Please do not replace the table description line with your cloak request.}}<br />
<br />
<br />
{|class="wikitable" border="1"<br />
|- style="color: white; background-color: #3074c2; font-weight: bold" <br />
| '''Real Name''' || '''Email''' || '''IRC Nick''' || '''Account System Name''' || '''Comment'''<br />
|-<br />
| John Doe || nobody@fedoraproject.org || nick || example || comment (if necessary)<br />
|-<br />
| Charles Lee || lchh@fedoraproject.org || lch || lchh || <br />
|-<br />
| Vincent Damewood || vincent.leo.damewood@gmail.com || vdamewood || vdamewood || <br />
|-<br />
| Stephen Gallagher || Stephen@gallagherhome.com || sgallagh || sgallagh ||<br />
|-<br />
| Oliver Gassner || gass@sdf.org || thegass || gass ||<br />
|-<br />
| Dennis Gilmore || dennis@ausil.us || dgilmore || ausil ||<br />
|-<br />
|}<br />
<br />
<br />
And please contact the staff for accounts with the character "|" you should look at the source because the formatted page does not show "|" Thank you!<br />
<br />
== Red Hat Cloaks ==<br />
<br />
If you're on the Red Hat payroll, you can get a *@redhat/yournick cloak. Email dlloyd@redhat.com (from your redhat.com email account) to get one. Remember:<br />
* You need to have registered your nick with <code>NickServ</code>.<br />
* You need to have set an email address with <code>NickServ</code>.<br />
* You need to have created an alternate nick and linked it to your primary nick with <code>NickServ</code>.<br />
<br />
[[Category:Communicate]]</div>Ausilhttps://fedoraproject.org/w/index.php?title=FUDCon&diff=601663FUDCon2021-01-22T20:48:50Z<p>Ausil: Córdoba is in Argentina not spain</p>
<hr />
<div>{{header|events}}<br />
<br />
== FUDCon: Fedora Users and Developers Conference ==<br />
<br />
'''FUD''': An acronym for Fear, Uncertainty and Doubt. A typical tactic used by the opponents of open source to prevent its widespread adoption.<br />
<br />
'''Con''': In opposition or disagreement with; against.<br />
<br />
'''FUDCon''' is the Fedora Users and Developers Conference, a major free software event held in various regions around the world, usually annually per region. FUDCon is a combination of sessions, talks, workshops, and hackfests in which contributors work on specific initiatives. Topics include infrastructure, feature development, community building, general management and governance, marketing, testing and QA, packaging, etc.<br />
<br />
FUDCon is always free to attend for anyone in the world.<br />
<br />
== Components of a FUDCon ==<br />
<br />
A FUDCon typically includes some combination of:<br />
* A [[FUDCon barcamp|barcamp]]-style conference<br />
* A [[FUDPub]] social evening<br />
* A [[FUDCon hackfest|hackfest]]<br />
<br />
They are usually scheduled over a weekend.<br />
<br />
== What is a FUDCon like? ==<br />
<br />
These videos of past events give a idea of what a FUDCon is like:<br />
<br />
# [http://magazine.redhat.com/2009/02/13/video-fudcon-11/ FUDCon Boston - January 2009]<br />
# [http://magazine.redhat.com/2008/02/29/video-what-you-missed-at-fudcon-2008/ FUDCon Raleigh - January 2008]<br />
<br />
== Upcoming FUDCons ==<br />
<br />
See [[Premier Fedora Events]] for the calendar of upcoming FUDCons and FADs.<br />
<br />
== Organizing a FUDCon ==<br />
<br />
For organizers (or potential organizers), we have an [[FUDCon organization process]] with tips on how to plan a FUDCon.<br />
<br />
There is a [https://fedorahosted.org/fudcon-planning Trac issue tracker] used by FUDCon organizers to plan these conferences (starting with the [[Archive:FUDCon:Tempe_2011|Tempe 2011]] event).<br />
<br />
== Past FUDCons ==<br />
<br />
=== 2016 ===<br />
<br />
* [[FUDCon:Bid_for_PhnomPenh_2016|Phnom Penh 2016]] - Phnom Penh, Combodia, November 4&ndash;6 2016<br />
* [[FUDCon:Puno_2016|Puno 2016]] - Puno, Perú, November 13&ndash;16 2016<br />
<br />
=== 2015 ===<br />
<br />
* [[FUDCon:Cordoba_2015|Córdoba 2015]] - Córdoba, Argentina, September 10&ndash;12 2015<br />
* [[FUDCon:Pune_2015|Pune 2015]] - Pune, India, June 26&ndash;28 2015<br />
<br />
=== 2014 ===<br />
<br />
* [[FUDCon:Beijing_2014|Beijing 2014]] - Beijing, China, May 23-25 2014<br />
* [[FUDCon:Managua_2014|Managua 2014]] - Managua, Nicaragua, Oct 23-25 2014<br />
<br />
=== 2013 ===<br />
<br />
* [[FUDCon:Cusco_2013|Cusco 2013]] - Cusco, Perú, September 26-28 2013<br />
* [[FUDCon:Lawrence 2013|Lawrence 2013]] - Lawrence, Kansas, USA, January 18-20 2013<br />
<br />
=== 2012 ===<br />
<br />
* [[FUDCon:Paris_2012|Paris 2012]] - Paris, France, October 13-15 2012<br />
* [[FUDCon:Valencia_2012|Valencia - Venezuela 2012]] - Valencia, Venezuela, August, Aug 23-24-25 2012<br />
* [[FUDCon:KualaLumpur_2012|Kuala Lumpur 2012]] - Kuala Lumpur, Malaysia, May 18 - 19 - 20, 2012<br />
* [[FUDCon:Blacksburg_2012|Blacksburg 2012]] - Blacksburg, Virginia - Jan 13-15, 2012<br />
<br />
=== 2011 ===<br />
<br />
* [[FUDCon:India_2011|Pune 2011]] - Pune, India - Nov 04 - 06 2011<br />
* [[FUDCon:Milan_2011|Milan 2011]] - Milan, Italy - Sep 30 - Oct 02 2011<br />
* [[Archive:FUDCon:Panama_2011|FUDCon Panama 2011]] - Ciudad del Saber - May 26 - 28, 2011<br />
* [[Archive:FUDCon:Tempe_2011|FUDCon Tempe 2011]] - Tempe, AZ - Jan 29 - 31, 2011<br />
<br />
=== 2010 ===<br />
<br />
* [[Archive:FUDCon:Zurich_2010|FUDCon Zurich 2010]] - Zurich, Switzerland - September 17 - 19, 2010<br />
* [[Archive:FUDCon:Santiago_2010|FUDCon Santiago 2010]] - Santiago de Chile, Chile - Jul 15 - 8, 2010<br />
<br />
=== 2009 ===<br />
<br />
* [[Archive:FUDCon:Toronto_2009|FUDCon Toronto 2009]] - Toronto, Canada - December 5 - 7, 2009<br />
* [[Archive:FUDCon:Berlin 2009|FUDCon Berlin 2009]] - Berlin, Germany - June 26 - 28, 2009<br />
* [[Archive:FUDCon:LATAM 2009|FUDCon Porto Alegre 2009]] - Porto Alegre, Brazil - June 24 - 27, 2009<br />
* [[Archive:FUDCon:FUDConF11|FUDCon Boston 2009]] - Boston, MA - January 9 - 11, 2009<br />
<br />
=== 2008 ===<br />
<br />
* [[Archive:FUDCon:Brno 2008|FUDCon Brno 2008]] - Brno, Czech Republic - September 5 - 7, 2008<br />
* [[Archive:FUDCon:FUDConF10|FUDCon Boston 2008]] - Boston, MA - June 19 - 21, 2008<br />
* [[Archive:FUDCon:FUDConLinuxTag2008|FUDCon Berlin 2008]] - Berlin, Germany - May 30, 2008<br />
* [[Archive:FUDCon:FUDConF9|FUDCon Raleigh 2008]] - Raleigh, NC - January 11 - 13, 2008<br />
<br />
=== 2007 ===<br />
<br />
* [[Archive:FUDCon:FUDConF8|FUDCon Online 2007]] - A virtual FUDCon - August 11 - 15, 2007<br />
* [[Archive:FUDCon:Berlin 2007|FUDCon Berlin 2007]] - Berlin, Germany - May 31, 2007<br />
* [[Archive:FUDCon:FUDConBrussels2007|FUDCon Brussels 2007]] - Brussels, Belgium - February 23 - 24, 2007<br />
* [[Archive:FUDCon:FUDConBoston2007|FUDCon Boston 2007]] - Boston, MA - February 2 - 4, 2007<br />
<br />
=== 2006 ===<br />
<br />
* [[Archive:FUDCon:FUDConBoston2006|FUDCon Boston 2006]] - Boston, MA - April 7, 2006<br />
* [[Archive:FUDCon:FUDConDelhi2006|FUDCon Delhi 2006]] - Delhi, India - February 9, 2006<br />
<br />
=== 2005 ===<br />
<br />
* [[Archive:FUDCon:FUDCon3|FUDCon London 2005]] - London, UK - October 6, 2005<br />
* [[Archive:FUDCon:FUDCon2|FUDCon Karlsruhe 2005 ]] - Karlsruhe, Germany - June 24 - 25, 2005<br />
* [[Archive:FUDCon:Boston 2005|FUDCon Boston 2005]] - Boston, MA - February 18, 2005<br />
<br />
[[Category:Events]] [[Category:FUDCon]]</div>Ausilhttps://fedoraproject.org/w/index.php?title=Architectures&diff=553062Architectures2019-09-18T19:45:10Z<p>Ausil: /* Alternative Architectures */</p>
<hr />
<div>= Fedora Architectures =<br />
<br />
'''Author:''' [[TomCallaway| Tom 'spot' Callaway]], others <BR><br />
<br />
<br />
<br />
<br />
== Structure ==<br />
There are two tiers of architectures with Fedora support:<br />
* [[PrimaryArchitectures| Primary Architectures]] : These are architectures with the majority of the users, the most common architectures. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd).<br />
* [[AlternativeArchitectures| Alternative Architectures]] : These are architectures with motivated Architecture Maintainer Teams. There are two classes of Alternative Architecturs, the ones built in Primary koji where build failures are fatal and ones built on their own koji instances where build failures on the alternative architecture are not fatal: if packages successfully build for the primary koji, they push independently of any alternative architecture build successes or failures.<br />
<br />
{{Anchor|PrimaryArchitectures}}<br />
=== Primary Architectures ===<br />
* [[Architectures/ARM|ARM]]-hfp (32-bit, little-endian, hfp for ARMv7->) (as of Fedora 20)<br />
* <strike>[[Architectures/x86|x86]] (32-bit for i686->) (until Fedora 25)</strike><br />
* [[Architectures/x86-64|x86_64]] (64-bit)<br />
* ARM [[Architectures/AArch64|AArch64]] (64-bit, little-endian for ARMv8->)<br />
{{Anchor|SecondaryArchitectures}}<br />
<br />
=== Alternative Architectures ===<br />
* <strike>[[Architectures/ARM|ARM]]-sfp (32-bit, little-endian, sfp for ARMv5->)</strike><br />
* <strike>[[Architectures/IA64|IA64]]</strike><br />
* [[Architectures/MIPS|MIPS]]-64el (mips64r2, little endian, n64 ABI)<br />
* [[Architectures/MIPS|MIPS]]-el (mips32r2, little endian, o32 ABI)<br />
* <strike>[[Architectures/MIPS|MIPS]]-n32el (mips64r2, little endian, n32 ABI)</strike><br />
* <strike>[[Architectures/Parisc|Parisc]]</strike><br />
* <strike>[[Architectures/PowerPC|PowerPC]] (32-bit)</strike><br />
* <strike>[[Architectures/PowerPC|PowerPC64]] (64-bit, big-endian for POWER5->)</strike><br />
* [[Architectures/PowerPC|PowerPC64le]] (64-bit, little-endian for POWER8->)<br />
* [[Architectures/RISC-V|RISC-V]] (64-bit open source ISA)<br />
* [[Architectures/s390x|s390x]] (64-bit for zEC12->)<br />
* <strike>[[Architectures/SPARC|SPARC]] (32-bit)</strike><br />
* <strike>[[Architectures/SPARC|SPARC64]] (64-bit for sun4u->)</strike><br />
* <strike>[[Architectures/x86|x86]] (32-bit for i686->) (Fedora 26 until Fedora 30)</strike><br />
<br />
{{Anchor|Architecture Maintainer Teams}}<br />
<br />
== Architecture Maintainer Teams ==<br />
<br />
In order to manage and support alternative architectures, each alternative architecture will have a team responsible for the Fedora release on that architecture. Each team will assign a team lead. <br />
<br />
=== Architecture Maintainer Team Responsibilities ===<br />
<br />
* Receiving notifications of alternative arch build successes and failures<br />
* Patching packages cleanly such that they build and function correctly on the alternative architecture, with a minimal amount of architecture conditionalization in the spec file (avoid %ifarch wherever possible). To enable this, architecture team members will have special grouped ACL access to all packages, permitting them special access to make changes. This ability requires a great amount of respect, and alternative architecture maintainers are expected to be extremely careful when modifying packages. With special access comes extra responsibility. Think before you commit. Consult the package maintainer before making a change, no matter how trivial.<br />
* Resolving architecture specific bugs filed against packages<br />
* Holding regular status meetings on IRC for the architecture<br />
* Meeting target dates for architecture stability, freezes, release candidates, and releases. If unable to meet target dates, release does not occur. Target dates for alternative architectures can be slightly farther out than the target dates for primary architectures, allowing for longer build times and architecture fixes for packages frozen for primary architectures. If an alternative architecture fails to make release goals for two consecutive Fedora releases, the architecture will be re-evaluated by FESCo.<br />
* Maintaining and hosting the buildserver(s) and storage for that architecture<br />
* working with [https://docs.pagure.org/releng/ Release Engineering] on Composing trees for that architecture<br />
* Maintain a section on the fedoraproject.org wiki for the architecture, documenting the effort, the maintainer team, the meeting schedule, and other useful information for users, packagers, and developers.<br />
* Participate in and give progress reports to the Release Engineering meeting on a weekly basis<br />
<br />
Each alternative architecture maintainer team will have a dedicated mailing list (e.g. fedora-arm@lists.fp.o) to serve as a contact point for architecture specific questions, bug notifications, build notifications, etc.<br />
<br />
There is a generic alternative arch list at [https://admin.fedoraproject.org/mailman/listinfo/secondary secondary@lists.fedoraproject.org] one or more team members should subscribe here.<br />
<br />
In addition, alternative architecture teams '''should''' do the following:<br />
* Run regular 'rebuild all in mock' runs (usually requires dedicated system)<br />
<br />
== Logistics ==<br />
<br />
=== Buildsystems ===<br />
Alternative architectures will need to provide their own hardware, to act as build servers for the koji buildsystem. Neither Red Hat nor the Fedora Project is able to guarantee to provide hosting space for Alternative Architecture systems at this time. Alternative Architecture koji buildsystems need to be accessible via the internet, so that they can communicate with the primary Fedora koji infrastructure and be accessed by all fedora contributors. All builds have to happen in a native environment. this means cross compiling is not allowed, you can however use virtualisation to emulate your target system.<br />
<br />
=== File Storage ===<br />
Alternative architectures will need to provide their own file storage for the buildsystem, there may be some available from Fedora Infrastructure, composed trees will be hosted at https://dl.fedoraproject.org/pub/fedora-secondary. Fedora mirrors can choose whether they wish to mirror alternative architecture trees on an arch-by-arch basis.<br />
<br />
=== Tree Composition ===<br />
Fedora Release Engineering will not have any responsibility for composing Alternative Architecture trees for Architectures that are built outside of primary koji. Composing trees and install media is the responsibility of the Alternative Architecture team. Each team should expect to have a dedicated server for compose purposes (if possible).<br />
<br />
=== Sandbox Systems ===<br />
Alternative architecture teams are encouraged to make a "sandbox", or testing system publicly available for Fedora packagers. It is possible to configure a system so that only Fedora Account System users with packager access can ssh into the box, using their FAS credentials.<br />
<br />
'''***TODO***''' Document how to set this up.<br />
<br />
While sandbox systems are very useful for Fedora packagers who would not normally have access to the hardware architecture, they are not a requirement.<br />
<br />
== Packaging Issues ==<br />
<br />
=== Divergence from Primary Architectures ===<br />
Alternative architecture package trees should be as close to primary architecture package trees as possible. Alternative architectures should not use older versions and must not use customized (hacked up) packages. Alternative architectures may include architecture specific packages where relevant (e.g. bootloaders, xorg drivers). Changes to support alternative architectures must be committed in GIT for each package.<br />
<br />
=== ExcludeArch & ExclusiveArch ===<br />
Fedora Packages should avoid using ExclusiveArch, except when absolutely correct. Only packages which are exclusively arch specific should use ExclusiveArch (e.g. a bootloader designed for only one architecture). ExcludeArch should only be set when the architecture is not relevant for the package, the package is non-functional on the architecture, or the code does not compile cleanly for the architecture.<br />
<br />
By using ExcludeArch on an arch by arch basis, it enables the majority of packages to have the chance to build on new alternative architectures, rather than being immediately ignored by a blanket ExclusiveArch. There is a process running that will notify architecture maintainers of all changes in Exclude and Exclusive Arch headers along with daily summaries of all packages with architecture specific handling<br />
<br />
=== Tracker Bugs ===<br />
Any packager which excludes an architecture for a package needs to open a [https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures bug report against an ExcludeArch blocker bug].<br />
This will help the architecture team track and fix packages for their architecture.</div>Ausilhttps://fedoraproject.org/w/index.php?title=Architectures&diff=553061Architectures2019-09-18T19:44:34Z<p>Ausil: EOL x86</p>
<hr />
<div>= Fedora Architectures =<br />
<br />
'''Author:''' [[TomCallaway| Tom 'spot' Callaway]], others <BR><br />
<br />
<br />
<br />
<br />
== Structure ==<br />
There are two tiers of architectures with Fedora support:<br />
* [[PrimaryArchitectures| Primary Architectures]] : These are architectures with the majority of the users, the most common architectures. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd).<br />
* [[AlternativeArchitectures| Alternative Architectures]] : These are architectures with motivated Architecture Maintainer Teams. There are two classes of Alternative Architecturs, the ones built in Primary koji where build failures are fatal and ones built on their own koji instances where build failures on the alternative architecture are not fatal: if packages successfully build for the primary koji, they push independently of any alternative architecture build successes or failures.<br />
<br />
{{Anchor|PrimaryArchitectures}}<br />
=== Primary Architectures ===<br />
* [[Architectures/ARM|ARM]]-hfp (32-bit, little-endian, hfp for ARMv7->) (as of Fedora 20)<br />
* <strike>[[Architectures/x86|x86]] (32-bit for i686->) (until Fedora 25)</strike><br />
* [[Architectures/x86-64|x86_64]] (64-bit)<br />
* ARM [[Architectures/AArch64|AArch64]] (64-bit, little-endian for ARMv8->)<br />
{{Anchor|SecondaryArchitectures}}<br />
<br />
=== Alternative Architectures ===<br />
* <strike>[[Architectures/ARM|ARM]]-sfp (32-bit, little-endian, sfp for ARMv5->)</strike><br />
* <strike>[[Architectures/IA64|IA64]]</strike><br />
* [[Architectures/MIPS|MIPS]]-64el (mips64r2, little endian, n64 ABI)<br />
* [[Architectures/MIPS|MIPS]]-el (mips32r2, little endian, o32 ABI)<br />
* <strike>[[Architectures/MIPS|MIPS]]-n32el (mips64r2, little endian, n32 ABI)</strike><br />
* <strike>[[Architectures/Parisc|Parisc]]</strike><br />
* <strike>[[Architectures/PowerPC|PowerPC]] (32-bit)</strike><br />
* [[Architectures/PowerPC|PowerPC64]] (64-bit, big-endian for POWER5->)<br />
* [[Architectures/PowerPC|PowerPC64le]] (64-bit, little-endian for POWER8->)<br />
* [[Architectures/RISC-V|RISC-V]] (64-bit open source ISA)<br />
* [[Architectures/s390x|s390x]] (64-bit for zEC12->)<br />
* <strike>[[Architectures/SPARC|SPARC]] (32-bit)</strike><br />
* <strike>[[Architectures/SPARC|SPARC64]] (64-bit for sun4u->)</strike><br />
* <strike>[[Architectures/x86|x86]] (32-bit for i686->) (Fedora 26 until Fedora 30)</strike><br />
<br />
{{Anchor|Architecture Maintainer Teams}}<br />
<br />
== Architecture Maintainer Teams ==<br />
<br />
In order to manage and support alternative architectures, each alternative architecture will have a team responsible for the Fedora release on that architecture. Each team will assign a team lead. <br />
<br />
=== Architecture Maintainer Team Responsibilities ===<br />
<br />
* Receiving notifications of alternative arch build successes and failures<br />
* Patching packages cleanly such that they build and function correctly on the alternative architecture, with a minimal amount of architecture conditionalization in the spec file (avoid %ifarch wherever possible). To enable this, architecture team members will have special grouped ACL access to all packages, permitting them special access to make changes. This ability requires a great amount of respect, and alternative architecture maintainers are expected to be extremely careful when modifying packages. With special access comes extra responsibility. Think before you commit. Consult the package maintainer before making a change, no matter how trivial.<br />
* Resolving architecture specific bugs filed against packages<br />
* Holding regular status meetings on IRC for the architecture<br />
* Meeting target dates for architecture stability, freezes, release candidates, and releases. If unable to meet target dates, release does not occur. Target dates for alternative architectures can be slightly farther out than the target dates for primary architectures, allowing for longer build times and architecture fixes for packages frozen for primary architectures. If an alternative architecture fails to make release goals for two consecutive Fedora releases, the architecture will be re-evaluated by FESCo.<br />
* Maintaining and hosting the buildserver(s) and storage for that architecture<br />
* working with [https://docs.pagure.org/releng/ Release Engineering] on Composing trees for that architecture<br />
* Maintain a section on the fedoraproject.org wiki for the architecture, documenting the effort, the maintainer team, the meeting schedule, and other useful information for users, packagers, and developers.<br />
* Participate in and give progress reports to the Release Engineering meeting on a weekly basis<br />
<br />
Each alternative architecture maintainer team will have a dedicated mailing list (e.g. fedora-arm@lists.fp.o) to serve as a contact point for architecture specific questions, bug notifications, build notifications, etc.<br />
<br />
There is a generic alternative arch list at [https://admin.fedoraproject.org/mailman/listinfo/secondary secondary@lists.fedoraproject.org] one or more team members should subscribe here.<br />
<br />
In addition, alternative architecture teams '''should''' do the following:<br />
* Run regular 'rebuild all in mock' runs (usually requires dedicated system)<br />
<br />
== Logistics ==<br />
<br />
=== Buildsystems ===<br />
Alternative architectures will need to provide their own hardware, to act as build servers for the koji buildsystem. Neither Red Hat nor the Fedora Project is able to guarantee to provide hosting space for Alternative Architecture systems at this time. Alternative Architecture koji buildsystems need to be accessible via the internet, so that they can communicate with the primary Fedora koji infrastructure and be accessed by all fedora contributors. All builds have to happen in a native environment. this means cross compiling is not allowed, you can however use virtualisation to emulate your target system.<br />
<br />
=== File Storage ===<br />
Alternative architectures will need to provide their own file storage for the buildsystem, there may be some available from Fedora Infrastructure, composed trees will be hosted at https://dl.fedoraproject.org/pub/fedora-secondary. Fedora mirrors can choose whether they wish to mirror alternative architecture trees on an arch-by-arch basis.<br />
<br />
=== Tree Composition ===<br />
Fedora Release Engineering will not have any responsibility for composing Alternative Architecture trees for Architectures that are built outside of primary koji. Composing trees and install media is the responsibility of the Alternative Architecture team. Each team should expect to have a dedicated server for compose purposes (if possible).<br />
<br />
=== Sandbox Systems ===<br />
Alternative architecture teams are encouraged to make a "sandbox", or testing system publicly available for Fedora packagers. It is possible to configure a system so that only Fedora Account System users with packager access can ssh into the box, using their FAS credentials.<br />
<br />
'''***TODO***''' Document how to set this up.<br />
<br />
While sandbox systems are very useful for Fedora packagers who would not normally have access to the hardware architecture, they are not a requirement.<br />
<br />
== Packaging Issues ==<br />
<br />
=== Divergence from Primary Architectures ===<br />
Alternative architecture package trees should be as close to primary architecture package trees as possible. Alternative architectures should not use older versions and must not use customized (hacked up) packages. Alternative architectures may include architecture specific packages where relevant (e.g. bootloaders, xorg drivers). Changes to support alternative architectures must be committed in GIT for each package.<br />
<br />
=== ExcludeArch & ExclusiveArch ===<br />
Fedora Packages should avoid using ExclusiveArch, except when absolutely correct. Only packages which are exclusively arch specific should use ExclusiveArch (e.g. a bootloader designed for only one architecture). ExcludeArch should only be set when the architecture is not relevant for the package, the package is non-functional on the architecture, or the code does not compile cleanly for the architecture.<br />
<br />
By using ExcludeArch on an arch by arch basis, it enables the majority of packages to have the chance to build on new alternative architectures, rather than being immediately ignored by a blanket ExclusiveArch. There is a process running that will notify architecture maintainers of all changes in Exclude and Exclusive Arch headers along with daily summaries of all packages with architecture specific handling<br />
<br />
=== Tracker Bugs ===<br />
Any packager which excludes an architecture for a package needs to open a [https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures bug report against an ExcludeArch blocker bug].<br />
This will help the architecture team track and fix packages for their architecture.</div>Ausilhttps://fedoraproject.org/w/index.php?title=Council/Nominations&diff=529496Council/Nominations2018-11-27T01:50:47Z<p>Ausil: update Dennis Gilmore fas account details</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-Nov-28 at 23:59:59 UTC}}<br />
<!-- {{admon/important|Voting period is now open.|The period ends on 2017-Dec-18 at 23:59:59 UTC}} --><br />
<!--{{admon/important|Nomination period is now closed.|Please wait for the next election cycle to nominate.}} --><br />
<!--{{admon/important|The Nomination period for Council is now over.|Please wait for the next Elections.}} --><br />
<br />
The following [[Elections|elections]] take place in December 2018:<br />
<br />
* [[Council/Nominations|Council]] (one seat)<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 />
See the [https://docs.fedoraproject.org/en-US/council/ Council docs] for more details regarding Council goals and structure.<br />
<br />
= Council Elections December 2018 =<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.<br />
<br />
The following Council member finishes their term, and the seat is up for re-election:<br />
<br />
* [[User:ausil| Dennis Gilmore]] (ausil)<br />
<br />
For the last election, see [https://fedoraproject.org/w/index.php?title=Council/Nominations&oldid=519630 Nominations May 2018].<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 the [[Council|Council]] you must have cla_done 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/Fedora-Council/tickets/issue/231 top 3 selected questions] are published in [https://pagure.io/fedora-project-schedule/blob/master/f/elections/2018-December Pagure]. Nominees are requested to answer these [https://pagure.io/fedora-project-schedule/blob/master/f/elections/2018-December selected questions] using '''[https://pagure.io/fedora-project-schedule/issues private issue in Pagure]'''. In this way only [https://fedoraproject.org/wiki/User:bcotton 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:Council]] [[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 />
| John M. Harris, Jr. || [[User:Johnmh|JohnMH]] || [[User:Johnmh|JohnMH]]<br />
|-<br />
|Alejandro Perez || [[User:Aeperezt|aeperezt]] || [[User:lbazan|lbazan ]]<br />
|-<br />
| Eduard Lucena || [[User:X3mboy|x3mboy]] || [[User:Jflory7|jflory7]]<br />
|-<br />
|Ricardo Martinelli de Oliveira || rimolive || '''[[User:Rimolive|rimolive]]'''<br />
|-<br />
|Itamar Reis Peixoto || itamarjp || '''[[User:itamarjp|itamarjp]]'''<br />
|-<br />
|Dennis Gilmore || [[User:Ausil|ausil]] / dgilmore || '''[[User:Ausil|ausil]]'''<br />
|}</div>Ausilhttps://fedoraproject.org/w/index.php?title=Council/Nominations&diff=529495Council/Nominations2018-11-27T01:49:25Z<p>Ausil: nominate Dennis Gilmore</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-Nov-28 at 23:59:59 UTC}}<br />
<!-- {{admon/important|Voting period is now open.|The period ends on 2017-Dec-18 at 23:59:59 UTC}} --><br />
<!--{{admon/important|Nomination period is now closed.|Please wait for the next election cycle to nominate.}} --><br />
<!--{{admon/important|The Nomination period for Council is now over.|Please wait for the next Elections.}} --><br />
<br />
The following [[Elections|elections]] take place in December 2018:<br />
<br />
* [[Council/Nominations|Council]] (one seat)<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 />
See the [https://docs.fedoraproject.org/en-US/council/ Council docs] for more details regarding Council goals and structure.<br />
<br />
= Council Elections December 2018 =<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.<br />
<br />
The following Council member finishes their term, and the seat is up for re-election:<br />
<br />
* [[User:ausil| Dennis Gilmore]] (ausil)<br />
<br />
For the last election, see [https://fedoraproject.org/w/index.php?title=Council/Nominations&oldid=519630 Nominations May 2018].<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 the [[Council|Council]] you must have cla_done 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/Fedora-Council/tickets/issue/231 top 3 selected questions] are published in [https://pagure.io/fedora-project-schedule/blob/master/f/elections/2018-December Pagure]. Nominees are requested to answer these [https://pagure.io/fedora-project-schedule/blob/master/f/elections/2018-December selected questions] using '''[https://pagure.io/fedora-project-schedule/issues private issue in Pagure]'''. In this way only [https://fedoraproject.org/wiki/User:bcotton 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:Council]] [[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 />
| John M. Harris, Jr. || [[User:Johnmh|JohnMH]] || [[User:Johnmh|JohnMH]]<br />
|-<br />
|Alejandro Perez || [[User:Aeperezt|aeperezt]] || [[User:lbazan|lbazan ]]<br />
|-<br />
| Eduard Lucena || [[User:X3mboy|x3mboy]] || [[User:Jflory7|jflory7]]<br />
|-<br />
|Ricardo Martinelli de Oliveira || rimolive || '''[[User:Rimolive|rimolive]]'''<br />
|-<br />
|Itamar Reis Peixoto || itamarjp || '''[[User:itamarjp|itamarjp]]'''<br />
|-<br />
|Dennis Gilmore || dgilmore || '''[[User:Ausil|ausil]]'''<br />
|}</div>Ausilhttps://fedoraproject.org/w/index.php?title=Council_Meetings&diff=527529Council Meetings2018-10-24T14:12:43Z<p>Ausil: updated councl members irc nics for chairing meeting</p>
<hr />
<div>= Fedora Council Meetings =<br />
<br />
The [https://docs.fedoraproject.org/fedora-project/council/charter.html Fedora Council] holds weekly meetings. Every other week we have an ''Open Floor'' meeting, where the agenda is set by attendees at the beginning of the hour. On the ''other'' weeks, we alternate between ''Tickets and Ongoing'' meetings and video-based ''Subproject reports''.<br />
<br />
You can see our upcoming meeting schedule in [https://apps.fedoraproject.org/calendar/list/council/ Fedocal].<br />
<br />
= Council Meeting Process =<br />
<br />
This guide explains how to manage and run a Council IRC meeting. Many of the steps here could well apply to other groups that hold regular IRC meetings as well. <br />
<br />
== ''Tickets and Ongoing'' Meetings ==<br />
<br />
''Tickets and Ongoing'' meetings happen every four weeks. They're held in the <tt>#fedora-meeting-1</tt> channel on Freenode. We don't want to be entirely ticket-driven (since that's a reactive process), but this helps keep important issues from slipping through the cracks. <br />
<br />
=== Pre-meeting (Tickets and Ongoing)===<br />
<br />
1. Go through [https://pagure.io/Fedora-Council/tickets/issues open tickets] and select several that seem timely or otherwise worth real-time discussion.This is also a good time to poke forward any issues that don't really need to be at the meeting but need further action, or to close issues that are resolved — or which won't be resolved. We want to keep the open tickets reflective of actual work in progress, not merely things we hope to get to someday. (Ticket system or not, there's an infinite pool of potential work for the Council, and keeping open tickets which we have no practical plan to work on is a recipe for sadness all around.)<br />
<br />
2. Consider other topics that might benefit from real-time discussion in order to move forward. Again, we don't want to block issues on waiting for "everyone in the room" conversations (when we have mailing lists and lazy consensus), but we've found that regular discussion is important.<br />
<br />
3. An automated calendar message should appear on [https://lists.fedoraproject.org/archives/list/council-discuss@lists.fedoraproject.org/ council-discuss@lists.fedoraproject.org list] the day before the meeting. Reply to this message with the following template: <br />
<br />
{{#tag:pre| <br />
Subject: Schedule for Wednesday's Tickets and Ongoing Fedora Council Meeting ({{#time:Y-m-d|wednesday}})<br />
}}<br />
<br />
{{#tag:pre| <br />
The Fedora Council will hold our regular Tickets and Ongoing meeting<br />
at 10:00am US/Eastern in #fedora-meeting-1 on irc.freenode.net.<br />
All are welcome!<br />
<br />
To convert to your local time, run:<br />
<br />
TZ=US/Eastern date -d '10am {{#time:Y-m-d|wednesday}}'<br />
<br />
<br />
Expected discussion items include:<br />
<br />
<br />
YOUR AGENDA ITEMS HERE<br />
<br />
<br />
If you would like to add something to this agenda, you can reply to<br />
this email, e-mail me directly, file a new ticket at<br />
https://pagure.io/Fedora-Council/tickets/issues, or if time permits,<br />
bring it up at the end of the meeting, during the open floor topic.<br />
Note that added topics may be deferred until the following meeting.<br />
}}<br />
<br />
=== During the Meeting (Tickets and Ongoing) ===<br />
<br />
You can copy and paste in lines from this template as the meeting proceeds. You may find it helpful to copy this to a file in advance, so you can pre-fill the <tt>topic</tt> lines.<br />
<br />
{{#tag:pre| <br />
#startmeeting Council ({{#time:Y-m-d|wednesday}})<br />
#meetingname council<br />
#chair amsharma bex contyk dgilmore dperpeet pbrobinson jkurik langdon mattdm tyll bcotton sumantrom<br />
#topic Introductions, Welcomes<br />
#topic Today's Agenda<br />
(paste agenda from previous email)<br />
#topic first topic...<br />
#topic next topic...<br />
...<br />
#topic Open Floor<br />
#endmeeting<br />
}}<br />
<br />
<br />
1. Use the lines up through 'Introductions, Welcomes' to start the meeting. <br />
<br />
2. Wait for a majority of the Council to show up.<br />
<br />
3 We've found that our meetings and discussions are small and informal enough that we don't need special etiquette markers (like <tt>!</tt> to ask for permission to talk). If we ever do have a particularly contentious and popular topic, we may introduce rules like that temporarily — but, usually, it's just not necessary. <br />
<br />
4. Keep an eye on the clock — if a topic is using more than the expected time, sometimes that's okay, and other times it's best to ask that discussion continue in tickets and on the mailing list and move on.<br />
<br />
5. Make liberal use of [[Zodbot]] commands like <tt>#topic</tt>, <tt>#info</tt>, and <tt>#help</tt>, to populate the meeting minutes.<br />
<br />
=== Post meeting (Tickets and Ongoing) ===<br />
<br />
1. The meeting minutes are automatically collected in [https://meetbot.fedoraproject.org/sresults/?group_id=council&type=team Møte] and emailed to [https://lists.fedoraproject.org/archives/list/meetingminutes@lists.fedoraproject.org/ meetingminutes]. It might be nice to find this and also mail it to the list. (Ideally, we'd enhance meetbot to automatically send these minutes to the appropriate list. <tt>#help</tt>, please!)<br />
<br />
2. Process through tickets comment/close them as appropriate.<br />
<br />
3. If you have any action items you can handle quickly, now is really a good time for it. Otherwise, don't forget to add these to your personal todo list.<br />
<br />
== ''Open Floor'' Meetings ==<br />
<br />
''Open Floor'' meetings happen every four weeks. As with ''Tickets and Ongoing'' meetings, they are held in the <tt>#fedora-meeting-1</tt> channel on Freenode. They do not have a preset agenda. Instead, we spend the first few minutes of the meeting deciding what topics will be discussed. If attendees — Council members and otherwise — have several topics of general interest, the primary meeting chair (usually the FPL or FCAIC) will put them in order, and after a certain amount of time discussing the first, ask if it's time to move on.<br />
<br />
=== Pre-meeting (Open Floor) ===<br />
<br />
The beauty of this is that it requires very little preparatory work. An automated calendar message will be sent to the list the day before, containing basic information about the meeting.<br />
<br />
=== During the Meeting (Open Floor) ===<br />
<br />
<br />
<br />
You can copy and paste in lines from this template as the meeting proceeds.<br />
<br />
<br />
{{#tag:pre| <br />
#startmeeting Council ({{#time:Y-m-d|wednesday}})<br />
#meetingname council<br />
#chair mattdm jkurik jwb langdon bexelbie dperpeet Amita dgilmore pbrobinson tyll bcotton sumantrom<br />
#topic Introductions, Welcomes<br />
#topic Today's Open Floor Agenda<br />
#topic (first topic decided on)...<br />
#topic (next topic decided on)...<br />
...<br />
#endmeeting<br />
}}<br />
<br />
<br />
1. Use the lines up to 'Introductions, Welcomes' to start the meeting. <br />
<br />
2. Wait a few for people to show up.<br />
<br />
3. Follow the Open Floor meeting procedure:<br />
#. Ask for topics<br />
#. Gauge popularity, sort topics<br />
#. Ask if everyone is okay with the sorted list<br />
#. Move to the first topic<br />
#. After ten minutes, or if discussion wanes, ask if people want to keep talking on the current topic or move on.<br />
#. Sometimes, a little encouragement to get to further topics is a good idea. :)<br />
<br />
4. Make liberal use of [[Zodbot]] commands like <tt>#topic</tt>, <tt>#info</tt>, and <tt>#help</tt>, to populate the meeting minutes.<br />
<br />
=== Post meeting (Open Floor) ===<br />
<br />
1. The meeting minutes are automatically collected in [https://meetbot.fedoraproject.org/sresults/?group_id=council&type=team Møte] and emailed to [https://lists.fedoraproject.org/archives/list/meetingminutes@lists.fedoraproject.org/ meetingminutes]. It might be nice to find this and also mail it to the list. (Ideally, we'd enhance meetbot to automatically send these minutes to the appropriate list. <tt>#help</tt>, please!)<br />
<br />
2. Process through tickets comment/close them as appropriate.<br />
<br />
<br />
3. If you have any action items you can handle quickly, now is really a good time for it. Otherwise, don't forget to add these to your personal todo list.<br />
<br />
== Subproject Reports ==<br />
<br />
TBD: expand this section. These are currently done with Jitsi and published to Youtube afterward.<br />
<br />
[[Category:Council]] [[Category:Council policy]]</div>Ausilhttps://fedoraproject.org/w/index.php?title=User:Ausil&diff=510655User:Ausil2018-02-01T13:17:04Z<p>Ausil: added some default templates</p>
<hr />
<div>{{Template:Userpage/Infobox2<br />
|REAL-NAME=Dennis Gilmore<br />
|image=<br />
|birthday=<br />
|birthplace= <br />
|HOME=https://ausil.us/<br />
|FAS-NAME=ausil<br />
|IRC=dgilmore<br />
|irc-channels=#fedora-3dprinting #fedora-meeting-3 #fedora-meeting-2 #fedora-websites #fedora-cloud #proyecto-fedora #fedora-apps #fedora-qa #fedora-fedmsg #fedora-buildsys #fedora-meeting-1 #fedora-releng #fedora-ambassadors #fedora-kernel #fedora #fedora-latam #fedora-br #fedora-java #fedora-mips #fedora-s390x #fedora-ppc #fedora-arm #epel #fedora-meeting #fedora-security #fedora-devel #fedora-noc #fedora-admin (and others)<br />
|pmail=<br />
|gpg=663C50D1 <br />
|homepage=https://ausil.us<br />
|jabber=<br />
|twitter=@dgilmoreAU<br />
}}<br />
= Dennis Gilmore =<br />
<br />
Email: dennis@ausil.us<br />
<br />
Home Page: [http://www.ausil.us] <br />
<br />
== About Me ==<br />
<br />
Born and Raised in Australia, I now live in the USA. I used to work for OLPC as their build and release engineer. Currently i am a team lead for Release Engineer at Red Hat for Platform (Fedora and RHEL)<br />
<br />
I am a member of Fedora Infrastructure and FESCo, formerly I was on the EPEL steering committee and Fedora Project Board. I helped to form EPEL with mmcgrath.<br />
<br />
== Some of the things I have worked on ==<br />
<br />
{| border="1"<br />
|-<br />
| Aurora SPARC Linux <br />
|-<br />
| Aurora SPARC Linux Extras<br />
|}<br />
<br />
<br />
== Badges ==<br />
To hightlight some of the work I've done in Fedora, here are the badges I've accumulated:<br />
<br />
{{ #fedorabadges: ausil }}</div>Ausilhttps://fedoraproject.org/w/index.php?title=User:Ausil&diff=508652User:Ausil2018-01-05T16:57:34Z<p>Ausil: </p>
<hr />
<div>= Dennis Gilmore =<br />
<br />
Email: dennis@ausil.us<br />
<br />
Home Page: [http://www.ausil.us] <br />
<br />
== About Me ==<br />
<br />
Born and Raised in Australia, I now live in the USA. I used to work for OLPC as their build and release engineer. Currently i am a team lead for Release Engineer at Red Hat for Platform (Fedora and RHEL)<br />
<br />
I am a member of Fedora Infrastructure and FESCo, formerly I was on the EPEL steering committee and Fedora Project Board. I helped to form EPEL with mmcgrath.<br />
<br />
== Some of the things I have worked on ==<br />
<br />
{| border="1"<br />
|-<br />
| Aurora SPARC Linux <br />
|-<br />
| Aurora SPARC Linux Extras<br />
|}</div>Ausilhttps://fedoraproject.org/w/index.php?title=SIGs/3DPrinting&diff=501625SIGs/3DPrinting2017-09-21T02:21:44Z<p>Ausil: /* Members */</p>
<hr />
<div>[[File:fedora-printed-thumb.jpg|500px|thumb|right|Fedora Printed [[F19_Artwork/Submissions/Supplemental_Wallpapers|supplemental wallpaper for Fedora 19]]]]<br />
= 3D Printing SIG =<br />
The Fedora 3D Printing SIG's goal is to make Fedora the best platform for 3D printing. <br />
<br />
== Members ==<br />
<br />
{|<br />
! Member !! Printers you have access to !! Main activity in the SIG<br />
|-<br />
| [[User:Churchyard|Miro Hrončok]] || RebeliX, Prusa i2/i3, Lulzbot TAZ 4, 6 and Mini, Ciclop 3D scanner || packaging, reviews, taking printers to events<br />
|-<br />
| [[User:djdelorie|DJ Delorie]] || Rostock MAX V1 || <br />
|-<br />
| [[User:jskarvad|Jaroslav Škarvada]] || RebeliX, Prusa i2/i3, LulzBot TAZ 6 || package review, firmware hacking, can help with packaging<br />
|-<br />
| [[User:M4rtink|Martin Kolman]] || RebeliX, Prusa i2, LulzBot TAZ 6 || package review, printer repair and maintenance, taking printers to events, general help<br />
|-<br />
| [[User:johnmh|John M. Harris]] || Lulzbot TAZ 5, Prusa i3 || can help with packaging<br />
|-<br />
| [[User:corey84 |Corey Sheldon]] || None at the moment, but knowledge and skills, planning to have a 3D printed laptop design out by fall 2018 (http://www.ameridea.net)|| Evangelism and workshops <br />
|-<br />
| [[User:Yn1v |Neville A. Cross]] || Rerap i3 || talks, videos, taking the printer to events<br />
|-<br />
| [[User:spot |Tom Callaway]] || Lulzbot TAZ 5, Lulzbot Mini || packaging, reviews, demos at events<br />
|-<br />
| [[User:przemekklosowski |Przemek Klosowski]] || under construction || general help, docs, MachineKit/BeagleBone<br />
|-<br />
| [[User:Ausil |Dennis Gilmore]] || Prusa i3 || general help, package review, ARM, packaging<br />
|-<br />
|}<br />
<br />
= Participation =<br />
<br />
There is no formal process for participating; joining the mailing list, hanging out on IRC, or participating in meetings are all great ways to get involved.<br />
<br />
A little self-introduction on the mailing list would be nice, too. And, if you want to, add yourself to our members-section above.<br />
<br />
There is now a [https://admin.fedoraproject.org/accounts/group/view/3d-printing-sig FAS group] as well; so if you want to get a badge, you can join. Plese introduce yourself on the list before applying.<br />
<br />
= 3D Printing Apps/Packages in Fedora =<br />
<br />
===3D CAD programs===<br />
<br />
* {{package|openscad}} The Programmers Solid 3D CAD Modeller<br />
* {{package|freecad}}* A general purpose 3D CAD modeller<br />
* {{package|librecad}}* A graphical and comprehensive 2D CAD application<br />
<br />
===3D mesh utilities and libraries===<br />
<br />
* {{package|admesh}} Diagnose and/or repair problems with STereo Lithography files<br />
* {{package|admeshgui}} STL viewer and manipulation tool<br />
* {{package|amftools}} AMF file library<br />
* {{package|libsavitar}} 3MF file library<br />
* {{package|meshlab}}* A system for processing and editing unstructured 3D triangular<br />
* {{package|poly2tri}} A 2D constrained Delaunay triangulation library<br />
* {{package|opencsg}} Library for Constructive Solid Geometry using OpenGL<br />
* {{package|OpenTK}} C# library that wraps OpenGL, OpenCL and OpenAL<br />
* {{package|polyclipping}}* Polygon clipping library<br />
* {{package|python-admesh}} Python bindings for ADMesh, STL manipulation library<br />
* {{package|python-numpy-stl}} Library for reading, writing and modifying STL files<br />
* {{package|simarrange}} STL 2D plate packer with collision simulation<br />
* {{package|stlsplit}} Split STL file to more files - one shell each<br />
<br />
===G-code generators/processors===<br />
<br />
* {{package|slic3r}} G-code generator for 3D printers (RepRap, Makerbot, Ultimaker, etc)<br />
* {{package|slic3r-prusa3d}} G-code generator for 3D printers (RepRap, Makerbot, Ultimaker, etc) (fork of the above)<br />
* {{package|CuraEngine}} Engine for processing 3D models into G-code instructions for 3D<br />
* {{package|CuraEngine-lulzbot}} Engine for processing 3D models into G-code instructions for 3D (Lulzbot fork)<br />
* {{package|sfact}} Converts 3D model into G-Code for RepRap<br />
* {{package|skeinforge}} Converts 3D model into G-Code for RepRap<br />
<br />
===3D printer control software ===<br />
<br />
* {{package|cura}} 3D printer control software<br />
* {{package|cura-lulzbot}} Cura LulzBot Edition, 3D printer control software<br />
* {{package|printrun}} RepRap printer interface and tools<br />
* {{package|python-uranium}} A Python framework for building Desktop 3D printing applications<br />
* {{package|RepetierHost}} 3D printer control software<br />
* {{package|repsnapper}} RepRap control software<br />
<br />
===3D printer firmware ===<br />
<br />
* {{package|lulzbot-marlin-firmware}} Marlin firmware files for the Lulzbot family of 3D printers<br />
<br />
===Utilities===<br />
<br />
* {{package|libarcus}} Communication library between internal components for Ultimaker software<br />
* {{package|lmfit}} Levenberg-Marquardt least-squares minimization and curve fitting<br />
* {{package|python-power}} Cross-platform system/battery power status information<br />
* {{package|python-utils}} Python Utils is a module with some convenient utilities<br />
* {{package|python-zeroconf}} Pure Python Multicast DNS Service Discovery Library<br />
* {{package|rapidxml}} Fast XML parser<br />
* {{package|3dprinter-udev-rules}} Rules for udev to give regular users access to operate 3D printers<br />
<br />
===Data===<br />
* {{package|cura-fdm-materials}} Cura FDM Material database<br />
<br />
Packages with * are not maintained by the members of the SIG, but are important for us.<br />
<br />
== Packages waiting for your review ==<br />
<br />
Feel free to add the link here or send an e-mail to our mailing list, if you have some new packages waiting for review.<br />
<br />
* [https://bugzilla.redhat.com/show_bug.cgi?id=1340327 M3D-Linux] Linux program that can communicate with the Micro M3D printer<br />
<br />
== Packages not yet in Fedora ==<br />
<br />
Those packages are not yet ready to be in Fedora:<br />
<br />
* [https://copr.fedorainfracloud.org/coprs/churchyard/horus/ horus]<br />
<br />
== Packages that will never be in Fedora ==<br />
<br />
Those packages are not able to be in Fedora, because they are not free software. Use known alternate repositories to get them.<br />
<br />
* netfabb-basic<br />
* kisslicer<br />
<br />
== Mailing list ==<br />
<br />
* Join: [https://lists.fedoraproject.org/admin/lists/3dprinting@lists.fedoraproject.org/ 3dprinting]<br />
<br />
== IRC ==<br />
<br />
We hang out on irc.freenode.net at '''{{fpchat|#fedora-3dprinting}}'''.<br />
<br />
== Meetings ==<br />
<br />
This SIG does not have regular meetings.<br />
<br />
[[Category:SIGs]]<br />
[[Category:Fedora special-interest groups]]</div>Ausilhttps://fedoraproject.org/w/index.php?title=Fedora_27_Binutils_Mass_Rebuild&diff=498972Fedora 27 Binutils Mass Rebuild2017-08-03T13:22:46Z<p>Ausil: </p>
<hr />
<div>== Goal ==<br />
The goal is to rebuild every single Fedora package, regardless of<br />
content, before the Fedora 27 Feature Freeze Change Deadline.<br />
<br />
== Driving Features ==<br />
Prior to the initial [[ Fedora_27_Mass_Rebuild| Mass Rebuild ]] for Fedora 27 there was a bug intreduced in binutils https://bugzilla.redhat.com/show_bug.cgi?id=1475636 as a result we have not tagged the architecture specific builds into f27 and are rebuilding all architecture specific packages again. in a different tag.<br />
<br />
== Schedule ==<br />
Given the changes required for the above features and the given<br />
schedules, Release Engineering will be ready to start scripted rebuilds<br />
on Wednesday, August 2nd. All automated rebuilds should be finished prior to the Feature Freeze.<br />
Any clean-up manual rebuilds should be finished prior to the Bodhi Enablement Deadline.<br />
<br />
== Scripts ==<br />
Release Engineering has created two scripts. One is to initiate the builds, and the other is to query for items still needing to be built.<br />
<br />
=== Build Initiation ===<br />
The rebuild [https://pagure.io/releng/blob/master/f/scripts/mass-rebuild.py script] works in the following way:<br />
<br />
Generate a list of all packages in f27<br />
Loop through each package:<br />
Query if a build has already been attempted/completed since koji changes went live.<br />
If so, move to next package<br />
If not, check out git<br />
rpmdev-bumpspec<br />
fedpkg commit -cp<br />
fedpkg (background) build<br />
Move on to next package<br />
<br />
Each step will have some error catching and logging so that people<br />
can clean up the various failures for whatever reasons. The builds will<br />
be background builds, which will allow other builds done to take higher<br />
priority when a builder has a free slot. However maintainers should<br />
take care when doing this so that the background build won't take<br />
'latest' precedent when it finishes. Asking rel-eng to kill the<br />
scripted build will typically be enough.<br />
<br />
=== Build Tagging ===<br />
Once the rebuild script has finished, another [https://pagure.io/releng/blob/master/f/scripts/mass-tag.py script] will run to tag the builds into f27. This script will check that a newer build hasn't been done or started in f27 since the scripted rebuild was submitted. This will protect against the scripted rebuild overriding an even newer build done while the scripted rebuild was waiting in the background.<br />
<br />
=== Status Query ===<br />
Release Engineering has developed a [https://pagure.io/releng/blob/master/f/scripts/need-rebuild.py script] to query f27<br />
and report on packages that have yet to be rebuilt. Results of these<br />
queries will be delivered to various places, yet to be determined,<br />
broken down by maintainer for easier discovery of work needed.<br />
<br />
== Maintainer Actions ==<br />
* Maintainers can help this effort by ensuring '''rpmdev-bumpspec''' correctly bumps your package's spec files.<br />
* Maintainers should ensure that their packages currently build from source.<br />
* Maintainers should ensure that there are no unwanted changes committed to git but not built yet.<br />
<br />
== Frequently Asked Questions ==<br />
=== When will my own build "count" for the rebuild? ===<br />
After the last piece needed for the mass rebuild a rpm build was put into place, a build done by a maintainer will "count" toward the rebuild. 2017-07-25 20:27:50 is the UTC time that builds count from<br />
<br />
=== Will the rebuilds be ordered? ===<br />
Currently there is no plan to logically order the rebuilds based on deps. The ordering will be alphanumerical based on package name. There are no planned ABI/soname changes that would require logical build ordering. Further, all the builds will be kept in a special tag (f27-binutils-rebuild) until the whole run is done, and then they will be tagged into f27-pending in one shot to minimize the shuffle of buildroot contents during the rebuilds.<br />
<br />
== Feedback ==<br />
<br />
Questions/comments/concerns should be directed to [https://lists.fedoraproject.org/mailman/listinfo/devel], or #fedora-releng on freenode IRC.</div>Ausilhttps://fedoraproject.org/w/index.php?title=Fedora_27_Binutils_Mass_Rebuild&diff=498971Fedora 27 Binutils Mass Rebuild2017-08-03T13:22:23Z<p>Ausil: /* Driving Features */</p>
<hr />
<div>== Goal ==<br />
The goal is to rebuild every single Fedora package, regardless of<br />
content, before the Fedora 27 Feature Freeze Change Deadline.<br />
<br />
== Driving Features =<br />
Prior to the initial [[ Fedora_27_Mass_Rebuild| Mass Rebuild ]] for Fedora 27 there was a bug intreduced in binutils https://bugzilla.redhat.com/show_bug.cgi?id=1475636 as a result we have not tagged the architecture specific builds into f27 and are rebuilding all architecture specific packages again. in a different tag.<br />
<br />
== Schedule ==<br />
Given the changes required for the above features and the given<br />
schedules, Release Engineering will be ready to start scripted rebuilds<br />
on Wednesday, August 2nd. All automated rebuilds should be finished prior to the Feature Freeze.<br />
Any clean-up manual rebuilds should be finished prior to the Bodhi Enablement Deadline.<br />
<br />
== Scripts ==<br />
Release Engineering has created two scripts. One is to initiate the builds, and the other is to query for items still needing to be built.<br />
<br />
=== Build Initiation ===<br />
The rebuild [https://pagure.io/releng/blob/master/f/scripts/mass-rebuild.py script] works in the following way:<br />
<br />
Generate a list of all packages in f27<br />
Loop through each package:<br />
Query if a build has already been attempted/completed since koji changes went live.<br />
If so, move to next package<br />
If not, check out git<br />
rpmdev-bumpspec<br />
fedpkg commit -cp<br />
fedpkg (background) build<br />
Move on to next package<br />
<br />
Each step will have some error catching and logging so that people<br />
can clean up the various failures for whatever reasons. The builds will<br />
be background builds, which will allow other builds done to take higher<br />
priority when a builder has a free slot. However maintainers should<br />
take care when doing this so that the background build won't take<br />
'latest' precedent when it finishes. Asking rel-eng to kill the<br />
scripted build will typically be enough.<br />
<br />
=== Build Tagging ===<br />
Once the rebuild script has finished, another [https://pagure.io/releng/blob/master/f/scripts/mass-tag.py script] will run to tag the builds into f27. This script will check that a newer build hasn't been done or started in f27 since the scripted rebuild was submitted. This will protect against the scripted rebuild overriding an even newer build done while the scripted rebuild was waiting in the background.<br />
<br />
=== Status Query ===<br />
Release Engineering has developed a [https://pagure.io/releng/blob/master/f/scripts/need-rebuild.py script] to query f27<br />
and report on packages that have yet to be rebuilt. Results of these<br />
queries will be delivered to various places, yet to be determined,<br />
broken down by maintainer for easier discovery of work needed.<br />
<br />
== Maintainer Actions ==<br />
* Maintainers can help this effort by ensuring '''rpmdev-bumpspec''' correctly bumps your package's spec files.<br />
* Maintainers should ensure that their packages currently build from source.<br />
* Maintainers should ensure that there are no unwanted changes committed to git but not built yet.<br />
<br />
== Frequently Asked Questions ==<br />
=== When will my own build "count" for the rebuild? ===<br />
After the last piece needed for the mass rebuild a rpm build was put into place, a build done by a maintainer will "count" toward the rebuild. 2017-07-25 20:27:50 is the UTC time that builds count from<br />
<br />
=== Will the rebuilds be ordered? ===<br />
Currently there is no plan to logically order the rebuilds based on deps. The ordering will be alphanumerical based on package name. There are no planned ABI/soname changes that would require logical build ordering. Further, all the builds will be kept in a special tag (f27-binutils-rebuild) until the whole run is done, and then they will be tagged into f27-pending in one shot to minimize the shuffle of buildroot contents during the rebuilds.<br />
<br />
== Feedback ==<br />
<br />
Questions/comments/concerns should be directed to [https://lists.fedoraproject.org/mailman/listinfo/devel], or #fedora-releng on freenode IRC.</div>Ausilhttps://fedoraproject.org/w/index.php?title=Fedora_27_Binutils_Mass_Rebuild&diff=498969Fedora 27 Binutils Mass Rebuild2017-08-03T13:13:35Z<p>Ausil: Created page with "== Goal == The goal is to rebuild every single Fedora package, regardless of content, before the Fedora 27 Feature Freeze Change Deadline. == Driving Features == * [[Changes/..."</p>
<hr />
<div>== Goal ==<br />
The goal is to rebuild every single Fedora package, regardless of<br />
content, before the Fedora 27 Feature Freeze Change Deadline.<br />
<br />
== Driving Features ==<br />
* [[Changes/golang1.9| golang 1.9 ]]<br />
<br />
== Schedule ==<br />
Given the changes required for the above features and the given<br />
schedules, Release Engineering will be ready to start scripted rebuilds<br />
on Wednesday, August 2nd. All automated rebuilds should be finished prior to the Feature Freeze.<br />
Any clean-up manual rebuilds should be finished prior to the Bodhi Enablement Deadline.<br />
<br />
== Scripts ==<br />
Release Engineering has created two scripts. One is to initiate the builds, and the other is to query for items still needing to be built.<br />
<br />
=== Build Initiation ===<br />
The rebuild [https://pagure.io/releng/blob/master/f/scripts/mass-rebuild.py script] works in the following way:<br />
<br />
Generate a list of all packages in f27<br />
Loop through each package:<br />
Query if a build has already been attempted/completed since koji changes went live.<br />
If so, move to next package<br />
If not, check out git<br />
rpmdev-bumpspec<br />
fedpkg commit -cp<br />
fedpkg (background) build<br />
Move on to next package<br />
<br />
Each step will have some error catching and logging so that people<br />
can clean up the various failures for whatever reasons. The builds will<br />
be background builds, which will allow other builds done to take higher<br />
priority when a builder has a free slot. However maintainers should<br />
take care when doing this so that the background build won't take<br />
'latest' precedent when it finishes. Asking rel-eng to kill the<br />
scripted build will typically be enough.<br />
<br />
=== Build Tagging ===<br />
Once the rebuild script has finished, another [https://pagure.io/releng/blob/master/f/scripts/mass-tag.py script] will run to tag the builds into f27. This script will check that a newer build hasn't been done or started in f27 since the scripted rebuild was submitted. This will protect against the scripted rebuild overriding an even newer build done while the scripted rebuild was waiting in the background.<br />
<br />
=== Status Query ===<br />
Release Engineering has developed a [https://pagure.io/releng/blob/master/f/scripts/need-rebuild.py script] to query f27<br />
and report on packages that have yet to be rebuilt. Results of these<br />
queries will be delivered to various places, yet to be determined,<br />
broken down by maintainer for easier discovery of work needed.<br />
<br />
== Maintainer Actions ==<br />
* Maintainers can help this effort by ensuring '''rpmdev-bumpspec''' correctly bumps your package's spec files.<br />
* Maintainers should ensure that their packages currently build from source.<br />
* Maintainers should ensure that there are no unwanted changes committed to git but not built yet.<br />
<br />
== Frequently Asked Questions ==<br />
=== When will my own build "count" for the rebuild? ===<br />
After the last piece needed for the mass rebuild a rpm build was put into place, a build done by a maintainer will "count" toward the rebuild. 2017-07-25 20:27:50 is the UTC time that builds count from<br />
<br />
=== Will the rebuilds be ordered? ===<br />
Currently there is no plan to logically order the rebuilds based on deps. The ordering will be alphanumerical based on package name. There are no planned ABI/soname changes that would require logical build ordering. Further, all the builds will be kept in a special tag (f27-binutils-rebuild) until the whole run is done, and then they will be tagged into f27-pending in one shot to minimize the shuffle of buildroot contents during the rebuilds.<br />
<br />
== Feedback ==<br />
<br />
Questions/comments/concerns should be directed to [https://lists.fedoraproject.org/mailman/listinfo/devel], or #fedora-releng on freenode IRC.</div>Ausilhttps://fedoraproject.org/w/index.php?title=Development/SteeringCommittee/Nominations&diff=498422Development/SteeringCommittee/Nominations2017-07-28T12:39:30Z<p>Ausil: </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 31, 2017! }}<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 />
<!--{{admon/important|The nomination period is CLOSED|The nomination period ended at 23:59:59 UTC on July 11th, 2016.}}--><br />
<!--{{admon/important|The nomination period is CLOSED. The nomination period ended at 23:59:59 UTC on May 15, 2012.}}--><br />
<!-- {{admon/important|The nomination period is CLOSED|The nomination period ended at 23:59:59 UTC on December 12th, 2016.}} --><br />
<br />
The following [[Elections|elections]] take place from [https://fedorapeople.org/groups/schedule/f-26/f-26-elections.html July 2017 to August 2017]:<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-26/f-26-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/August 2017 =<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 F25/F26 period<br />
* [[User:Ausil| Dennis Gilmore]] (dgilmore) - elected for F25/F26 period<br />
* [[User:Rathann| Dominik Mierzejewski]] (rathann) - elected for F25/F26 period<br />
* [[User:Sgallagh| Stephen Gallagher]] (sgallagh) - elected for F25/F26 period<br />
<br />
For the last election, see [https://fedoraproject.org/w/index.php?title=Development/SteeringCommittee/Nominations&oldid=483566 Nominations December 2016]<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 />
[[Category:FESCo]] [[Category:Elections]]<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 />
You may self-nominate. If you wish to nominate someone else, please consult with that person ahead of time.<br />
<br />
* NAME (IRC nick/FAS account ID) [nominated by: FAS account ID]<br />
<br />
* Dominik Mierzejewski (Rathann/rathann) [self-nominated]<br />
<br />
* Stephen Gallagher (sgallagh/sgallagh) [self-nominated]<br />
<br />
* Randy Barlow (bowlofeggs/bowlofeggs) [self-nominated]<br />
* [[User:Ausil | Dennis Gilmore]] (dgilmore / ausil) [self-nominated]</div>Ausilhttps://fedoraproject.org/w/index.php?title=Council/Nominations&diff=498420Council/Nominations2017-07-28T12:38:27Z<p>Ausil: /* 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 31, 2017! }}<br />
<!--{{admon/important|We're OPEN!|The nomination period is in progress! Please add your nomination before 23:59:59 UTC on December 12th, 2016! }}--><br />
<!--{{admon/important|The nomination period has not yet begun. Please add your nomination on or after November 17, 2015 UTC.}}--><br />
<!--{{admon/important|The nomination period is CLOSED|The nomination period ended at 23:59:59 UTC on July 11th, 2016.}}--><br />
<!--{{admon/important|We're OPEN!|The nomination period is in progress. Please add your nomination before 23:59:59 UTC on July 11, 2016! }}--><br />
<!--{{admon/tip | VOTE FOR YOUR FAVORITE CANDIDATES. | Fedora contributors can elect the Fedora Board at https://admin.fedoraproject.org/voting/about/board-december2012.<br />
<br />DEADLINE: January 30, 23:59:59 UTC}}--><br />
<!--{{admon/important|We're OPEN!|The nomination period is in progress! Please add your nomination before 23:59:59 UTC on 2016-July11!}}--><br />
<!-- {{admon/important|The nomination period is CLOSED|The nomination period ended at 23:59:59 UTC on December 12th, 2016.}} --><br />
<br />
The following [[Elections|elections]] take place from [https://fedorapeople.org/groups/schedule/f-26/f-26-elections.html July 2017 to August 2017]:<br />
<br />
* [[Council/Nominations|Council]] (one seat)<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 />
See [[Council]] page for more details regarding Council goals and structure.<br />
<br />
See [https://fedorapeople.org/groups/schedule/f-26/f-26-elections.html Election Schedule] page for more details regarding the Elections timeline.<br />
All dates and times noted are UTC time.<br />
<br />
= Council Elections July/August 2017 =<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.<br />
<br />
The following Council members finish their terms, and the seats are up for re-election:<br />
<br />
* [[User:langdon| Langdon White]] (langdon) - elected for F25/F26 period<br />
<br />
<br />
<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 the [[Council|Council]] you must have cla_done in FAS.}}<br />
<br />
[[Category:Council]] [[Category:Elections]]<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 />
You may self-nominate. If you wish to nominate someone else, please consult with that person ahead of time.<br />
<br />
* NAME (IRC nick/FAS account ID) [nominated by: FAS account ID]<br />
<br />
* [[User:Jflory7 | Justin W. Flory]] (jwf / jflory7) [cprofitt and self-nominated]<br />
* [[User:langdon | Langdon White]] (langdon) [self-nominated]<br />
* [[User:Nb | Nick Bebout]] (nb) [self-nominated]<br />
* [[User:Ausil | Dennis Gilmore]] (dgilmore / ausil) [self-nominated]</div>Ausilhttps://fedoraproject.org/w/index.php?title=Infrastructure/Factory2/Focus/ArbitraryBranching&diff=497228Infrastructure/Factory2/Focus/ArbitraryBranching2017-07-10T02:35:07Z<p>Ausil: /* How This Affects Release Engineering (WIP) */</p>
<hr />
<div><br />
== What is a Focus Document? ==<br />
<br />
The Factory 2.0 team produces a confusing number of documents. The first round was about the Problem Statements we were trying to solve. Let’s retroactively call them Problem Documents. The Focus Documents (like this one) focus on some system or some aspect of our solutions that cut across different problems. The content here doesn’t fit cleanly in one problem statement document, which is why we broke it out.<br />
<br />
This document provides more detail to the [[Changes/ArbitraryBranching]] proposal.<br />
<br />
== Background on PkgDB ==<br />
<br />
PkgDB is the central repository for information on all packages in Fedora. Its primary job is to manage the ACLs of a package’s dist-git branches, but it’s also an interface to request new packages in Fedora and view metadata about packages such as a summary of its purpose and external links to a package’s builds, updates, and source. It is a central part of Fedora’s workflow today.<br />
<br />
PkgDB in general works well for the current workflow of a package’s lifecycle. Currently, a package has several branches that are tied to Fedora releases such as “f24” or “f25”. These branches have implied service level agreements (SLAs) and end of life (EOL) dates based on the Fedora release itself. There are also additional branches for Extra Packages For Enterprise Linux (EPEL), which implicitly share the EOL of its RHEL/CentOS counterpart. The SLA on EPEL branches are strict as they cannot contain any breaking changes; therefore, a package’s EPEL branches are only updated with bug fixes, security fixes, and features which do not alter the current behavior.<br />
<br />
Although the implied SLAs and EOLs in these branches have worked well for Fedora in the past, it’s becoming increasingly difficult to juggle these different application lifecycles and their dependencies’ lifecycles under the umbrella of these limited number of SLAs and EOLs, especially when trying to keep up with upstream. Please read about the [https://docs.pagure.org/modularity/ Fedora Modularity project] for more argument on this position.<br />
<br />
== Why Make This Change? ==<br />
<br />
Factory 2.0 is an enabler for the Modularity project and that project will change how a package’s SLA and EOL are defined. Since in a modular operating system (OS) a single package is no longer tied to the entire OS distribution, module packagers can now specify which specific packages should be included in the module. This allows for different branches with different SLAs and EOLs. For instance, you may have a bug and security fix only branch for a specific version of a package, but you may have another branch that is the same as the upstream master branch for the package. This added flexibility can allow for a package’s SLA and EOL to be defined to fulfill the needs of the module rather than just the OS release.<br />
<br />
To further clarify this point, there are some graphics from Ralph Bean’s Factory 2.0 presentation from DevConf 2017 which show the proposed changes in branching. Below are two of those graphics; the first illustrates the current branching strategy and the one below illustrates the new branching strategy that will come with Modularity.<br />
<br />
[[File:Arbitrarybranching-1.png]]<br />
<br />
[[File:Arbitrarybranching-2.png]]<br />
<br />
To further illustrate, below is a graphic of two versions of a django module and how it utilizes this new branching strategy.<br />
* The 1.9 django module utilizes the 2.12 python-requests branch and the 1.9 python-django branch. The 2.12 python-requests branch in this case would most likely only be updated with bug fix releases (i.e. 2.12.x). The same would apply for the 1.9 python-django branch.<br />
* On the other hand, the 1.10 django module utilizes the master branch of python-requests which means that whenever the module is built, it’ll just be using the latest packaged version available. This introduces a potential risk as their could in theory be breaking changes to python-requests, but it could be deemed that whatever benefits that the latest upstream provides are worth the risk of potential incompatibilities in the future.<br />
<br />
These are all decisions that module packagers will make and they should be based on the SLA and EOL they specify for their module. Now whether the module packager made the correct decisions is out of the scope of this document and best practices around this should be written by the Modularity team. One thing that is not clear in this graphic is that although these branches are named after versions and it makes logical sense, they do not have to be and could be named anything that the packager of the RPM would like; therefore, modules should choose RPMs because of their EOLs and SLAs, not because of the name.<br />
<br />
[[File:Arbitrarybranching-3.png]]<br />
<br />
== How To Make This Change ==<br />
<br />
Since PkgDB is tied to the workflow of one branch per OS distribution, it needs to be heavily modified or entirely replaced to allow a packager to arbitrarily specify branch names for their package. Since these branches are no longer tied to the lifecycle of the Fedora release, they will need to have SLAs and EOLs defined by the packager for the given package. The SLAs should be defined through a variety machine readable parameters. The specific parameters will be decided later on and this should be decided upon by the Fedora community before the release of these changes. The Factory 2.0 team thought about modifying PkgDB but Pierre-Yves Chibon/pingou (the author of PkgDB) noted that with Pagure being deployed over dist-git in Fedora (as of this writing it is deployed in staging), it, alongside of PDC, could be a viable option to replace PkgDB.<br />
<br />
With Pagure over dist-git and PDC (both with modifications), we could do away with PkgDB entirely for the new branching strategy and retrofit it for older branches (EPEL6/7 and F24/25/26) that we must support. This change would mean that ACLs would no longer be tied to branches but instead to the repository itself. One could either allow any packager with repository commit access to push to any branch, or not allow packagers to push to any branches and instead, only submit pull-requests which can then be merged by maintainers of the repository. To gain rights on the repository, you’d have to be given commit access the specific package repository.<br />
<br />
There are other use cases for PkgDB other than ACL management. For instance, PkgDB is responsible for the implicit EOL and SLA information tied to the Fedora release branches (e.g f25), however, this new EOL and SLA information needs to be explicit and stored somewhere that is accessible programmatically. There are two approaches to solve this problem that have come up in discussions.<br />
* The first option is to create a Product Definition Center (PDC) endpoint to contain the EOL and SLA information. These entries would most likely be requested through a ticket and upon approval, the entry in PDC would be created. Pagure would restrict the creation of new branches to those that have an EOL and SLA defined in PDC.<br />
* The second option is to keep a separate git repository with a YAML file containing the EOL and SLA information of the package branch. This YAML file cannot be in the same repository as the package because it will then never be able to share the same codebase as another branch, which is a requirement for some packagers.<br />
<br />
We decided that option one is the right approach, and here are video demos showing that functionality:<br />
* [https://fedorapeople.org/groups/factory2/sprint-014/mprahl-pdc-sla-apis.mp4 PDC SLA APIs] (currently in production PDC in Fedora)<br />
* [https://fedorapeople.org/groups/factory2/sprint-028/mprahl-pdc-module-slas.mp4 PDC SLA APIs with Modularity]<br />
<br />
PkgDB also has an “Admin Actions” section which is basically a ticketing system that allows new packages to be requested and approved. This could be replaced with a Release Engineering (releng) controlled Pagure repository just for tickets. CLI tools will be provided that make and process these tickets. This method also opens the door for some of these tickets to be automatically processed by a microservice that listens for new ticket messages. This microservice is beyond the scope of this project, but it is worth mentioning as a future enhancement.<br />
<br />
PkgDB also keeps track of orphaned packages which are just packages with no owners. Ideally this functionality would be replaced with a query to Pagure or PDC. Querying Pagure would just be an API call asking for all projects that are owned by the "orphan" user. Another feature of PkgDB is that it keeps track of retired packages. Retired packages are currently distinguished by a file named “DEAD.package” in their repository. We would continue to do this, but would also mark all of the package's branches as "not active" in PDC to allow this to be queryable programatically. PkgDB is also a source for determining the default assignee and carbon copy (CC) list for new Bugzilla bugs. The default assignee of a bug would likely be the owner of the Pagure repository, but this point is up for discussion. As to the second point, a new feature is being added to Pagure to allow a user to watch only issues and PRs, only commits, or both on a project ([https://pagure.io/pagure/pull-request/2255 PR #2255]). The users that are at least watching the issues in the Pagure repository would then be CC'd in Bugzilla bugs. PkgDB is also a source for generating “PackageName-owners@fedoraproject.org” email aliases. The members to these aliases would be determined by the list of users that have commit access on a package repository in Pagure. PkgDB also determines who is allowed to edit Bodhi updates. This could be determined again by querying for the list of users with commit access in Pagure.<br />
<br />
The drawback to these Pagure queries is that the queries could be relatively slow and would use up a lot of resources on the Pagure server(s). An idea to alleviate this is to programmatically query Pagure when package ownership changes or a package is retired. The results would then be stored in a JSON file that is accessible through the proxies or available in PDC instead. Further discussion on this topic is needed.<br />
<br />
== How This Affects Release Engineering (WIP) ==<br />
<br />
* Need a way to enforce that a module’s SLA and EOL is not greater than the lowest common denominator of it’s components<br />
* “cvsadmins” currently process new package requests with the “pkgdb-admin” CLI tool. This will need to be done in Pagure with a new tool. We got the approval from limb on this.<br />
* When package branches go EOL (on their own terms), Release Engineering will need tooling to make the retirement of those branches happen. Things such as sending emails to the relevant people will need to happen.<br />
* Does the mass branch process go away or do we need a new equivalent version of that process for modules?<br />
<br />
== Additional Tooling Changes ==<br />
<br />
* PkgDB is often queried to determine what the latest active releases are. This data will need to be stored in PDC instead.<br />
* Zodbot queries PkgDB to figure out the latest release for cookies. It will need to query PDC instead.<br />
* Bodhi queries PkgDB to find the list of critpath packages in a collection. This will need to use PDC instead.<br />
* Not really related to PkgDB, but to branch names: How will the branches be tied to Koji? Currently `fedpkg` uses the branch name to generate the correct dist tag, and checks if the build already exists based on the generated NVR. The mapping from branch names to dist tags in the tools would have to be updated.<br />
<br />
== General Work Plan ==<br />
<br />
Below is an itemized list of big tasks that roughly need to happen in order. At what point do we get to decommission pkgdb? What subprojects are blocked on what other subprojects?<br />
<br />
* [done] Have the Modularity team and/or Fedora Community devise a machine readable scale for SLAs with a series of parameters that include: bugs will be fixed, security issues will be fixed, how fast CVEs will be addressed, non-breaking features will be added, breaking changes will be added. These parameters will either be boolean values or time durations.<br />
* [done] Add a PDC endpoint to allow storing the new EOL and SLA information (include ability to retire packages)<br />
* Add the following features to Pagure<br />
** [done] Add the ability to view a repository's owners, admins, and committers through the API<br />
** [done] Add the ability to give ownership of a package<br />
** [done] Add the ability to view a repo's branches through the API<br />
** [done] Add the ability to query projects via namespace through the API<br />
** [in progress at the time of publication] Add the ability to watch issues and PRs, commits, or both.<br />
** Add the ability to generate a user API key to create new issues on a specific project<br />
** Need a git hook to deny creating new branches via git if they don’t also appear in PDC. This needs to apply only to mainline dist-git branches. The “forked” dist-git branches under your personal username should allow arbitrary branches.<br />
* Solidify a strategy for retiring and manually decommissioning branches<br />
* Release a new version of Pagure that sits on top of dist-git<br />
* Offload ticketing of new package requests to pagure.io/SOMEPROJECT<br />
** Use a Pagure repo for this on https://pagure.io. Ask releng and “cvsadmins” if they want to use pagure.io/releng or if they want a brand new repo just for new package requests.<br />
** Enforce that all tickets have an EOL and SLA for the specified package branch<br />
** Create a CLI tool for the workflow of package requests from Pagure<br />
* [done at this publication but not in use yet] Update the script to generate the “PackageName-owners@fedoraproject.org” mail aliases from the list of package owners to use Pagure<br />
* Restrict who can edit Bodhi updates based on the list of owners in Pagure<br />
* Modify the Bugzilla sync script to set the owner/default cc list in Bugzilla based on Pagure data<br />
* [done at this publication but not in use yet] Modify the Koji sync script that sets the packagelist owner in Koji based on Pagure data<br />
* Lastly, decommission PkgDB</div>Ausilhttps://fedoraproject.org/w/index.php?title=Infrastructure/Factory2/Focus/ArbitraryBranching&diff=497227Infrastructure/Factory2/Focus/ArbitraryBranching2017-07-10T02:34:31Z<p>Ausil: /* How This Affects RCM (WIP) */ RCM is a unknown term in Fedora please do not use it</p>
<hr />
<div><br />
== What is a Focus Document? ==<br />
<br />
The Factory 2.0 team produces a confusing number of documents. The first round was about the Problem Statements we were trying to solve. Let’s retroactively call them Problem Documents. The Focus Documents (like this one) focus on some system or some aspect of our solutions that cut across different problems. The content here doesn’t fit cleanly in one problem statement document, which is why we broke it out.<br />
<br />
This document provides more detail to the [[Changes/ArbitraryBranching]] proposal.<br />
<br />
== Background on PkgDB ==<br />
<br />
PkgDB is the central repository for information on all packages in Fedora. Its primary job is to manage the ACLs of a package’s dist-git branches, but it’s also an interface to request new packages in Fedora and view metadata about packages such as a summary of its purpose and external links to a package’s builds, updates, and source. It is a central part of Fedora’s workflow today.<br />
<br />
PkgDB in general works well for the current workflow of a package’s lifecycle. Currently, a package has several branches that are tied to Fedora releases such as “f24” or “f25”. These branches have implied service level agreements (SLAs) and end of life (EOL) dates based on the Fedora release itself. There are also additional branches for Extra Packages For Enterprise Linux (EPEL), which implicitly share the EOL of its RHEL/CentOS counterpart. The SLA on EPEL branches are strict as they cannot contain any breaking changes; therefore, a package’s EPEL branches are only updated with bug fixes, security fixes, and features which do not alter the current behavior.<br />
<br />
Although the implied SLAs and EOLs in these branches have worked well for Fedora in the past, it’s becoming increasingly difficult to juggle these different application lifecycles and their dependencies’ lifecycles under the umbrella of these limited number of SLAs and EOLs, especially when trying to keep up with upstream. Please read about the [https://docs.pagure.org/modularity/ Fedora Modularity project] for more argument on this position.<br />
<br />
== Why Make This Change? ==<br />
<br />
Factory 2.0 is an enabler for the Modularity project and that project will change how a package’s SLA and EOL are defined. Since in a modular operating system (OS) a single package is no longer tied to the entire OS distribution, module packagers can now specify which specific packages should be included in the module. This allows for different branches with different SLAs and EOLs. For instance, you may have a bug and security fix only branch for a specific version of a package, but you may have another branch that is the same as the upstream master branch for the package. This added flexibility can allow for a package’s SLA and EOL to be defined to fulfill the needs of the module rather than just the OS release.<br />
<br />
To further clarify this point, there are some graphics from Ralph Bean’s Factory 2.0 presentation from DevConf 2017 which show the proposed changes in branching. Below are two of those graphics; the first illustrates the current branching strategy and the one below illustrates the new branching strategy that will come with Modularity.<br />
<br />
[[File:Arbitrarybranching-1.png]]<br />
<br />
[[File:Arbitrarybranching-2.png]]<br />
<br />
To further illustrate, below is a graphic of two versions of a django module and how it utilizes this new branching strategy.<br />
* The 1.9 django module utilizes the 2.12 python-requests branch and the 1.9 python-django branch. The 2.12 python-requests branch in this case would most likely only be updated with bug fix releases (i.e. 2.12.x). The same would apply for the 1.9 python-django branch.<br />
* On the other hand, the 1.10 django module utilizes the master branch of python-requests which means that whenever the module is built, it’ll just be using the latest packaged version available. This introduces a potential risk as their could in theory be breaking changes to python-requests, but it could be deemed that whatever benefits that the latest upstream provides are worth the risk of potential incompatibilities in the future.<br />
<br />
These are all decisions that module packagers will make and they should be based on the SLA and EOL they specify for their module. Now whether the module packager made the correct decisions is out of the scope of this document and best practices around this should be written by the Modularity team. One thing that is not clear in this graphic is that although these branches are named after versions and it makes logical sense, they do not have to be and could be named anything that the packager of the RPM would like; therefore, modules should choose RPMs because of their EOLs and SLAs, not because of the name.<br />
<br />
[[File:Arbitrarybranching-3.png]]<br />
<br />
== How To Make This Change ==<br />
<br />
Since PkgDB is tied to the workflow of one branch per OS distribution, it needs to be heavily modified or entirely replaced to allow a packager to arbitrarily specify branch names for their package. Since these branches are no longer tied to the lifecycle of the Fedora release, they will need to have SLAs and EOLs defined by the packager for the given package. The SLAs should be defined through a variety machine readable parameters. The specific parameters will be decided later on and this should be decided upon by the Fedora community before the release of these changes. The Factory 2.0 team thought about modifying PkgDB but Pierre-Yves Chibon/pingou (the author of PkgDB) noted that with Pagure being deployed over dist-git in Fedora (as of this writing it is deployed in staging), it, alongside of PDC, could be a viable option to replace PkgDB.<br />
<br />
With Pagure over dist-git and PDC (both with modifications), we could do away with PkgDB entirely for the new branching strategy and retrofit it for older branches (EPEL6/7 and F24/25/26) that we must support. This change would mean that ACLs would no longer be tied to branches but instead to the repository itself. One could either allow any packager with repository commit access to push to any branch, or not allow packagers to push to any branches and instead, only submit pull-requests which can then be merged by maintainers of the repository. To gain rights on the repository, you’d have to be given commit access the specific package repository.<br />
<br />
There are other use cases for PkgDB other than ACL management. For instance, PkgDB is responsible for the implicit EOL and SLA information tied to the Fedora release branches (e.g f25), however, this new EOL and SLA information needs to be explicit and stored somewhere that is accessible programmatically. There are two approaches to solve this problem that have come up in discussions.<br />
* The first option is to create a Product Definition Center (PDC) endpoint to contain the EOL and SLA information. These entries would most likely be requested through a ticket and upon approval, the entry in PDC would be created. Pagure would restrict the creation of new branches to those that have an EOL and SLA defined in PDC.<br />
* The second option is to keep a separate git repository with a YAML file containing the EOL and SLA information of the package branch. This YAML file cannot be in the same repository as the package because it will then never be able to share the same codebase as another branch, which is a requirement for some packagers.<br />
<br />
We decided that option one is the right approach, and here are video demos showing that functionality:<br />
* [https://fedorapeople.org/groups/factory2/sprint-014/mprahl-pdc-sla-apis.mp4 PDC SLA APIs] (currently in production PDC in Fedora)<br />
* [https://fedorapeople.org/groups/factory2/sprint-028/mprahl-pdc-module-slas.mp4 PDC SLA APIs with Modularity]<br />
<br />
PkgDB also has an “Admin Actions” section which is basically a ticketing system that allows new packages to be requested and approved. This could be replaced with a Release Engineering (releng) controlled Pagure repository just for tickets. CLI tools will be provided that make and process these tickets. This method also opens the door for some of these tickets to be automatically processed by a microservice that listens for new ticket messages. This microservice is beyond the scope of this project, but it is worth mentioning as a future enhancement.<br />
<br />
PkgDB also keeps track of orphaned packages which are just packages with no owners. Ideally this functionality would be replaced with a query to Pagure or PDC. Querying Pagure would just be an API call asking for all projects that are owned by the "orphan" user. Another feature of PkgDB is that it keeps track of retired packages. Retired packages are currently distinguished by a file named “DEAD.package” in their repository. We would continue to do this, but would also mark all of the package's branches as "not active" in PDC to allow this to be queryable programatically. PkgDB is also a source for determining the default assignee and carbon copy (CC) list for new Bugzilla bugs. The default assignee of a bug would likely be the owner of the Pagure repository, but this point is up for discussion. As to the second point, a new feature is being added to Pagure to allow a user to watch only issues and PRs, only commits, or both on a project ([https://pagure.io/pagure/pull-request/2255 PR #2255]). The users that are at least watching the issues in the Pagure repository would then be CC'd in Bugzilla bugs. PkgDB is also a source for generating “PackageName-owners@fedoraproject.org” email aliases. The members to these aliases would be determined by the list of users that have commit access on a package repository in Pagure. PkgDB also determines who is allowed to edit Bodhi updates. This could be determined again by querying for the list of users with commit access in Pagure.<br />
<br />
The drawback to these Pagure queries is that the queries could be relatively slow and would use up a lot of resources on the Pagure server(s). An idea to alleviate this is to programmatically query Pagure when package ownership changes or a package is retired. The results would then be stored in a JSON file that is accessible through the proxies or available in PDC instead. Further discussion on this topic is needed.<br />
<br />
== How This Affects Release Engineering (WIP) ==<br />
<br />
* Need a way to enforce that a module’s SLA and EOL is not greater than the lowest common denominator of it’s components<br />
* “cvsadmins” currently process new package requests with the “pkgdb-admin” CLI tool. This will need to be done in Pagure with a new tool. We got the approval from limb on this.<br />
* When package branches go EOL (on their own terms), RCM will need tooling to make the retirement of those branches happen. Things such as sending emails to the relevant people will need to happen.<br />
* Does the mass branch process go away or do we need a new equivalent version of that process for modules?<br />
<br />
== Additional Tooling Changes ==<br />
<br />
* PkgDB is often queried to determine what the latest active releases are. This data will need to be stored in PDC instead.<br />
* Zodbot queries PkgDB to figure out the latest release for cookies. It will need to query PDC instead.<br />
* Bodhi queries PkgDB to find the list of critpath packages in a collection. This will need to use PDC instead.<br />
* Not really related to PkgDB, but to branch names: How will the branches be tied to Koji? Currently `fedpkg` uses the branch name to generate the correct dist tag, and checks if the build already exists based on the generated NVR. The mapping from branch names to dist tags in the tools would have to be updated.<br />
<br />
== General Work Plan ==<br />
<br />
Below is an itemized list of big tasks that roughly need to happen in order. At what point do we get to decommission pkgdb? What subprojects are blocked on what other subprojects?<br />
<br />
* [done] Have the Modularity team and/or Fedora Community devise a machine readable scale for SLAs with a series of parameters that include: bugs will be fixed, security issues will be fixed, how fast CVEs will be addressed, non-breaking features will be added, breaking changes will be added. These parameters will either be boolean values or time durations.<br />
* [done] Add a PDC endpoint to allow storing the new EOL and SLA information (include ability to retire packages)<br />
* Add the following features to Pagure<br />
** [done] Add the ability to view a repository's owners, admins, and committers through the API<br />
** [done] Add the ability to give ownership of a package<br />
** [done] Add the ability to view a repo's branches through the API<br />
** [done] Add the ability to query projects via namespace through the API<br />
** [in progress at the time of publication] Add the ability to watch issues and PRs, commits, or both.<br />
** Add the ability to generate a user API key to create new issues on a specific project<br />
** Need a git hook to deny creating new branches via git if they don’t also appear in PDC. This needs to apply only to mainline dist-git branches. The “forked” dist-git branches under your personal username should allow arbitrary branches.<br />
* Solidify a strategy for retiring and manually decommissioning branches<br />
* Release a new version of Pagure that sits on top of dist-git<br />
* Offload ticketing of new package requests to pagure.io/SOMEPROJECT<br />
** Use a Pagure repo for this on https://pagure.io. Ask releng and “cvsadmins” if they want to use pagure.io/releng or if they want a brand new repo just for new package requests.<br />
** Enforce that all tickets have an EOL and SLA for the specified package branch<br />
** Create a CLI tool for the workflow of package requests from Pagure<br />
* [done at this publication but not in use yet] Update the script to generate the “PackageName-owners@fedoraproject.org” mail aliases from the list of package owners to use Pagure<br />
* Restrict who can edit Bodhi updates based on the list of owners in Pagure<br />
* Modify the Bugzilla sync script to set the owner/default cc list in Bugzilla based on Pagure data<br />
* [done at this publication but not in use yet] Modify the Koji sync script that sets the packagelist owner in Koji based on Pagure data<br />
* Lastly, decommission PkgDB</div>Ausilhttps://fedoraproject.org/w/index.php?title=Test_Results:Fedora_26_Beta_1.4_Server&diff=494181Test Results:Fedora 26 Beta 1.4 Server2017-06-02T16:28:52Z<p>Ausil: /* Release-blocking roles */</p>
<hr />
<div>{{Release_validation_instructions|testtype=Server|release=26|milestone=Beta|compose=1.4|date=}}<br />
<br />
{{anchor|results}}<br />
== '''Test Matrix''' ==<br />
<br />
<onlyinclude><br />
==== General tests ====<br />
{| class="wikitable sortable collapsible" width=100%<br />
|-<br />
! Milestone !! Test Case !! x86 !! ARM<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_kickstart_firewall_disabled]]<br />
| {{result|pass|coconut|bot=true}}<br />
| {{result|pass|<previous RC1.3 run>}}<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_kickstart_firewall_configured]]<br />
| {{result|pass|coconut|bot=true}}<br />
| {{result|pass|<previous RC1.3 run>}}<br />
|-<br />
| Alpha<br />
| [[ QA:Testcase_Server_firewall_default]]<br />
| {{result|pass|coconut|bot=true}}<br />
| {{result|pass|pwhalen}}<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_Server_cockpit_default]]<br />
| {{result|pass|coconut|bot=true}}<br />
| {{result|pass|pwhalen}}<br />
|-<br />
| Beta<br />
| [[QA:Testcase_Server_cockpit_basic]]<br />
| {{result|pass|coconut|bot=true}}<br />
| {{result|pass|pwhalen}}<br />
|-<br />
|}<br />
<references/><br />
<br />
==== Domain joining tests: '''FreeIPA''' ====<br />
{| class="wikitable sortable collapsible" width=100%<br />
|-<br />
! Milestone !! Test Case !! Result<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_realmd_join_kickstart]]<br />
| {{result|pass|coconut|bot=true}}<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_realmd_join_sssd]]<br />
| {{result|pass|coconut|bot=true}}<br />
|-<br />
| Beta<br />
| [[QA:Testcase_realmd_join_cockpit]]<br />
| {{result|pass|coconut|bot=true}}<br />
|-<br />
|}<br />
<references/><br />
<br />
==== Domain joining tests: '''Active Directory''' ====<br />
{| class="wikitable sortable collapsible" width=100%<br />
|-<br />
! Milestone !! Test Case !! Result<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_realmd_join_kickstart]]<br />
| {{result|pass|sgallagh}}<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_realmd_join_sssd]]<br />
| {{result|pass|<previous RC1.3 run>}}<br />
|-<br />
| Beta<br />
| [[QA:Testcase_realmd_join_cockpit]]<br />
| {{result|pass|<previous RC1.3 run>}}<br />
|-<br />
|}<br />
<references/><br />
<br />
==== Domain client tests ====<br />
{| class="wikitable sortable collapsible" width=100%<br />
|-<br />
! Milestone !! Test Case !! Result<br />
|-<br />
| Beta<br />
| [[QA:Testcase_domain_client_authenticate]] (FreeIPA)<br />
| {{result|pass|coconut|bot=true}}<br />
|-<br />
| Final<br />
| [[QA:Testcase_FreeIPA_realmd_login]]<br />
| {{result|pass|coconut|bot=true}}<br />
|-<br />
| Optional<br />
| [[QA:Testcase_domain_client_authenticate]] (Active Directory)<br />
| {{result|pass|<previous RC1.3 run>}}<br />
|}<br />
<references/><br />
<br />
==== Release-blocking roles ====<br />
{{admon/note|Single test table|In all of these tests, the test case used is [[QA:Testcase Server role deploy]]. That is where the links point. The test must be run for each release-blocking role.}}<br />
{| class="wikitable sortable collapsible" width=100%<br />
|-<br />
! Milestone !! Test Case !! x86 !! ARM<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_Server_role_deploy|Domain controller]]<br />
| {{result|pass|coconut|bot=true}}<br />
| {{result|pass|ausil}}<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_Server_role_deploy|Database server]]<br />
| {{result|pass|coconut|bot=true}}<br />
| {{result|pass|ausil}}<br />
|-<br />
|}<br />
<references/><br />
<br />
===== Domain controller role =====<br />
{| class="wikitable sortable collapsible" width=100%<br />
|-<br />
! Milestone !! Test Case !! Result<br />
|-<br />
| Beta<br />
| [[QA:Testcase_FreeIPA_web_ui]]<br />
| {{result|pass|coconut|bot=true}}<br />
|-<br />
| Beta<br />
| [[QA:Testcase_FreeIPA_password_change]]<br />
| {{result|pass|coconut|bot=true}}<br />
|-<br />
|}<br />
<references/><br />
<br />
===== Database server role =====<br />
{| class="wikitable sortable collapsible" width=100%<br />
|-<br />
! Milestone !! Test Case !! Result<br />
|-<br />
| Beta<br />
| [[QA:Testcase_database_server_remote_client]]<br />
| {{result|pass|coconut|bot=true}}<br />
<br />
|-<br />
|}<br />
<references/><br />
<br />
==== Non-release-blocking roles ====<br />
{{admon/note|Single test table|In all of these tests, the test case used is [[QA:Testcase Server role deploy]]. That is where the links point. The test may be run for each non-release-blocking role.}}<br />
{| class="wikitable sortable collapsible" width=100%<br />
|-<br />
! Milestone !! Test Case !! x86 !! ARM<br />
|-<br />
|}<br />
<references/></onlyinclude><br />
<br />
[[Category:Server_validation_testing]]<br />
{{#if:|[[Category:Fedora_26_Nightly_Test_Results|Server]]|[[Category:Fedora_26_Beta_Test_Results|Server]]}}</div>Ausilhttps://fedoraproject.org/w/index.php?title=Test_Results:Fedora_26_Beta_1.4_Server&diff=494149Test Results:Fedora 26 Beta 1.4 Server2017-06-02T04:02:40Z<p>Ausil: /* Release-blocking roles */ I did a test</p>
<hr />
<div>{{Release_validation_instructions|testtype=Server|release=26|milestone=Beta|compose=1.4|date=}}<br />
<br />
{{anchor|results}}<br />
== '''Test Matrix''' ==<br />
<br />
<onlyinclude><br />
==== General tests ====<br />
{| class="wikitable sortable collapsible" width=100%<br />
|-<br />
! Milestone !! Test Case !! x86 !! ARM<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_kickstart_firewall_disabled]]<br />
| {{result|pass|coconut|bot=true}}<br />
| {{result|pass|<previous RC1.3 run>}}<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_kickstart_firewall_configured]]<br />
| {{result|pass|coconut|bot=true}}<br />
| {{result|pass|<previous RC1.3 run>}}<br />
|-<br />
| Alpha<br />
| [[ QA:Testcase_Server_firewall_default]]<br />
| {{result|pass|coconut|bot=true}}<br />
| {{result|pass|pwhalen}}<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_Server_cockpit_default]]<br />
| {{result|pass|coconut|bot=true}}<br />
| {{result|pass|pwhalen}}<br />
|-<br />
| Beta<br />
| [[QA:Testcase_Server_cockpit_basic]]<br />
| {{result|pass|coconut|bot=true}}<br />
| {{result|pass|pwhalen}}<br />
|-<br />
|}<br />
<references/><br />
<br />
==== Domain joining tests: '''FreeIPA''' ====<br />
{| class="wikitable sortable collapsible" width=100%<br />
|-<br />
! Milestone !! Test Case !! Result<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_realmd_join_kickstart]]<br />
| {{result|pass|coconut|bot=true}}<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_realmd_join_sssd]]<br />
| {{result|pass|coconut|bot=true}}<br />
|-<br />
| Beta<br />
| [[QA:Testcase_realmd_join_cockpit]]<br />
| {{result|pass|coconut|bot=true}}<br />
|-<br />
|}<br />
<references/><br />
<br />
==== Domain joining tests: '''Active Directory''' ====<br />
{| class="wikitable sortable collapsible" width=100%<br />
|-<br />
! Milestone !! Test Case !! Result<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_realmd_join_kickstart]]<br />
| {{result|pass|sgallagh}}<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_realmd_join_sssd]]<br />
| {{result|pass|<previous RC1.3 run>}}<br />
|-<br />
| Beta<br />
| [[QA:Testcase_realmd_join_cockpit]]<br />
| {{result|pass|<previous RC1.3 run>}}<br />
|-<br />
|}<br />
<references/><br />
<br />
==== Domain client tests ====<br />
{| class="wikitable sortable collapsible" width=100%<br />
|-<br />
! Milestone !! Test Case !! Result<br />
|-<br />
| Beta<br />
| [[QA:Testcase_domain_client_authenticate]] (FreeIPA)<br />
| {{result|pass|coconut|bot=true}}<br />
|-<br />
| Final<br />
| [[QA:Testcase_FreeIPA_realmd_login]]<br />
| {{result|pass|coconut|bot=true}}<br />
|-<br />
| Optional<br />
| [[QA:Testcase_domain_client_authenticate]] (Active Directory)<br />
| {{result|pass|<previous RC1.3 run>}}<br />
|}<br />
<references/><br />
<br />
==== Release-blocking roles ====<br />
{{admon/note|Single test table|In all of these tests, the test case used is [[QA:Testcase Server role deploy]]. That is where the links point. The test must be run for each release-blocking role.}}<br />
{| class="wikitable sortable collapsible" width=100%<br />
|-<br />
! Milestone !! Test Case !! x86 !! ARM<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_Server_role_deploy|Domain controller]]<br />
| {{result|pass|coconut|bot=true}}<br />
| {{result|none}}<br />
|-<br />
| Alpha<br />
| [[QA:Testcase_Server_role_deploy|Database server]]<br />
| {{result|pass|coconut|bot=true}}<br />
| {{result|pass|ausil|bot=false}}<br />
|-<br />
|}<br />
<references/><br />
<br />
===== Domain controller role =====<br />
{| class="wikitable sortable collapsible" width=100%<br />
|-<br />
! Milestone !! Test Case !! Result<br />
|-<br />
| Beta<br />
| [[QA:Testcase_FreeIPA_web_ui]]<br />
| {{result|pass|coconut|bot=true}}<br />
|-<br />
| Beta<br />
| [[QA:Testcase_FreeIPA_password_change]]<br />
| {{result|pass|coconut|bot=true}}<br />
|-<br />
|}<br />
<references/><br />
<br />
===== Database server role =====<br />
{| class="wikitable sortable collapsible" width=100%<br />
|-<br />
! Milestone !! Test Case !! Result<br />
|-<br />
| Beta<br />
| [[QA:Testcase_database_server_remote_client]]<br />
| {{result|pass|coconut|bot=true}}<br />
<br />
|-<br />
|}<br />
<references/><br />
<br />
==== Non-release-blocking roles ====<br />
{{admon/note|Single test table|In all of these tests, the test case used is [[QA:Testcase Server role deploy]]. That is where the links point. The test may be run for each non-release-blocking role.}}<br />
{| class="wikitable sortable collapsible" width=100%<br />
|-<br />
! Milestone !! Test Case !! x86 !! ARM<br />
|-<br />
|}<br />
<references/></onlyinclude><br />
<br />
[[Category:Server_validation_testing]]<br />
{{#if:|[[Category:Fedora_26_Nightly_Test_Results|Server]]|[[Category:Fedora_26_Beta_Test_Results|Server]]}}</div>Ausilhttps://fedoraproject.org/w/index.php?title=Fedora_26_27_Mass_Rebuild&diff=492796Fedora 26 27 Mass Rebuild2017-05-16T03:11:56Z<p>Ausil: /* Maintainer Actions */ there is no opt out</p>
<hr />
<div>== Goal ==<br />
The goal is to rebuild some Fedora packages, for fedora 26 and 27 which are affected by a ABI bug in GCC<br />
<br />
== Schedule ==<br />
Given the changes required for the above features and the given<br />
schedules, Release Engineering will be ready to start scripted rebuilds<br />
on Monday, May 15th 2017. All automated rebuilds should be finished in couple of days.<br />
Any clean-up manual rebuilds should be finished before Beta change deadline and will need Bodhi updates.<br />
<br />
== Scripts ==<br />
Release Engineering has created two scripts. One is to initiate the builds, and the other is to query for items still needing to be built.<br />
<br />
=== Build Initiation ===<br />
The rebuild [https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-special.py script] works in the following way:<br />
<br />
use list of packages in f26 and f27 that are archeful <br />
Loop through list of packages provided in the script:<br />
Query if a build has already been attempted/completed since koji changes went live.<br />
If so, move to next package<br />
If not, check out git<br />
check master and f26 git hashes <br />
if master or git hashes dont match<br />
rpmdev-bumpspec<br />
else<br />
git merge master<br />
fedpkg commit -cp<br />
fedpkg (background) build<br />
Move on to next package<br />
<br />
Each step will have some error catching and logging so that people<br />
can clean up the various failures for whatever reasons. The builds will<br />
be background builds, which will allow other builds done to take higher<br />
priority when a builder has a free slot. However maintainers should<br />
take care when doing this so that the background build won't take<br />
'latest' precedent when it finishes. Asking rel-eng to kill the<br />
scripted build will typically be enough.<br />
<br />
=== Build Tagging ===<br />
Once the rebuild script has finished, another [https://pagure.io/releng/blob/master/f/scripts/mass-tag.py script] will run to tag the builds into f26. This script will check that a newer build hasn't been done or started in f26 since the scripted rebuild was submitted. This will protect against the scripted rebuild overriding an even newer build done while the scripted rebuild was waiting in the background.<br />
<br />
=== Status Query ===<br />
Release Engineering has developed a [https://pagure.io/releng/blob/master/f/scripts/need-rebuild.py script] to query f26<br />
and report on packages that have yet to be rebuilt. Results of these<br />
queries will be delivered to various places, yet to be determined,<br />
broken down by maintainer for easier discovery of work needed.<br />
<br />
== Maintainer Actions ==<br />
* Maintainers can help this effort by ensuring '''rpmdev-bumpspec''' correctly bumps your package's spec files.<br />
* Maintainers should ensure that their packages currently build from source.<br />
* Maintainers should ensure that there are no unwanted changes committed to git but not built yet.<br />
<br />
== Frequently Asked Questions ==<br />
=== When will my own build "count" for the rebuild? ===<br />
After the last piece needed for the mass rebuild a gcc build was put into place, a build done by a maintainer will "count" toward the rebuild. 2017-05-15 00:00:00 is the UTC time that builds count from<br />
<br />
=== Will the rebuilds be ordered? ===<br />
Currently there is no plan to logically order the rebuilds based on deps. The ordering will be alphanumerical based on package name. There are no planned ABI/soname changes that would require logical build ordering. Further, all the builds will be kept in a special tag (f26-gcc-abi-rebuild) until the whole run is done, and then they will be tagged into f26 in one shot to minimize the shuffle of buildroot contents during the rebuilds.<br />
<br />
<br />
== Feedback ==<br />
<br />
Questions/comments/concerns should be directed to [https://lists.fedoraproject.org/mailman/listinfo/devel], or #fedora-releng on freenode IRC.</div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/InvokingTests&diff=490690Changes/InvokingTests2017-04-12T03:48:15Z<p>Ausil: /* Voting */</p>
<hr />
<div>= Standard Discovery, Packaging, Invocation of Integration Tests =<br />
<br />
{{admon/warning|This Page is being reworked|This message will be removed when refactoring is complete}}<br />
<br />
== Summary ==<br />
<br />
Lets define a clear delineation of between a ''test suite'' (including framework) and the CI system that is running the test suite. This is the standard interface.<br />
<br />
[[File:Invoking-tests-standard-interface.png|800px]]<br />
<br />
What follows is a standard way to discover, package and invoke integration tests for a package stored in a Fedora dist-git repo.<br />
<br />
Many Fedora packages have unit tests. These tests are typically run during a <code>%check</code> RPM build step and run in a build root. On the other hand, integration testing should happen against a composed system. Upstream projects have integration tests, both Fedora QA and the Atomic Host team would like to create more integration tests, Red Hat would like to bring integration tests upstream. <br />
<br />
== Owner ==<br />
<br />
* Name: '''TODO:''' Fill in owner here. Maybe pingou, tflink, other? More than one owner is possible.<br />
* Email: '''TODO:''' Fill in email of owner here.<br />
<br />
== Terminology ==<br />
<br />
* '''Test Subject''': The items that are to be tested. <br />
** Examples: RPMs, OCI image, ISO, QCow2, Module repository ...<br />
* '''Test''': A callable/runnable piece of code and corresponding test data and mocks which exercises and evaluates a ''test subject''.<br />
* '''Test Suite''': The collection of all tests that apply to a ''test subject''. <br />
* '''Test Framework''': A library or component that the ''test suite'' and ''tests'' use to accomplish their job.<br />
** Examples: [https://avocado-framework.github.io/ Avocado], [https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests GNOME Installed Tests], [https://pagure.io/modularity-testing-framework/ Modularity Testing Framework], [https://github.com/projectatomic/atomic-host-tests Ansible tests in Atomic Host], [https://tunir.readthedocs.io/en/latest/ Tunir tests], docker test images, ...<br />
* '''Test Result''': A boolean pass/fail output of a ''test suite''. <br />
** ''Test results'' are for consumption by automated aspects of a ''testing systems''.<br />
* '''Test Artifact''': Any additional output of the test suite such as the stdout/stderr output, log files, screenshots, core dumps, or TAP/Junit/subunit streams. <br />
** ''Test artifacts'' are for consumption by humans, archival or big data analysis.<br />
* '''Testing System''': A CI or other ''testing system'' that would like to discover, stage and invoke tests for a ''test subject''.<br />
** Examples: [https://jenkins.io/ Jenkins], [https://taskotron.fedoraproject.org/ Taskotron], [https://docs.openstack.org/infra/zuul/ ZUUL], [https://ci.centos.org/ CentOS CI], Red Hat CI, [https://travis-ci.org/ Travis], [https://semaphoreci.com/ Semaphore], [https://developers.openshift.com/managing-your-applications/continuous-integration.html Openshift CI/CD], [https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure Ubuntu CI], ...<br />
<br />
== Responsibilities ==<br />
<br />
The '''testing system''' is responsible to:<br />
* Build or otherwise acquire the ''test subject'', such as package, container image, tree …<br />
* Decide which ''test suite'' to run, often by using the standard interface to discover appropriate ''tests'' for the dist-git repo that a test subject originated in.<br />
* Schedule, provision or orchestrate a job to run the ''test suite'' on appropriate compute, storage, ...<br />
* Stage the ''test suite'' as described by the ''standard interface''.<br />
* Invoke the ''test suite'' as described by the ''standard interface''.<br />
* Gather the ''test results'' and ''test artifacts'' as described by the ''standard interface''.<br />
* Announce and relay the ''test results'' and ''test artifacts'' for gating, archival ...<br />
<br />
The '''standard interface''' describes how to:<br />
* Discover a ''test suite'' for a given dist-git repo.<br />
* Uniquely identify a ''test suite''.<br />
* Stage a ''test suite'' and its dependencies such as ''test frameworks''.<br />
* Provide the ''test subject'' to the ''test suite''.<br />
* Invoke a ''test suite'' in a consistent way.<br />
* Gather ''test results'' and ''test artifacts'' from the invoked ''test suite''.<br />
<br />
The '''test suite''' is responsible to:<br />
* Declare its dependencies such as a ''test framework'' via the ''standard interface''.<br />
* Execute the ''test framework'' as necessary.<br />
* Provision (usually locally) any containers or virtual machines necessary for testing the ''test subject''.<br />
* Provide ''test results'' and ''test subjects'' back according to the standard <br />
<br />
The format of the textual logs and ''test artifacts'' that come out of a test suite is not prescribed by this document. Nor is it envisioned to be standardized across all possible ''test suites''.<br />
<br />
== Requirements ==<br />
<br />
* The ''test suite'' and ''test framework'' SHOULD NOT leak its implementation details into the testing system, other than via the ''standard interface''.<br />
* The ''test suite'' and ''test framework'' SHOULD NOT rely on behavior of the testing system other than the ''standard interface''.<br />
* The ''standard interface'' MUST enable a dist-git packager to run a ''test suite'' locally.<br />
** ''Test suites'' or ''test frameworks'' MAY call out to the network for certain tasks.<br />
* It MUST be possible to stage an upstream ''test suite'' using the ''standard interface''.<br />
* Both ''in-situ tests'', and more rigorous ''outside-in tests'' MUST be possible with the ''standard interface''.<br />
** For ''in-situ tests'' the ''test suite'' is in the same file system tree and process space as the ''test subject''.<br />
** For ''outside-in tests'' the ''test suite'' is outside of the file system tree and process space of the ''test subject''.<br />
* The ''test suite'' and ''test framework'' SHOULD be able to provision containers and virtual machines necessary for its testing without requesting them from the ''testing system''.<br />
* The ''standard interface'' SHOULD describe how to uniquely identify a ''test suite'', <br />
<br />
== Detailed Description ==<br />
<br />
This standard interface describes how to discover, stage and invoke tests. It is important to cleanly separate implementation details of the ''testing system'' from the ''test suite'' and its framework. It is also important to allow Fedora packagers to locally and manually invoke a ''test suite''.<br />
<br />
=== Staging ===<br />
<br />
<br />
Tests files will be added into the ''tests'' folder in the dist-git of the package that they are testing. The structure of the files and folders is left to the liberty of the packagers but there should be a ''run_tests.yml'' playbook at the top level of the tests folder to set up and run all the tests.<br />
<br />
=== Invocation ===<br />
<br />
The test can be invoke simply by calling ''sudo ansible-playbook run_tests.yml'' on the ''run_tests.yml'' playbook of interest.<br />
<br />
=== Discovery ===<br />
<br />
A testing system needs to be able to efficiently answer the question "does this subject have any tests packages, and if so, what are their names". This should be automatically discoverable to the extent possible.<br />
<br />
<br />
Use repoquery, basically I propose we rely on the dependency chain of the<br />
RPMs itself instead of trying to replicate it differently.<br />
<br />
repoquery --whatrequires or an equivalent relying on mdapi:<br />
https://apps.fedoraproject.org/mdapi/ (which I need to adjust to support<br />
back walking (ie find which packages requires "foo" instead of what packages<br />
"foo" requires which we currently have)<br />
and we should be able to build a list of dependencies.<br />
<br />
== Test Output Collection ==<br />
<br />
This will enable us to collect full consistent output regardless of the test output to report with ansible invocation<br />
<br />
https://github.com/openstack/ara<br />
<br />
<br />
In addition, a ''test suite'' can be uniquely identified using the git hash of the commit of the git repo.<br />
<br />
== Scope ==<br />
<br />
Since the tests are added in a sub-folder of the dist-git repo, there are no changes required to the Fedora infrastructure and will have no impact on the packagers' workflow and tooling.<br />
<br />
Only the testing system will need to be taught to install the requirements and run the playbooks.<br />
<br />
== Benefit to Fedora ==<br />
<br />
Developers benefit by having a consistent target for how to describe tests, while also being able to execute them locally while debugging issues or iterating on tests.<br />
<br />
By staging and invoking tests consistently in Fedora we create an eco-system for the tests that allows varied test frameworks as well as CI system infrastructure to interoperate. The integration tests outlast the implementation details of either the frameworks they're written in or the CI systems running them.<br />
<br />
'''TODO:''' note any additional benefits to Fedora.<br />
<br />
<br />
= Current Proposals =<br />
<br />
There are currently two proposals for how to implement this change and a final decision has not yet been made as to which is the final proposal. The two current proposals are:<br />
<br />
* [[Changes/InvokingTestsPackaged|Tests invoked via RPM packages]]<br />
* [[Changes/InvokingTestsAnsible|Tests invoked via Ansible]]<br />
<br />
== Evaluations ==<br />
<br />
''Instructions:'' In depth evaluations should be done in the sub-proposal pages in the existing evaluation sections. Indicate vote below in the [[Changes/InvokingTests#voting|voting section]]<br />
<br />
<br />
{{anchor|voting}}<br />
=== Voting ===<br />
<br />
{|<br />
! Contributor !! Packaged Tests !! Ansible Tests !! Notes<br />
|-<br />
| [[User:YourUserName|YourUserName]] || || +1 || This is just an example, please vote for one of the options<br />
|-<br />
| [[User:Roshi|Roshi]] || || +1 || <br />
|-<br />
| [[User:Ausil|Ausil]] || || +1 || Ansible is a bit more work but I think will give better results and options <br />
|-<br />
|}</div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/InvokingTestsAnsible&diff=490689Changes/InvokingTestsAnsible2017-04-12T03:46:36Z<p>Ausil: </p>
<hr />
<div>= Ansible: Standard Discovery, Staging, Invocation of Integration Tests =<br />
<br />
{{admon/warning|This is a proposal|Feedback is more than welcome.<br />
There's a ''discussion'' tab above.}}<br />
<br />
<br />
== User Experience ==<br />
<br />
A standard way to package, store and run tests benefits Fedora stability, and makes Fedora better for users.<br />
<br />
* This structure makes it easy to run locally thus potentially reproducing an error triggered on the test system.<br />
* Ansible is being more and more popular, thus making it easier for people to contribute new tests<br />
* Used by a lot of sys-admin, ansible could help sys-admin to bring test-cases to the packagers and developers about situation where something failed for them.<br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
There are no real upgrade or compatibility impact. The tests will be branched per release as spec files are branched dist-git is now.<br />
<br />
<br />
== Full Structure ==<br />
<br />
.<br />
└── tests<br />
└── test-case<br />
└── config<br />
└── playbooks<br />
└── group_vars<br />
└── roles<br />
│ └── configure<br />
│ │ └── defaults<br />
│ │ └── files<br />
│ │ └── handlers<br />
│ │ └── meta<br />
│ │ └── tasks<br />
│ │ └── templates<br />
│ │ └── vars<br />
│ └── run_tests<br />
│ │ └── defaults<br />
│ │ └── files<br />
│ │ └── handlers<br />
│ │ └── meta<br />
│ │ └── tasks<br />
│ │ └── templates<br />
│ │ └── vars<br />
└── configure.yml<br />
└── run_tests.yml<br />
<br />
<br />
Tests will live under tests directory in a dist-git repo. The playbooks directory will define the roles for configuration and execution of the tests.<br />
The run_tests.yml will call roles necessary and dependencies of other roles can be defined there or in the meta of another role. (Well documented on writing ansible playbooks)<br />
I put the config as a place holder for configuration files needed or for provisioning (thinking of linch-pin https://github.com/CentOS-PaaS-SIG/linch-pin)<br />
''Note :This does not mean all these role sub-directories are required this just shows a full example case''<br />
<br />
== Examples ==<br />
<br />
What follows are examples of writing and/or packaging existing tests to this standard.<br />
<br />
'''TODO:''' Put general example notes here.<br />
<br />
=== Example: Simple in-situ test ===<br />
<br />
A simple downstream integration test for gzip can be found at: https://pagure.io/ansible_based_tests/blob/master/f/tests/gzip<br />
<br />
This is how the folder structure looks like:<br />
<br />
.<br />
├── files<br />
│ └── test-simple<br />
└── run_tests.yml<br />
<br />
And the content of ''run_tests.yml'' is:<br />
<pre><br />
---<br />
- hosts: localhost<br />
remote_user: root<br />
tasks:<br />
- name: Install the requirements<br />
package: <br />
name: "{{item}}" <br />
state: latest<br />
with_items:<br />
- coreutils<br />
- /sbin/install-info<br />
- gzip<br />
<br />
- name: Create the folder where we will store the tests<br />
file: <br />
state: directory<br />
path: "{{ item }}"<br />
owner: root <br />
group: root<br />
with_items:<br />
- /usr/libexec/tests/gzip/<br />
<br />
- name: Install the test files<br />
copy: <br />
src: "{{ item.file }}"<br />
dest: "/usr/libexec/tests/gzip/{{ item.dest }}"<br />
mode: 0755<br />
with_items:<br />
- {file: test-simple, dest: test-simple }<br />
<br />
- name: Execute the tests<br />
shell: /usr/libexec/tests/gzip/test-simple<br />
</pre><br />
<br />
=== Example: GNOME style "Installed Tests" ===<br />
<br />
A downstream integration test running in gnome installed tests can be found at: https://pagure.io/ansible_based_tests/blob/master/f/tests/gzip<br />
full example structure: https://pagure.io/ansible_based_tests/blob/master/f/tests/gzip/playbooks<br />
<br />
=== Example: Tests run in Docker Container ===<br />
<br />
An integration test running tests in a docker container can be found at: https://pagure.io/ansible_based_tests/blob/master/f/tests/glib2<br />
full example structure: https://pagure.io/ansible_based_tests/blob/master/f/tests/glib2/playbooks<br />
<br />
=== Example: Modularity testing Framework ===<br />
<br />
TODO: Port [https://pagure.io/modularity-testing-framework/blob/master/f/examples an example]<br />
<br />
=== Example: Ansible with Atomic Host ===<br />
<br />
TODO: Port [https://github.com/projectatomic/atomic-host-tests an existing test]<br />
<br />
=== Example: Beakerlib based test ===<br />
<br />
TODO: Port and shim a beakerlib test<br />
<br />
== Evaluation ==<br />
<br />
''Instructions:'' Copy the block below, sign your name and fill in each section with your evaluation of that aspect. Add additional bullet points with overall summary or notes.<br />
<br />
'''Full Name''' -- SignAture<br />
* ''Summary:'' ... <br />
* ''Staging:'' ...<br />
* ''Invocation:'' ...<br />
* ''Discovery:'' ...<br />
<br />
'''Stef Walter''' -- Stefw<br />
* ''Summary:''<br />
** PRO: Ansible is readable and approachable<br />
** PRO: Tests are stored in same repo as tests<br />
** PRO: Inclusion of upstream tests seems to require packaging them as RPMs.<br />
** CON: Ansible is another technology (in addition to RPM spec files, etc.) that packager is required to learn in order to maintain a package in dist-git.<br />
** CON: If tests become a core Fedora concept (which we hope), Ansible becomes a core technology that Fedora requires and is built upon.<br />
** CON: Most Ansible modules require Python 2.x while the distro is trying to move to Python 3.x<br />
** CON: No standard mechanism for passing a test subject to a test suite implementing the standard test interface<br />
** CON: No standard mechanism for reporting test log, or test artifacts from standard interface<br />
** CON: No way to describe whether tests are compatible with or conflict with specific NVR of test subjects.<br />
* ''Staging:'' <br />
** No mechanism for passing a test subject (eg: a built package, a module, or a container) to the test suite to operate on.<br />
** No guidance on what Ansible modules should be used to install test dependencies<br />
** No mechanism for a test system to control which repo of known-good packages to pull test or test suite dependencies from.<br />
** Requires sudo, dnf, git, ansible, python2-dnf, libselinux-python as well known staging dependencies<br />
* ''Invocation:'' <br />
** Seems that zero exit code from sudo means success, non-zero exit code means failure? Not described explicitly in standard.<br />
** The use of sudo seems to imply invocation should happen as a non-root user. Is this correct?<br />
** Does the standard assume sudo is guaranteed to work? Should the sudo part just be dropped and require invocation as root?<br />
** No mechanism for reporting logs, or test artifacts has been described.<br />
* ''Discovery:'' <br />
** Mechanism is simple, but no concrete description of how exactly this works. How does a testing system find tests given a test subject such as an RPM or NVR?<br />
** MDAPI link is broken: https://apps.fedoraproject.org/mdapi/<br />
<br />
'''Martin Pitt''' -- mpitt<br />
* ''Summary:''<br />
** I agree to what Stef said above, so I just add my "delta" review.<br />
** PRO: I prefer keeping tests in the sources (like in this proposal) over packaging tests, as it's much less overhead for the packager and avoids having to create a new kind of package archive.<br />
** CON: My main concern is that the Ansible format/tool might be replaced with something else in a few years, but the test format should be stable for a long time to avoid having to port hundreds/thousands of tests.<br />
** CON: The ansible format is relatively verbose and too procedural for my taste; I prefer a purely declarative syntax and avoiding boilerplate for installing test deps and invoking the tests.<br />
* ''Staging:''<br />
** Not supporting test subjects is a major gap in the prototype - this is one of the core requirements here!<br />
** Installing the actual tests is unnecessary overhead in the playbook, and clutters the host system with files in <code>/usr</code> that don't belong to a package; this can be rectified though with dropping the "Create folder"/"Install" tasks and replacing the run part with<br />
<pre><br />
- name: Execute the tests<br />
script: files/test-simple</pre><br />
* ''Invocation:''<br />
** Getting live logs from the test and also saving it as an artifact is crucial, this is a major gap in the prototype. Can ansible do this somehow?<br />
* ''Discovery:''<br />
** Checking out and inspecting hundreds/thousands of dist-gits whether they contain tests does not meet "able to efficiently answer the question..."; this needs a new service which regularly indexes all dist-gits and creates list of source packages that have tests.<br />
<br />
<br />
'''Pierre-Yves Chibon''' -- pingou<br />
* Disclaimer: I am one of the owners above.<br />
* ''Summary:''<br />
** PRO: Ansible is a well-know technology for sys-admin making it easier for them to contribute tests<br />
** CON: While being well-know for some people, it will be new for others<br />
** PRO: Very flexible it gives the packagers all the flexibility to install/configure/run their tests as they wish<br />
** PRO: We could use --tag to allow running just a part of the test suite at certain time (''-t PR'' to run on pull-request ''-t updates'' to run on bodhi updates...)<br />
** CON: We may need to "regulate" the flexibility to suggest a set of standard/gold practices to be used in the test system (using different tags or playbook if we want)<br />
* ''Staging'':<br />
** PRO: its flexibility makes it easy to test anything<br />
** CON: we will need to write policies/guidelines on how to test the different subject (RPM, container, images...)<br />
* ''Invocation:''<br />
** PRO: easy to run locally<br />
** PRO: easy to run as root and switch to a local user or vice-versa<br />
** PRO: easy to couple with something like vagrant to allow running locally destructive tests<br />
** CON: May require policy to set expectations and document how to move from one to the other<br />
** CON: Inter-package dependencies is a challenge that can be overcome with a custom ansible module allowing to git clone other dist-git repo and while allowing us to block other network accesses (to avoid downloading random things from the internet that may be gone tomorrow and thus kill the reproducibility aspect).<br />
* ''Discovery:''<br />
** Git hash uniquely identifies a test suite<br />
*** Meaning the identifier may change while the test suite itself hasn't<br />
** PRO: Relies on the same dependency chain as the artefacts themselves<br />
** QUESTION: What is the aim here? Do we really want to run all the tests of every perl module for every change made to the perl package? If so, good luck, otherwise ''repoquery --whatrequires <pkg>'' should do what we want.<br />
<br />
<br />
'''Tim Flink''' -- Tflink<br />
* Disclaimer: I am one of the owners of this proposal<br />
* ''Summary:''<br />
** PRO: Storing tests in this way decouples them from the build process<br />
** PRO: Ansible has better docs and more examples than Fedora packages or RPM do<br />
** PRO: non-packager testers don't have to learn RPM syntax<br />
** PRO: Able to provide a lot more in the way of convenience functions to the test author - galaxy, roles/modules that we provide<br />
** PRO: easy to change tests during devel, does not require a dedicated path in the filesystem<br />
** PRO/CON: More easily extendable<br />
** CON: Adds ansible et. al as a dependency for the test process - what happens if ansible changes or if it becomes unattractive 5-10 years from now?<br />
** CON: Adds additional thing that packagers have to learn<br />
** CON: We would have no control over when/how ansible changes<br />
** It's not incredibly clear what all would be distributed (ansible modules, plugins) or how those would be distributed (galaxy-ish, package, etc.)<br />
* ''Staging:''<br />
** There is no obvious way to say what NVR is under test other than looking at what's installed or what's locally available pre-build<br />
* ''Invocation:''<br />
** Not sure sudo is required, it would likely be easier to have a plugin (if required) that ran things in a temp dir kind of how we do with libtaskotron today<br />
* ''Discovery:''<br />
** While arguably more complex than the <code>-tests</code> package proposal, the additional complexity in terms of code to be written doesn't seem to be much more complex<br />
** There are systems already doing some parts of this discovery and could likely be re-used to a certain extent (Taskotron's trigger)<br />
<br />
'''Dennis Gilmore''' -- Ausil<br />
* ''Summary:''<br />
** PRO: we could have unique git repos for collections, gnome-desktop, KDE, Atomic Host, Server, etc<br />
** PRO: Docs are good as is support ofr the format across platforms<br />
** PRO: Branching could be separate from package branching, simplifying workflows<br />
** PRO: should be simple to write validation testing of tests, making sure that people are in compliance.<br />
** CON: Not clear how we should store tests for same package with different git namespaces. for example Cockpit rpm and cockpit container<br />
** CON: getting started with Ansible for those who do not now it is a steep learning curve<br />
** CON: can not reuse tools like rpmlint, rpmdiff etc<br />
** PRO: seems like we should be able to easily setup a template for a tests repo<br />
** PRO: We should be able to easily put a web interface for adding and editing tests for people not familiar with git<br />
* ''Staging:''<br />
** Using VM's and containers seems to have a much clearer path than the <code>-tests</code> package proposal<br />
* ''Invocation:''<br />
** use of sudo seems very suboptimal.<br />
* ''Discovery:''<br />
** indexing, searching and mapping of tests seems uncovered. Likely we will need to write some tooling to make it useful and easy to find and get for people.</div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/InvokingTestsPackaged&diff=490688Changes/InvokingTestsPackaged2017-04-12T03:23:46Z<p>Ausil: Dennis's thoughts</p>
<hr />
<div>= Standard Discovery, Packaging, Invocation of Integration Tests via RPM packages =<br />
<br />
{{admon/warning|This is a proposal|Feedback is more than welcome.<br />
There's a ''discussion'' tab above.}}<br />
<br />
== Detailed Description ==<br />
<br />
This standard interface describes how to discover, stage and invoke tests. It is important to cleanly separate implementation details of the ''testing system'' from the ''test suite'' and its framework. It is also important to allow packagers to locally and manually invoke a ''test suite''.<br />
<br />
=== Packaging ===<br />
<br />
The integration tests are packaged and delivered through Fedora as packages.<br />
<br />
Each dist-git repo that has integration tests should package those tests in one or more subpackages<br />
like <code>%{name}-tests</code>. This is similar to the<br />
<code>%{name}-debuginfo</code> or <code>%{name}-docs</code> subpackages we have<br />
today.<br />
<br />
The spec file for a dist-git repo may install upstream integration tests as files in<br />
its <code>%{name}-tests</code> package. The spec file may also include tests<br />
directly from files in <code>tests/</code> subdirectory of the dist-git repo itself.<br />
<br />
The tests package should use <code>Requires:</code> to require any other package, testing framework, or dependency necessary to run the tests. In ''in-situ'' testing cases, the tests package will directly <code>Requires:</code> the package of the ''test subject''.<br />
<br />
=== Invocation ===<br />
<br />
To invoke the test suite, the test package that contains it is installed. Each test of the suite<br />
installs an executable in the path <code>/usr/tests/</code>''sourcepackage''<code>/</code> (this will avoid name collisions between packages).<br />
<br />
To invoke the test suite, one would:<br />
<br />
# Create a temporary directory, referred to as: <code>$TESTDIR</code><br />
# Place the ''test subject(s)'' being tested in <code>$TESTDIR/subjects/</code><br />
# Execute all executable files in <code>/usr/tests/*/</code> directories one at a time.<br />
## Each executable test is invoked with a working directory of <code>$TESTDIR</code><br />
## Each executable test is invoked as root, and may drop privileges as desired.<br />
## Treat the stdout/stderr of the test process as the test log. This is a standard ''test artifact'' and written to <code>$TESTDIR/artifacts/testname.log</code>.<br />
## Examine the exit code of each test process. Zero exit code is a successful ''test result'', non-zero is failure.<br />
# Tests can put any additional ''test artifacts'' like screenshots into <code>$TESTDIR/artifacts/</code>.<br />
<br />
This ensures that tests can be run on a production system without accidentally clobbering permanent directories,<br />
don't require root privileges (simplifies test development), and that CI systems have one unique place from where<br />
to collect artifacts. It also avoids collecting temporary files such as downloaded container or VM images as artifacts,<br />
as these would usually get stored for a longer time period.<br />
<br />
These steps would usually be done through a standard test driver tool (particularly for sensible stdout/stderr teeing and log capturing), but its usage is not mandatory for developing and calling tests manually.<br />
<br />
=== Staging ===<br />
<br />
The <code>%{name}-test</code> package should <code>Requires:</code> all other packages<br />
that the testsuite executable needs in order to run. This includes libraries or frameworks,<br />
or subsystems like <code>libvirt</code>.<br />
<br />
Some integration tests may choose to test ''in-situ'', on the system on which the test suite<br />
is installed. In these cases the <code>%{name}-tests</code> package should directly<br />
depend on the package being tested.<br />
<br />
More rigorous integration tests are ''outside-in''. They test an integrated system without affecting its contents. It is the responsibility of the <code>%{name}-tests</code> packages to provision virtual machines or containers necessary to do such testing. In almost all cases this will happen by way of a provisioning framework such as [http://avocado-framework.readthedocs.org/ Avocado], [https://www.ansible.com/ Ansible], [https://pagure.io/modularity-testing-framework/ Module Testing Framework], [https://linch-pin.readthedocs.io/en/latest/ linch-pin], etc.<br />
<br />
Multiple tests packages may be installed as long as their dependencies do not conflict.<br />
<br />
=== Discovery ===<br />
<br />
A testing system needs to be able to efficiently answer the question "does this subject have any tests packages, and if so, what are their names". This should be automatically discoverable to the extent possible.<br />
<br />
For any RPM ''test subject'' this process requires no additional metadata and can be fully automatic:<br />
<br />
* It is possible to map a RPM to its SRPM source package (<code>&lt;rpm:sourcerpm&gt;</code> in the package index <code>*-primary.xml.gz</code>).<br />
* One can map an SRPM to all the RPMs that it builds (from the same index), and using the <code>*-filelists.xml.gz</code> index one can mechanically tell which of the RPMs are of this test package kind described here.<br />
<br />
'''TODO''': For other types of test subject cases such as docker images or distribution ISO files this discovery still needs to be discussed.<br />
* E. g. a <code>Dockerfile</code> might grow a reference to a test package RPM, or at least initially there is a manually maintained map of subject to test package in the testing system.<br />
<br />
== Scope ==<br />
<br />
This change requires no initial changes to Fedora infrastructure itself. The change only affects contents spec files in dist-git repos. <br />
<br />
'''TODO:''' However certain key infrastructure changes could mitigate usability or side-effects of this change. In particular, once this grows beyond the experimental phase, these test packages need to be put into a separate archive, similar to <code>-debuginfo</code>.<br />
<br />
* How much effort is that to set up?<br />
* Does this require any additional tags, keywords, or other explicit declaration in the spec file, other than "this RPM ships something in <code>/usr/tests/*</code>"?<br />
<br />
== Benefit to Fedora ==<br />
<br />
Developers benefit by having a consistent target for how to describe tests, while also being able to execute them locally while debugging issues or iterating on tests.<br />
<br />
By packaging, staging and invoking tests consistently in Fedora we create an eco-system for the tests that allows varied test frameworks as well as CI system infrastructure to interoperate. The integration tests outlast the implementation details of either the frameworks they're written in or the CI systems running them.<br />
<br />
== User Experience ==<br />
<br />
A standard way to package tests benefits Fedora stability, and makes Fedora better for users.<br />
<br />
Users could also benefit by having tests that they can reproduce on their own systems. They could install the similar to how they consume <code>%{name}-doc</code> or <code>%{name}-debuginfo</code> subpackages today.<br />
<br />
We may choose to avoid having such packages available in the standard repositories. We may choose to only have them in <code>updates-testing</code> or an arrangement similar to <code>debuginfo</code>. These choices will require some<br />
markup and/or change to infrastructure.<br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
Although there may already be packages that are named <code>%{name}-tests</code> this is merely a convention, and such packages will not affect the behavior of this proposal.<br />
<br />
== Comparison with Debian's autopkgtest ==<br />
<br />
Debian/Ubuntu have used CI with packaged tests (called "autopkgtests") for many years, with<br />
[https://ci.debian.net/status/ over 7.000 tests]. These are good candidates or at least bases for taking into Fedora<br />
packages. This compares the structure of autopkgtest with this proposal to learn from autopkgtest's experiences and take<br />
what works, and justifies the differences. See the<br />
[https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html format definition] for details.<br />
<br />
=== Packaging ===<br />
<br />
'''Similarities:''' Both specifications use an existing test metatada format (RPM spec files with <code>Requires:</code> here, Debian RFC822 control files with <code>Depends:</code>in autopkgtest).<br />
<br />
'''Differences:'''<br />
* This specification requires packaging tests as binary RPM packages, whereas autopkgtest opted for keeping the test in the source package (equivalent of dist-git) only. The latter avoids the overhead of packaging the tests and having to create a separate archive for them. An important point is also that installing an RPM `-test` package requires root privileges, while invoking autopkgtest doesn't.<br />
* As autopkgtest uses a separate control file (<code>debian/tests/control</code> instead of <code>debian/control</code> which describes the binary packages), it offers a much richer set of test metadata which cannot be expressed with <code>debian/control</code> or RPM spec files.<br />
<br />
=== Invocation ===<br />
<br />
'''Simimlarities''': The test interface is very similar: In both specifications, a test is an executable<br />
(of any script or compiled language), the exit code is the primary indicator of pass/fail, the executable's stdout/err<br />
is a standard test artifact ("test log"), and tests can write additional artifacts into the<br />
<code>$AUTOPKGTEST_ARTIFACTS</code> dir (like <code>./artifacts/</code> here).<br />
<br />
'''Differences:'''<br />
* By default, autopkgtest considers a test as failed if it produces anything on stderr, for catching unexpected new warnings. This can be disabled with adding <code>Restrictions: allow-stderr</code> to the test metadata. However, this turned out to be not overly useful, and tests which want to intercept warnings should better do that themselves.<br />
* autopkgtest has no concept of passing test subjects to the test. Tests expect that their subjects are already available/installed, i. e. they get called in a testbed of the desired kind and state. It is the responsibility of the autopkgtest command line tool (the "test driver/executor") to install proposed new package(s) into the testbed (due to its origin of being primarily focussed on testing packages). For testing desktop/cloud images, upgrades, or other non-package subjects, it is instead the testing system's responsibility to produce the desired testbed and call <code>autopkgtest</code> on it. As the scope of this specification puts the staging into the hand of the test instead of the testing system, passing the test subject is a necessary consequence.<br />
<br />
=== Staging ===<br />
<br />
'''Similarities:''' Both specifications use standard dpkg/rpm package dependencies (<code>Depends:</code> for dpkg, <code>Requires:</code> for rpm) to pull in test dependencies, and both can opt into doing their own provisioning of containers/VMs etc. for doing outside-in tests instead of in-situ. However, of all the ~ 7.000 autopkgtests, only a small handful is actually doing that (known cases are systemd and open-iscsi), as the vast majority of package/upgrade/image tests can (because it's sufficient) and should (because it's magnitudes faster) be run in-situ.<br />
<br />
'''Differences:''' Here the test itself is responsible for installing the test subjects, while in autopkgtest it's the testing system's responsibility (see above).<br />
<br />
=== Discovery ===<br />
<br />
'''Similarities:''' The idea is the same in both specifications. Here, as soon as there is a binary package that ships <code>/usr/tests/*</code> it can be discovered through file lists. In autopkgtest, as soon as there is a <code>debian/tests/control</code>, the source package index entry will automatically get a <code>Testsuite: autopkgtest</code> tag. So in both cases the developer does not need to explicitly do anything other than adding the tests.<br />
<br />
'''Differences:''' None concerning the interface, just technical implementation details due to how rpm/dpkg work.<br />
<br />
== Examples ==<br />
<br />
What follows are examples of writing and/or packaging existing tests to this standard.<br />
<br />
There is a mock ''test system''' which is a simple shell script: [http://piware.de/tmp/run-installed-test run-installed-test]. It runs all <code>/usr/tests/*</code>, can pass arbitrary subjects to them, and report/capture the results/logs. This is purely to study what a CI system would do and whether the standard interface works.<br />
<br />
=== Example: Simple in-situ test ===<br />
<br />
Add simple downstream integration test for gzip:<br />
<br />
* Package: '''gzip-tests'''<br />
* dist-git: https://github.com/martinpitt/fedora-gzip-test<br />
* Reference: https://patches.ubuntu.com/g/gzip/ (taken verbatim from Ubuntu's autopkgtest)<br />
<br />
With this you can install test RPM from above gzip repo:<br />
<br />
$ sudo rpm -i results_gzip/1.8/2.fc27/gzip-tests-1.8-2.fc25.x86_64.rpm<br />
<br />
and run the gzip tests on the already installed package (as user) with<br />
<br />
$ ~/run-installed-test<br />
Subjects/artifacts directory: /tmp/test.vsR<br />
-----------------------------------------<br />
Running /usr/tests/gzip/test-simple<br />
-----------------------------------------<br />
++ ls 'subjects/*.rpm'<br />
+ echo Bla<br />
+ cp bla.file bla.file.orig<br />
+ gzip bla.file<br />
+ gunzip bla.file.gz<br />
+ cmp bla.file bla.file.orig<br />
+ rm bla.file bla.file.orig<br />
PASS: /usr/tests/gzip/test-simple<br />
<br />
$ ls -l /tmp/test.vsR/artifacts/<br />
-rw-r--r-- 1 martin martin 156 Mar 28 16:49 test-simple.log<br />
<br />
or run them as root (as officially specified) with a subject (locally built gzip RPM):<br />
<br />
$ sudo ~/run-installed-test results_gzip/1.8/2.fc27/gzip-1.8-2.fc25.x86_64.rpm<br />
Installing subject results_gzip/1.8/2.fc27/gzip-1.8-2.fc25.x86_64.rpm<br />
Subjects/artifacts directory: /tmp/test.Cck<br />
-----------------------------------------<br />
Running /usr/tests/gzip/test-simple<br />
-----------------------------------------<br />
++ ls subjects/gzip-1.8-2.fc25.x86_64.rpm<br />
+ '[' -w / ']'<br />
+ rpm --verbose --force -U subjects/gzip-1.8-2.fc25.x86_64.rpm<br />
Preparing packages...<br />
gzip-1.8-2.fc25.x86_64<br />
+ echo Bla<br />
+ cp bla.file bla.file.orig<br />
+ gzip bla.file<br />
+ gunzip bla.file.gz<br />
+ cmp bla.file bla.file.orig<br />
+ rm bla.file bla.file.orig<br />
PASS: /usr/tests/gzip/test-simple<br />
<br />
=== Example: GNOME style "Installed Tests" ===<br />
<br />
Add downstream integration test running in gnome installed tests.<br />
<br />
* Package: '''glib2-tests'''<br />
* dist-git: https://github.com/martinpitt/fedora-glib2-test<br />
* Reference: https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests<br />
<br />
=== Example: Tests run in Docker Container ===<br />
<br />
Add integration test running glib2 installed tests in a docker container. This is also an example of having two different tests packages being created by the same dist-git repo.<br />
<br />
* Package: '''glib2-container-tests'''<br />
* dist-git: https://github.com/martinpitt/fedora-glib2-test<br />
* Based on Debian/Ubuntu's autopkgtest glib2 related script<br />
<br />
=== Example: Modularity testing Framework ===<br />
<br />
TODO: Port [https://pagure.io/modularity-testing-framework/blob/master/f/examples an example]<br />
<br />
=== Example: Ansible with Atomic Host ===<br />
<br />
TODO: Port [https://github.com/projectatomic/atomic-host-tests an existing test]<br />
<br />
=== Example: Beakerlib based test ===<br />
<br />
TODO: Port and shim a beakerlib test<br />
<br />
=== Example: Cockpit upstream test ===<br />
<br />
Run upstream integration test, which uses VMs through libvirt, in a docker<br />
container; the entire libvirt/bridge setup is confined to the container, so<br />
this can be run without interfering with the host system.<br />
<br />
* Package: '''cockpit-tests'''<br />
* dist-git: https://github.com/martinpitt/cockpit/commits/packaged-tests - The penultimate commit creates a new <code>cockpit-integration-tests</code> package containing the actual tests and libvirt/qemu etc. dependencies, the topmost commit provides the <code>/usr/tests/</code> script that runs the former in docker.<br />
* Reference: https://github.com/cockpit-project/cockpit/blob/master/test/README<br />
<br />
== Evaluation ==<br />
<br />
''Instructions:'' Copy the block below, sign your name and fill in each section with your evaluation of that aspect. Add additional bullet points with overall summary or notes.<br />
<br />
'''Full Name''' -- SignAture<br />
* ''Summary:'' ... <br />
* ''Staging:'' ...<br />
* ''Invocation:'' ...<br />
* ''Discovery:'' ...<br />
<br />
'''Stef Walter''' -- Stefw<br />
* ''Summary:''<br />
** Disclaimer: I am one of the owners above.<br />
** PRO: RPM is used for staging. RPM and YUM-style reposotiries are a standard part of Fedora. No other technology is involved in the standard.<br />
** PRO: Simple Unix invocation mechanism: executable + stdin/stdout + environment variables.<br />
** CON: RPM has a learning curve. Although a dist-git maintainer is required to already know about this.<br />
** CON: /usr/tests is a new FHS directory, should probably be /usr/libexec/tests.<br />
** CON: Only a partial way to describe whether tests are compatible with or conflict with a specific NVR of test subjects.<br />
** CON: The *-tests packages may require special handling if the distro does not want to have users able to install/run tests.<br />
* ''Staging:''<br />
** Requires rpm and yum/dnf as well known staging dependencies.<br />
** The *-tests suffix is implied by the standard, not required. Is this confusing?<br />
* ''Invocation:''<br />
** The standard describes how multiple test suites can be staged together and executed in one shot.<br />
* ''Discovery:''<br />
** An NVR is the unique identifier for a test suite.<br />
** This uses capabilities of how YUM repositories work, but requires no additional technology.<br />
<br />
<br />
'''Pierre-Yves Chibon''' -- pingou<br />
* ''Summary:''<br />
** PRO: RPM is used and well-know by all packagers.<br />
** CON: It would require buy-in by the Fedora Packaging Committee and documentation in the Fedora Package Guidelines<br />
** CON: Complexifies the spec file, some of which are already quite complex/un-readable<br />
** CON: What about auto-generated spec file? (Think TexLive)<br />
** CON: Require local tooling to run the tests (or rpm -ql <foo>-test first to find the executables)<br />
** CON: /usr/tests needs to be changed<br />
** CON: How are test subject supported?<br />
** CON: Will take up space on the mirror<br />
** CON: Packagers and QA/testers are working on the same file all the time, high chances PR will conflict, higher changes to disagreement among contributors<br />
* ''Staging:''<br />
** PRO: Requires rpm and yum/dnf as well known staging dependencies.<br />
** CON: How is test subject supported?<br />
* ''Invocation:''<br />
** CON: The standard describes how multiple test suites can be staged together and executed but not in one shot, first install then run. -> May need a wrapper tool to do both in one go.<br />
* ''Discovery:''<br />
** PRO: An NVR is the unique identifier for a test suite.<br />
*** Also meaning that the test suite may change NVR while its content has not changed or we would need to define a EVR just for the -test sub-package<br />
** PRO: This uses capabilities of how RPM repositories work, but requires no additional technology.<br />
** CON: This implies tracking the dependencies at two distinct places, the main package then the -test sub-package<br />
<br />
<br />
<br />
'''Tim Flink''' -- Tflink<br />
* ''Summary:''<br />
** PRO: No significantly new technology, no huge requirements for additional software development<br />
** PRO: Paradigm works really well for package-specific tests<br />
** CON: All involved folks need to learn RPM packaging<br />
** CON: RPM packaging overhead once folks learn RPM packaging<br />
** CON: Not sure how well the paradigm works for non-package testing (containers, images, etc.)<br />
* ''Staging:''<br />
** Nothing to add here, same concerns about convention over having a standard.<br />
** Not clear on how the test subject is found or passed into the framework? How are tests modified during development? How does one find the correct NVR for the test rpm at staging time?<br />
* ''Invocation:''<br />
** What kinds of features would we eventually want to see in the <code>run-installed test</code> script?<br />
** How do we differentiate between in-situ and outside-in tests? Is this needed?<br />
* ''Discovery:''<br />
** Are there existing tools to do the RPM to SRPM mapping?<br />
<br />
'''Dennis Gilmore''' -- Ausil<br />
* ''Summary:''<br />
** PRO: works well for singular tests<br />
** PRO: tests in package branching is easy to map tests to package nvr's<br />
** CON: difficult to map tests to package groups<br />
** CON: high cost of entry to people not familiar with packaging.<br />
** CON: easy for people to do non standard things, resulting in it being hard to test test changes for validity.<br />
** CON: proper rpm/yum/dnf support may be difficult to implement<br />
* ''Staging:''<br />
** the opt in use of containers/VMs for staging seems to be open wildly to interpretation and prone to people doing incompatible things<br />
* ''Invocation:''<br />
** Nothing extra to add here thats not already covered<br />
* ''Discovery:'' <br />
** Seems like a sane way to do it, would need to have changes to all of the compose tools in order to make test repos like debug for debuginfo, unknown how invasive it would be to do in rpm.</div>Ausilhttps://fedoraproject.org/w/index.php?title=How_to_remove_a_package_at_end_of_life&diff=487844How to remove a package at end of life2017-03-14T18:22:02Z<p>Ausil: /* Spins */</p>
<hr />
<div>{{autolang|base=yes}}<br />
<br />
When a package reaches the end of its useful life, the following procedure will let other people -- and automated processes! -- know both not to expect any more releases, and why it was removed. The process is called retirement.<br />
<br />
== Procedure ==<br />
{{admon/warning|Retire only in development/EPEL branches!|Do not retire packages in other branches than Branched (until the [[Schedule|Final Freeze]]), Rawhide (master) and EPEL branches (el5, el6, epel7).<br />
When you need to add package from EPEL to any RHEL release, only retire EPEL branch when package is released in that RHEL release.}}<br />
Please execute the following steps in the order indicated.<br />
<br />
=== RPM ===<br />
If the package is being replaced by some other package, ensure that the Obsoletes/Provides tags are properly set by the new package, see [[Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages|Renaming/Replacing Guidelines]].<br />
<br />
=== GIT ===<br />
Run <code>fedpkg retire DESCRIPTION</code> in all non-stable Fedora branches and EPEL<br />
branches, if applicable. The retiring needs to start with the oldest branch<br />
(e.g. retire on f25 before you retire on master)<br />
<br />
<br />
==== Remarks ====<br />
* The <code>DESCRIPTION</code> parameter should explain why the package was retired, good messages are:<br />
** <code>Obsoleted by bar</code><br />
** <code>Renamed to bar</code><br />
* The command will remove all files from the branch, add a file name <code>dead.package</code> containing the description and push the changes. Starting with fedpkg 1.13 it will also retire the package in package DB.<br />
* <code>git rm</code> all files in the other branches '''only if''' there are special factors at work, like licensing issues, or package being removed completely from Fedora.<br />
* If you retired master before other older branches you want to retire, just continue with the older branches. It will still work, but will block the package in more Koji tags, because tag inheritance will not be used automatically then.<br />
<br />
=== Package DB ===<br />
Ensure that the package is marked as retired in [https://admin.fedoraproject.org/pkgdb the package database system]. This should happen automatically with fedpkg 1.13 and newer if you provide your FAS credentials. If it failed, you can retire the package with the following command:<br />
pkgdb-cli orphan --retire PACKAGENAME master<br />
<br />
==== Remarks ====<br />
* After the package was retired in package DB, you will not be able to commit changes to GIT. Therefore clean up GIT first.<br />
* Change <code>master</code> to the respective branch<br />
* Start with the oldest branch<br />
<br />
=== Comps ===<br />
Remove the package from [[How_to_use_and_edit_comps.xml_for_package_groups| comps]] if it is listed.<br />
<br />
=== Spins ===<br />
Remove the package from any [https://pagure.io/fedora-kickstarts spin kickstart file]<br />
fork fedora-kickstarts and check out your clone. commit any fixes and send in a Pull Request<br />
git clone ssh://git@pagure.io/path/to/fork/fedora-kickstarts.git<br />
<br />
=== Upstream Release Monitoring ===<br />
Remove the package from [[Upstream_release_monitoring]] if it is listed.<br />
<br />
=== Koji ===<br />
To keep retired packages from being pushed to the mirrors, they need to be blocked in koji. This will happen during the next Rawhide/Branched compose (also for EPEL). If it did not happen file a<br />
[https://fedorahosted.org/rel-eng/newticket ticket] for rel-eng (component <code>koji</code>) and mention the package name and the branch the package needs to be blocked.<br />
<br />
==== Remarks ====<br />
* Please wait long enough before opening a ticket to avoid unnecessary work.<br />
* Use one ticket for all packages you retired at once, do not open one ticket for each package if you retired several packages.<br />
* You check whether a package is blocked in koji, e.g. for the package <code>curry</code> there should the a entry with <code>[BLOCKED]</code> for each branch the package was retired in. It is enough for a package to be retired in an older tag to be also blocked in a newer tag due to inheritance: <br />
<br />
<pre><br />
$ koji list-pkgs --show-blocked --tag f21 --package curry <br />
Package Tag Extra Arches Owner <br />
----------------------- ----------------------- ---------------- ---------------<br />
curry f20 gemi [BLOCKED]<br />
</pre><br />
<br />
== EPEL ==<br />
Note that you can use this process for EPEL as well with one difference:<br />
<br />
* You can remove the package from any EPEL branch whether or not it has been released.<br />
<br />
For example, if your package has been added to base RHEL in RHEL-6.4 then perform the steps above but use the <code>el6</code> branch instead of <code>master</code>.<br />
<br />
== Unretire a Package ==<br />
See [[Orphaned_package_that_need_new_maintainers]]<br />
<br />
[[Category:Package Maintainers]]</div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/NoMoreAlpha&diff=487730Changes/NoMoreAlpha2017-03-09T20:02:50Z<p>Ausil: /* Contingency Plan */</p>
<hr />
<div><!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= No More Alphas <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Fedora will no longer produce Alpha releases.<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:Ausil| Dennis Gilmore]], [[User:Adamwill| Adam Williamson]]<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: dennis@ausil.us, awilliam@redhat.com<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/27 | Fedora 27 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
By gating Rawhide builds from landing in the compose and gating the publication of composes on automated test results we will ensure Rawhide will always be at Alpha quality. This will make it more generally useful to people as a daily driver and development platform, and mean we no longer need to go through the process of building, testing and shipping Alpha releases. The initial testing will be ensuring that a package is installable and that it does not break existing packages installation. Over time we can enable extra testing to gate the build going into rawhide. Builds will land in the buildroot immediatly after the build has completed, in order to be built against before they make it to the compose. We will run the gating testing only to gate builds to the compose and not in order to make the buildroot.<br />
<br />
== Benefit to Fedora ==<br />
<br />
A Rawhide that is always at least Alpha quality is a more compelling product and may attract more target users (developers) to Fedora. Removing the process overhead of Alpha releases from the cycle frees up release engineering, quality engineering, development and project management resources for other work, and potentially offers more flexibility for the Change development and branching parts of the release cycle. Preventing broken changes from reaching the official Rawhide repository at all means we are not stuck with fundamentally problematic changes (bar doing epoch bumps and rebuilds of dependent packages) but can more easily revert them.<br />
<br />
== Scope ==<br />
* Proposal owners: rearrange the koji tag and target structure, have the testing in place, setup processes to move builds in koji when they meet gating criteria. The changes would start to be implemented in rawhide shortly after branching Fedora 26<br />
<br />
* Other developers: Pay attention to new notifications and act when necessary<br />
<br />
* Release engineering: [https://pagure.io/releng/issue/6621 #6621] <br />
<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: This change removes a milestone and all associated deliverables <br />
<br />
* Policies and guidelines: As there is no more Alpha we will need to update the guidelines to have changes be completed for Beta. We will likely want to add a new checkpoint for change implementation that currently needs to be checked at Alpha<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
There will be no change to existing systems.<br />
<br />
== How To Test ==<br />
<br />
See that there is no Alpha release any longer <br />
<br />
== User Experience ==<br />
Rawhide will be more stable and be suitable for use on a daily basis by all developers and tech enthusiasts.<br />
<br />
== Dependencies ==<br />
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --><br />
<br />
QA to have tests to detect when a new build breaks dependencies.<br />
releng to make changes to tagging in koji<br />
a tool to move builds from -pending into rawhide when it passes its tests<br />
notifications on test failures and delays in getting packages into rawhide<br />
<br />
== Contingency Plan ==<br />
<br />
<br />
* Contingency mechanism: Reinstate Alpha milestone and release. we will know if we are on target a few weeks before when Alpha would have been.<br />
* Contingency deadline: a month before alpha would have occurred <br />
* Blocks release? No<br />
* Blocks product? None<br />
<br />
== Documentation ==<br />
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --><br />
<br />
* [https://www.youtube.com/watch?v=gQskU7P1CKk&t=447s Dennis' Moving everyone to rawhide talk at DevConf]<br />
* [https://www.youtube.com/watch?v=5gqccjyjwFk&t=3s Ralph's Factory 2.0 Talk at DevConf]<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangeReadyForFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
[[Category:SystemWideChange]]</div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/NoMoreAlpha&diff=487027Changes/NoMoreAlpha2017-02-27T22:33:18Z<p>Ausil: /* Detailed Description */</p>
<hr />
<div><!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= No More Alphas <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Fedora will no longer produce Alpha releases.<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:Ausil| Dennis Gilmore]], [[User:Adamwill| Adam Williamson]]<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: dennis@ausil.us, awilliam@redhat.com<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/27 | Fedora 27 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
By gating Rawhide builds from landing in the compose and gating the publication of composes on automated test results we will ensure Rawhide will always be at Alpha quality. This will make it more generally useful to people as a daily driver and development platform, and mean we no longer need to go through the process of building, testing and shipping Alpha releases. The initial testing will be ensuring that a package is installable and that it does not break existing packages installation. Over time we can enable extra testing to gate the build going into rawhide. Builds will land in the buildroot immediatly after the build has completed, in order to be built against before they make it to the compose. We will run the gating testing only to gate builds to the compose and not in order to make the buildroot.<br />
<br />
== Benefit to Fedora ==<br />
<br />
A Rawhide that is always at least Alpha quality is a more compelling product and may attract more target users (developers) to Fedora. Removing the process overhead of Alpha releases from the cycle frees up release engineering, quality engineering, development and project management resources for other work, and potentially offers more flexibility for the Change development and branching parts of the release cycle. Preventing broken changes from reaching the official Rawhide repository at all means we are not stuck with fundamentally problematic changes (bar doing epoch bumps and rebuilds of dependent packages) but can more easily revert them.<br />
<br />
== Scope ==<br />
* Proposal owners: rearrange the koji tag and target structure, have the testing in place, setup processes to move builds in koji when they meet gating criteria. The changes would start to be implemented in rawhide shortly after branching Fedora 26<br />
<br />
* Other developers: Pay attention to new notifications and act when necessary<br />
<br />
* Release engineering: [https://pagure.io/releng/issue/6621 #6621] <br />
<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: This change removes a milestone and all associated deliverables <br />
<br />
* Policies and guidelines: As there is no more Alpha we will need to update the guidelines to have changes be completed for Beta. We will likely want to add a new checkpoint for change implementation that currently needs to be checked at Alpha<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
There will be no change to existing systems.<br />
<br />
== How To Test ==<br />
<br />
See that there is no Alpha release any longer <br />
<br />
== User Experience ==<br />
Rawhide will be more stable and be suitable for use on a daily basis by all developers and tech enthusiasts.<br />
<br />
== Dependencies ==<br />
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --><br />
<br />
QA to have tests to detect when a new build breaks dependencies.<br />
releng to make changes to tagging in koji<br />
a tool to move builds from -pending into rawhide when it passes its tests<br />
notifications on test failures and delays in getting packages into rawhide<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: a month before alpha would have occurred <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? None <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
Reinstate Alpha milestone and release. we will know if we are on target a few weeks before when Alpha would have been.<br />
<br />
== Documentation ==<br />
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --><br />
<br />
* [https://www.youtube.com/watch?v=gQskU7P1CKk&t=447s Dennis' Moving everyone to rawhide talk at DevConf]<br />
* [https://www.youtube.com/watch?v=5gqccjyjwFk&t=3s Ralph's Factory 2.0 Talk at DevConf]<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangeReadyForFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
[[Category:SystemWideChange]]</div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/NoMoreAlpha&diff=486411Changes/NoMoreAlpha2017-02-17T02:09:16Z<p>Ausil: </p>
<hr />
<div><!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= No More Alphas <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Fedora will no longer produce Alpha releases.<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:Ausil| Dennis Gilmore]], [[User:Adamwill| Adam Williamson]]<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: dennis@ausil.us, awilliam@redhat.com<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/27 | Fedora 27 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
By gating Rawhide builds from landing in the compose and gating the publication of composes on automated test results we will ensure Rawhide will always be at Alpha quality. This will make it more generally useful to people as a daily driver and development platform, and mean we no longer need to go through the process of building, testing and shipping Alpha releases. The initial testing will be ensuring that a package is installable and that it does not break existing packages installation. Over time we can enable extra testing to gate the build going into rawhide. Builds will land in the buildroot to be built against before they make it to the compose.<br />
<br />
== Benefit to Fedora ==<br />
<br />
A Rawhide that is always at least Alpha quality is a more compelling product and may attract more target users (developers) to Fedora. Removing the process overhead of Alpha releases from the cycle frees up release engineering, quality engineering, development and project management resources for other work, and potentially offers more flexibility for the Change development and branching parts of the release cycle. Preventing broken changes from reaching the official Rawhide repository at all means we are not stuck with fundamentally problematic changes (bar doing epoch bumps and rebuilds of dependent packages) but can more easily revert them.<br />
<br />
== Scope ==<br />
* Proposal owners: rearrange the koji tag and target structure, have the testing in place, setup processes to move builds in koji when they meet gating criteria. The changes would start to be implemented in rawhide shortly after branching Fedora 26<br />
<br />
* Other developers: Pay attention to new notifications and act when necessary<br />
<br />
* Release engineering: [https://pagure.io/releng/issue/6621 #6621] <br />
<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: This change removes a milestone and all associated deliverables <br />
<br />
* Policies and guidelines: As there is no more Alpha we will need to update the guidelines to have changes be completed for Beta. We will likely want to add a new checkpoint for change implementation that currently needs to be checked at Alpha<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
There will be no change to existing systems.<br />
<br />
== How To Test ==<br />
<br />
See that there is no Alpha release any longer <br />
<br />
== User Experience ==<br />
Rawhide will be more stable and be suitable for use on a daily basis by all developers and tech enthusiasts.<br />
<br />
== Dependencies ==<br />
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --><br />
<br />
QA to have tests to detect when a new build breaks dependencies.<br />
releng to make changes to tagging in koji<br />
a tool to move builds from -pending into rawhide when it passes its tests<br />
notifications on test failures and delays in getting packages into rawhide<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: a month before alpha would have occurred <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? None <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
Reinstate Alpha milestone and release. we will know if we are on target a few weeks before when Alpha would have been.<br />
<br />
== Documentation ==<br />
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --><br />
<br />
* [https://www.youtube.com/watch?v=gQskU7P1CKk&t=447s Dennis' Moving everyone to rawhide talk at DevConf]<br />
* [https://www.youtube.com/watch?v=5gqccjyjwFk&t=3s Ralph's Factory 2.0 Talk at DevConf]<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangeReadyForWrangler]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
[[Category:SystemWideChange]]</div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/NoMoreAlpha&diff=486410Changes/NoMoreAlpha2017-02-17T01:56:56Z<p>Ausil: /* Detailed Description */</p>
<hr />
<div><!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= No More Alphas <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Fedora will no longer produce Alpha releases.<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:Ausil| Dennis Gilmore]], [[User:Adamwill| Adam Williamson]]<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: dennis@ausil.us, awilliam@redhat.com<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/27 | Fedora 27 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
By gating Rawhide builds from landing in the compose and gating the publication of composes on automated test results we will ensure Rawhide will always be at Alpha quality. This will make it more generally useful to people as a daily driver and development platform, and mean we no longer need to go through the process of building, testing and shipping Alpha releases. The initial testing will be ensuring that a package is installable and that it does not break existing packages installation. Over time we can enable extra testing to gate the build going into rawhide. Builds will land in the buildroot to be built against before they make it to the compose.<br />
<br />
== Benefit to Fedora ==<br />
<br />
A Rawhide that is always at least Alpha quality is a more compelling product and may attract more target users (developers) to Fedora. Removing the process overhead of Alpha releases from the cycle frees up release engineering, quality engineering, development and project management resources for other work, and potentially offers more flexibility for the Change development and branching parts of the release cycle. Preventing broken changes from reaching the official Rawhide repository at all means we are not stuck with fundamentally problematic changes (bar doing epoch bumps and rebuilds of dependent packages) but can more easily revert them.<br />
<br />
== Scope ==<br />
* Proposal owners: rearrange the koji tag and target structure, have the testing in place, setup processes to move builds in koji when they meet gating criteria. The changes would start to be implemented in rawhide shortly after branching Fedora 26<br />
<br />
* Other developers: Pay attention to new notifications and act when necessary<br />
<br />
* Release engineering: [https://pagure.io/releng/issue/6621 #6621] <br />
<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: This change removes a milestone and all associated deliverables <br />
<br />
* Policies and guidelines: As there is no more Alpha we will need to update the guidelines to have changes be completed for Beta. We will likely want to add a new checkpoint for change implementation that currently needs to be checked at Alpha<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
There will be no change to existing systems.<br />
<br />
== How To Test ==<br />
<br />
See that there is no Alpha release any longer <br />
<br />
== User Experience ==<br />
Rawhide will be more stable and be suitable for use on a daily basis by all developers and tech enthusiasts.<br />
<br />
== Dependencies ==<br />
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --><br />
<br />
QA to have tests to detect when a new build breaks dependencies.<br />
releng to make changes to tagging in koji<br />
a tool to move builds from -pending into rawhide when it passes its tests<br />
notifications on test failures and delays in getting packages into rawhide<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: a month before alpha would have occurred <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? None <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
Reinstate Alpha milestone and release. we will know if we are on target a few weeks before when Alpha would have been.<br />
<br />
== Documentation ==<br />
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --><br />
<br />
* [https://www.youtube.com/watch?v=gQskU7P1CKk&t=447s Dennis' Moving everyone to rawhide talk at DevConf]<br />
* [https://www.youtube.com/watch?v=5gqccjyjwFk&t=3s Ralph's Factory 2.0 Talk at DevConf]<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SelfContainedChange]]<br />
<!-- [[Category:SystemWideChange]] --></div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/NoMoreAlpha&diff=486409Changes/NoMoreAlpha2017-02-17T01:52:50Z<p>Ausil: /* Detailed Description */</p>
<hr />
<div><!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= No More Alphas <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Fedora will no longer produce Alpha releases.<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:Ausil| Dennis Gilmore]], [[User:Adamwill| Adam Williamson]]<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: dennis@ausil.us, awilliam@redhat.com<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/27 | Fedora 27 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
By gating Rawhide compose publication on automated test results we will ensure Rawhide will always be at Alpha quality. This will make it more generally useful to people as a daily driver and development platform, and mean we no longer need to go through the process of building, testing and shipping Alpha releases. The initial testing will be ensuring that a package is installable and that it does not break existing packages installation. Over time we can enable extra testing to gate the build going into rawhide.<br />
<br />
== Benefit to Fedora ==<br />
<br />
A Rawhide that is always at least Alpha quality is a more compelling product and may attract more target users (developers) to Fedora. Removing the process overhead of Alpha releases from the cycle frees up release engineering, quality engineering, development and project management resources for other work, and potentially offers more flexibility for the Change development and branching parts of the release cycle. Preventing broken changes from reaching the official Rawhide repository at all means we are not stuck with fundamentally problematic changes (bar doing epoch bumps and rebuilds of dependent packages) but can more easily revert them.<br />
<br />
== Scope ==<br />
* Proposal owners: rearrange the koji tag and target structure, have the testing in place, setup processes to move builds in koji when they meet gating criteria. The changes would start to be implemented in rawhide shortly after branching Fedora 26<br />
<br />
* Other developers: Pay attention to new notifications and act when necessary<br />
<br />
* Release engineering: [https://pagure.io/releng/issue/6621 #6621] <br />
<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: This change removes a milestone and all associated deliverables <br />
<br />
* Policies and guidelines: As there is no more Alpha we will need to update the guidelines to have changes be completed for Beta. We will likely want to add a new checkpoint for change implementation that currently needs to be checked at Alpha<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
There will be no change to existing systems.<br />
<br />
== How To Test ==<br />
<br />
See that there is no Alpha release any longer <br />
<br />
== User Experience ==<br />
Rawhide will be more stable and be suitable for use on a daily basis by all developers and tech enthusiasts.<br />
<br />
== Dependencies ==<br />
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --><br />
<br />
QA to have tests to detect when a new build breaks dependencies.<br />
releng to make changes to tagging in koji<br />
a tool to move builds from -pending into rawhide when it passes its tests<br />
notifications on test failures and delays in getting packages into rawhide<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: a month before alpha would have occurred <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? None <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
Reinstate Alpha milestone and release. we will know if we are on target a few weeks before when Alpha would have been.<br />
<br />
== Documentation ==<br />
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --><br />
<br />
* [https://www.youtube.com/watch?v=gQskU7P1CKk&t=447s Dennis' Moving everyone to rawhide talk at DevConf]<br />
* [https://www.youtube.com/watch?v=5gqccjyjwFk&t=3s Ralph's Factory 2.0 Talk at DevConf]<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SelfContainedChange]]<br />
<!-- [[Category:SystemWideChange]] --></div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/NoMoreAlpha&diff=486322Changes/NoMoreAlpha2017-02-16T03:56:51Z<p>Ausil: /* Scope */</p>
<hr />
<div><!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= No More Alphas <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Fedora will no longer produce Alpha releases.<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:Ausil| Dennis Gilmore]], [[User:Adamwill| Adam Williamson]]<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: dennis@ausil.us, awilliam@redhat.com<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/27 | Fedora 27 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
By gating Rawhide compose publication on automated test results we will ensure Rawhide will always be at Alpha quality. This will make it more generally useful to people as a daily driver and development platform, and mean we no longer need to go through the process of building, testing and shipping Alpha releases.<br />
<br />
== Benefit to Fedora ==<br />
<br />
A Rawhide that is always at least Alpha quality is a more compelling product and may attract more target users (developers) to Fedora. Removing the process overhead of Alpha releases from the cycle frees up release engineering, quality engineering, development and project management resources for other work, and potentially offers more flexibility for the Change development and branching parts of the release cycle. Preventing broken changes from reaching the official Rawhide repository at all means we are not stuck with fundamentally problematic changes (bar doing epoch bumps and rebuilds of dependent packages) but can more easily revert them.<br />
<br />
== Scope ==<br />
* Proposal owners: rearrange the koji tag and target structure, have the testing in place, setup processes to move builds in koji when they meet gating criteria. The changes would start to be implemented in rawhide shortly after branching Fedora 26<br />
<br />
* Other developers: Pay attention to new notifications and act when necessary<br />
<br />
* Release engineering: [https://pagure.io/releng/issue/6621 #6621] <br />
<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: This change removes a milestone and all associated deliverables <br />
<br />
* Policies and guidelines: As there is no more Alpha we will need to update the guidelines to have changes be completed for Beta. We will likely want to add a new checkpoint for change implementation that currently needs to be checked at Alpha<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
There will be no change to existing systems.<br />
<br />
== How To Test ==<br />
<br />
See that there is no Alpha release any longer <br />
<br />
== User Experience ==<br />
Rawhide will be more stable and be suitable for use on a daily basis by all developers and tech enthusiasts.<br />
<br />
== Dependencies ==<br />
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --><br />
<br />
QA to have tests to detect when a new build breaks dependencies.<br />
releng to make changes to tagging in koji<br />
a tool to move builds from -pending into rawhide when it passes its tests<br />
notifications on test failures and delays in getting packages into rawhide<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: a month before alpha would have occurred <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? None <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
Reinstate Alpha milestone and release. we will know if we are on target a few weeks before when Alpha would have been.<br />
<br />
== Documentation ==<br />
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --><br />
<br />
* [https://www.youtube.com/watch?v=gQskU7P1CKk&t=447s Dennis' Moving everyone to rawhide talk at DevConf]<br />
* [https://www.youtube.com/watch?v=5gqccjyjwFk&t=3s Ralph's Factory 2.0 Talk at DevConf]<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SelfContainedChange]]<br />
<!-- [[Category:SystemWideChange]] --></div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/NoMoreAlpha&diff=486320Changes/NoMoreAlpha2017-02-16T02:45:30Z<p>Ausil: /* Benefit to Fedora */</p>
<hr />
<div><!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= No More Alphas <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Fedora will no longer produce Alpha releases.<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:Ausil| Dennis Gilmore]], [[User:Adamwill| Adam Williamson]]<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: dennis@ausil.us, awilliam@redhat.com<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/27 | Fedora 27 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
By gating Rawhide compose publication on automated test results we will ensure Rawhide will always be at Alpha quality. This will make it more generally useful to people as a daily driver and development platform, and mean we no longer need to go through the process of building, testing and shipping Alpha releases.<br />
<br />
== Benefit to Fedora ==<br />
<br />
A Rawhide that is always at least Alpha quality is a more compelling product and may attract more target users (developers) to Fedora. Removing the process overhead of Alpha releases from the cycle frees up release engineering, quality engineering, development and project management resources for other work, and potentially offers more flexibility for the Change development and branching parts of the release cycle. Preventing broken changes from reaching the official Rawhide repository at all means we are not stuck with fundamentally problematic changes (bar doing epoch bumps and rebuilds of dependent packages) but can more easily revert them.<br />
<br />
== Scope ==<br />
* Proposal owners: rearrange the koji tag and target structure, have the testing in place, setup processes to move builds in koji when they pass testing<br />
<br />
* Other developers: Pay attention to new notifications and act when necessary<br />
<br />
* Release engineering: [https://pagure.io/releng/issue/6621 #6621] <br />
<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: This change removes a milestone and all associated deliverables <br />
<br />
* Policies and guidelines: As there is no more Alpha we will need to update the guidelines to have changes be completed for Beta. We will likely want to add a new checkpoint for change impelemtation that currently needs to be checked at Alpha<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
There will be no change to existing systems.<br />
<br />
== How To Test ==<br />
<br />
See that there is no Alpha release any longer <br />
<br />
== User Experience ==<br />
Rawhide will be more stable and be suitable for use on a daily basis by all developers and tech enthusiasts.<br />
<br />
== Dependencies ==<br />
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --><br />
<br />
QA to have tests to detect when a new build breaks dependencies.<br />
releng to make changes to tagging in koji<br />
a tool to move builds from -pending into rawhide when it passes its tests<br />
notifications on test failures and delays in getting packages into rawhide<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: a month before alpha would have occurred <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? None <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
Reinstate Alpha milestone and release. we will know if we are on target a few weeks before when Alpha would have been.<br />
<br />
== Documentation ==<br />
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --><br />
<br />
* [https://www.youtube.com/watch?v=gQskU7P1CKk&t=447s Dennis' Moving everyone to rawhide talk at DevConf]<br />
* [https://www.youtube.com/watch?v=5gqccjyjwFk&t=3s Ralph's Factory 2.0 Talk at DevConf]<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SelfContainedChange]]<br />
<!-- [[Category:SystemWideChange]] --></div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/NoMoreAlpha&diff=486318Changes/NoMoreAlpha2017-02-16T02:31:36Z<p>Ausil: /* Detailed Description */</p>
<hr />
<div><!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= No More Alphas <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Fedora will no longer produce Alpha releases.<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:Ausil| Dennis Gilmore]], [[User:Adamwill| Adam Williamson]]<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: dennis@ausil.us, awilliam@redhat.com<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/27 | Fedora 27 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
By gating Rawhide compose publication on automated test results we will ensure Rawhide will always be at Alpha quality. This will make it more generally useful to people as a daily driver and development platform, and mean we no longer need to go through the process of building, testing and shipping Alpha releases.<br />
<br />
== Benefit to Fedora ==<br />
<br />
By keeping rawhide always at Alpha quality or better we provide a compelling environment for people to have the latest and greatest bits. Developers and tech enthusiasts would want to be running rawhide. Which will result in it getting bug fixes quicker and resulting in an overall better development release. We can drop Alpha releases as we will always be at Alpha quality, by no longer doing Alpha we gain an extra 4 weeks in the schedule which will let us do more. We may need to add a Change testing checkpoint to ensure that new Changes are progressing and are testable, without the need of freezing and branching. The cost of the checkpoint milestone will be much less than the current cost of doing an Alpha release is. We will able to branch 4 weeks later in the schedule than we had previously.<br />
<br />
== Scope ==<br />
* Proposal owners: rearrange the koji tag and target structure, have the testing in place, setup processes to move builds in koji when they pass testing<br />
<br />
* Other developers: Pay attention to new notifications and act when necessary<br />
<br />
* Release engineering: [https://pagure.io/releng/issue/6621 #6621] <br />
<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: This change removes a milestone and all associated deliverables <br />
<br />
* Policies and guidelines: As there is no more Alpha we will need to update the guidelines to have changes be completed for Beta. We will likely want to add a new checkpoint for change impelemtation that currently needs to be checked at Alpha<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
There will be no change to existing systems.<br />
<br />
== How To Test ==<br />
<br />
See that there is no Alpha release any longer <br />
<br />
== User Experience ==<br />
Rawhide will be more stable and be suitable for use on a daily basis by all developers and tech enthusiasts.<br />
<br />
== Dependencies ==<br />
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --><br />
<br />
QA to have tests to detect when a new build breaks dependencies.<br />
releng to make changes to tagging in koji<br />
a tool to move builds from -pending into rawhide when it passes its tests<br />
notifications on test failures and delays in getting packages into rawhide<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: a month before alpha would have occurred <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? None <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
Reinstate Alpha milestone and release. we will know if we are on target a few weeks before when Alpha would have been.<br />
<br />
== Documentation ==<br />
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --><br />
<br />
* [https://www.youtube.com/watch?v=gQskU7P1CKk&t=447s Dennis' Moving everyone to rawhide talk at DevConf]<br />
* [https://www.youtube.com/watch?v=5gqccjyjwFk&t=3s Ralph's Factory 2.0 Talk at DevConf]<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SelfContainedChange]]<br />
<!-- [[Category:SystemWideChange]] --></div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/NoMoreAlpha&diff=486317Changes/NoMoreAlpha2017-02-16T02:24:42Z<p>Ausil: /* Documentation */</p>
<hr />
<div><!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= No More Alphas <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Fedora will no longer produce Alpha releases.<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:Ausil| Dennis Gilmore]], [[User:Adamwill| Adam Williamson]]<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: dennis@ausil.us, awilliam@redhat.com<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/27 | Fedora 27 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
By adding gating on Rawhide we will enable rawhide to be more stable and generally useful to people as a daily driver. As a result rawhide should always be at alpha quality, by keeping Rawhide always at Alpha quality we will be no longer need to do Alpha releases.<br />
<br />
== Benefit to Fedora ==<br />
<br />
By keeping rawhide always at Alpha quality or better we provide a compelling environment for people to have the latest and greatest bits. Developers and tech enthusiasts would want to be running rawhide. Which will result in it getting bug fixes quicker and resulting in an overall better development release. We can drop Alpha releases as we will always be at Alpha quality, by no longer doing Alpha we gain an extra 4 weeks in the schedule which will let us do more. We may need to add a Change testing checkpoint to ensure that new Changes are progressing and are testable, without the need of freezing and branching. The cost of the checkpoint milestone will be much less than the current cost of doing an Alpha release is. We will able to branch 4 weeks later in the schedule than we had previously.<br />
<br />
== Scope ==<br />
* Proposal owners: rearrange the koji tag and target structure, have the testing in place, setup processes to move builds in koji when they pass testing<br />
<br />
* Other developers: Pay attention to new notifications and act when necessary<br />
<br />
* Release engineering: [https://pagure.io/releng/issue/6621 #6621] <br />
<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: This change removes a milestone and all associated deliverables <br />
<br />
* Policies and guidelines: As there is no more Alpha we will need to update the guidelines to have changes be completed for Beta. We will likely want to add a new checkpoint for change impelemtation that currently needs to be checked at Alpha<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
There will be no change to existing systems.<br />
<br />
== How To Test ==<br />
<br />
See that there is no Alpha release any longer <br />
<br />
== User Experience ==<br />
Rawhide will be more stable and be suitable for use on a daily basis by all developers and tech enthusiasts.<br />
<br />
== Dependencies ==<br />
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --><br />
<br />
QA to have tests to detect when a new build breaks dependencies.<br />
releng to make changes to tagging in koji<br />
a tool to move builds from -pending into rawhide when it passes its tests<br />
notifications on test failures and delays in getting packages into rawhide<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: a month before alpha would have occurred <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? None <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
Reinstate Alpha milestone and release. we will know if we are on target a few weeks before when Alpha would have been.<br />
<br />
== Documentation ==<br />
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --><br />
<br />
* [https://www.youtube.com/watch?v=gQskU7P1CKk&t=447s Dennis' Moving everyone to rawhide talk at DevConf]<br />
* [https://www.youtube.com/watch?v=5gqccjyjwFk&t=3s Ralph's Factory 2.0 Talk at DevConf]<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SelfContainedChange]]<br />
<!-- [[Category:SystemWideChange]] --></div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/NoMoreAlpha&diff=486316Changes/NoMoreAlpha2017-02-16T02:17:32Z<p>Ausil: /* Detailed Description */</p>
<hr />
<div><!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= No More Alphas <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Fedora will no longer produce Alpha releases.<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:Ausil| Dennis Gilmore]], [[User:Adamwill| Adam Williamson]]<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: dennis@ausil.us, awilliam@redhat.com<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/27 | Fedora 27 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
By adding gating on Rawhide we will enable rawhide to be more stable and generally useful to people as a daily driver. As a result rawhide should always be at alpha quality, by keeping Rawhide always at Alpha quality we will be no longer need to do Alpha releases.<br />
<br />
== Benefit to Fedora ==<br />
<br />
By keeping rawhide always at Alpha quality or better we provide a compelling environment for people to have the latest and greatest bits. Developers and tech enthusiasts would want to be running rawhide. Which will result in it getting bug fixes quicker and resulting in an overall better development release. We can drop Alpha releases as we will always be at Alpha quality, by no longer doing Alpha we gain an extra 4 weeks in the schedule which will let us do more. We may need to add a Change testing checkpoint to ensure that new Changes are progressing and are testable, without the need of freezing and branching. The cost of the checkpoint milestone will be much less than the current cost of doing an Alpha release is. We will able to branch 4 weeks later in the schedule than we had previously.<br />
<br />
== Scope ==<br />
* Proposal owners: rearrange the koji tag and target structure, have the testing in place, setup processes to move builds in koji when they pass testing<br />
<br />
* Other developers: Pay attention to new notifications and act when necessary<br />
<br />
* Release engineering: [https://pagure.io/releng/issue/6621 #6621] <br />
<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: This change removes a milestone and all associated deliverables <br />
<br />
* Policies and guidelines: As there is no more Alpha we will need to update the guidelines to have changes be completed for Beta. We will likely want to add a new checkpoint for change impelemtation that currently needs to be checked at Alpha<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
There will be no change to existing systems.<br />
<br />
== How To Test ==<br />
<br />
See that there is no Alpha release any longer <br />
<br />
== User Experience ==<br />
Rawhide will be more stable and be suitable for use on a daily basis by all developers and tech enthusiasts.<br />
<br />
== Dependencies ==<br />
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --><br />
<br />
QA to have tests to detect when a new build breaks dependencies.<br />
releng to make changes to tagging in koji<br />
a tool to move builds from -pending into rawhide when it passes its tests<br />
notifications on test failures and delays in getting packages into rawhide<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: a month before alpha would have occurred <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? None <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
Reinstate Alpha milestone and release. we will know if we are on target a few weeks before when Alpha would have been.<br />
<br />
== Documentation ==<br />
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --><br />
<br />
[https://www.youtube.com/watch?v=gQskU7P1CKk&t=447s Dennis' Moving everyone to rawhide talk at DevConf]<br />
[https://www.youtube.com/watch?v=5gqccjyjwFk&t=3s Ralph's Factory 2.0 Talk at DevConf]<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SelfContainedChange]]<br />
<!-- [[Category:SystemWideChange]] --></div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/NoMoreAlpha&diff=486315Changes/NoMoreAlpha2017-02-16T02:08:00Z<p>Ausil: /* Benefit to Fedora */</p>
<hr />
<div><!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= No More Alphas <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Fedora will no longer produce Alpha releases.<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:Ausil| Dennis Gilmore]], [[User:Adamwill| Adam Williamson]]<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: dennis@ausil.us, awilliam@redhat.com<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/27 | Fedora 27 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
By adding CI and gating on Rawhide we will enable rawhide to be more stable and generally useful to people as a daily driver. As a result rawhide should always be at alpha quality, by keeping Rawhide always at Alpha quality we will be no longer need to do Alpha releases.<br />
<br />
== Benefit to Fedora ==<br />
<br />
By keeping rawhide always at Alpha quality or better we provide a compelling environment for people to have the latest and greatest bits. Developers and tech enthusiasts would want to be running rawhide. Which will result in it getting bug fixes quicker and resulting in an overall better development release. We can drop Alpha releases as we will always be at Alpha quality, by no longer doing Alpha we gain an extra 4 weeks in the schedule which will let us do more. We may need to add a Change testing checkpoint to ensure that new Changes are progressing and are testable, without the need of freezing and branching. The cost of the checkpoint milestone will be much less than the current cost of doing an Alpha release is. We will able to branch 4 weeks later in the schedule than we had previously.<br />
<br />
== Scope ==<br />
* Proposal owners: rearrange the koji tag and target structure, have the testing in place, setup processes to move builds in koji when they pass testing<br />
<br />
* Other developers: Pay attention to new notifications and act when necessary<br />
<br />
* Release engineering: [https://pagure.io/releng/issue/6621 #6621] <br />
<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: This change removes a milestone and all associated deliverables <br />
<br />
* Policies and guidelines: As there is no more Alpha we will need to update the guidelines to have changes be completed for Beta. We will likely want to add a new checkpoint for change impelemtation that currently needs to be checked at Alpha<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
There will be no change to existing systems.<br />
<br />
== How To Test ==<br />
<br />
See that there is no Alpha release any longer <br />
<br />
== User Experience ==<br />
Rawhide will be more stable and be suitable for use on a daily basis by all developers and tech enthusiasts.<br />
<br />
== Dependencies ==<br />
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --><br />
<br />
QA to have tests to detect when a new build breaks dependencies.<br />
releng to make changes to tagging in koji<br />
a tool to move builds from -pending into rawhide when it passes its tests<br />
notifications on test failures and delays in getting packages into rawhide<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: a month before alpha would have occurred <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? None <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
Reinstate Alpha milestone and release. we will know if we are on target a few weeks before when Alpha would have been.<br />
<br />
== Documentation ==<br />
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --><br />
<br />
[https://www.youtube.com/watch?v=gQskU7P1CKk&t=447s Dennis' Moving everyone to rawhide talk at DevConf]<br />
[https://www.youtube.com/watch?v=5gqccjyjwFk&t=3s Ralph's Factory 2.0 Talk at DevConf]<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SelfContainedChange]]<br />
<!-- [[Category:SystemWideChange]] --></div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/NoMoreAlpha&diff=486314Changes/NoMoreAlpha2017-02-16T01:56:18Z<p>Ausil: </p>
<hr />
<div><!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= No More Alphas <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Fedora will no longer produce Alpha releases.<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:Ausil| Dennis Gilmore]], [[User:Adamwill| Adam Williamson]]<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: dennis@ausil.us, awilliam@redhat.com<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/27 | Fedora 27 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
By adding CI and gating on Rawhide we will enable rawhide to be more stable and generally useful to people as a daily driver. As a result rawhide should always be at alpha quality, by keeping Rawhide always at Alpha quality we will be no longer need to do Alpha releases.<br />
<br />
== Benefit to Fedora ==<br />
<br />
<br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners: rearrange the koji tag and target structure, have the testing in place, setup processes to move builds in koji when they pass testing<br />
<br />
* Other developers: Pay attention to new notifications and act when necessary<br />
<br />
* Release engineering: [https://pagure.io/releng/issue/6621 #6621] <br />
<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: This change removes a milestone and all associated deliverables <br />
<br />
* Policies and guidelines: As there is no more Alpha we will need to update the guidelines to have changes be completed for Beta. We will likely want to add a new checkpoint for change impelemtation that currently needs to be checked at Alpha<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
There will be no change to existing systems.<br />
<br />
== How To Test ==<br />
<br />
See that there is no Alpha release any longer <br />
<br />
== User Experience ==<br />
Rawhide will be more stable and be suitable for use on a daily basis by all developers and tech enthusiasts.<br />
<br />
== Dependencies ==<br />
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --><br />
<br />
QA to have tests to detect when a new build breaks dependencies.<br />
releng to make changes to tagging in koji<br />
a tool to move builds from -pending into rawhide when it passes its tests<br />
notifications on test failures and delays in getting packages into rawhide<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: a month before alpha would have occurred <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? None <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
Reinstate Alpha milestone and release. we will know if we are on target a few weeks before when Alpha would have been.<br />
<br />
== Documentation ==<br />
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --><br />
<br />
[https://www.youtube.com/watch?v=gQskU7P1CKk&t=447s Dennis' Moving everyone to rawhide talk at DevConf]<br />
[https://www.youtube.com/watch?v=5gqccjyjwFk&t=3s Ralph's Factory 2.0 Talk at DevConf]<br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SelfContainedChange]]<br />
<!-- [[Category:SystemWideChange]] --></div>Ausilhttps://fedoraproject.org/w/index.php?title=ReleaseEngineering/Meeting_Process&diff=486008ReleaseEngineering/Meeting Process2017-02-13T15:38:07Z<p>Ausil: /* Day of meeting */</p>
<hr />
<div>= releng meeting process =<br />
<br />
This guide explains how to manage and run a releng IRC meeting. Many of the steps here could well apply to other groups that hold regular IRC meetings as well. <br />
<br />
== Pre-meeting ==<br />
<br />
1 "business day" before the meeting is scheduled, do the following tasks: (So, Friday if meetings are Monday, etc)<br />
<br />
1. First check the pagure issue items that have the 'meeting' keyword: <br />
<br />
https://pagure.io/releng/issues?status=Open&tags=meeting<br />
<br />
2. Generate an email to the rel-eng@lists.fedoraproject.org list with the following template: <br />
{{#tag:pre|<br />
Schedule for Monday's Release Engineering Meeting ({{#time:Y-m-d|monday}})<br />
}}<br />
(Replace "Monday's" with the day of week for the meeting)<br />
{{#tag:pre|<br />
<br />
Following is the list of topics that will be discussed in the releng<br />
meeting Monday at 14:30UTC in #fedora-meeting-2 on irc.freenode.net.<br />
<br />
To convert UTC to your local time, take a look at<br />
http://fedoraproject.org/wiki/UTCHowto<br />
<br />
or run:<br />
date -d '{{#time:Y-m-d|monday}} 14:30 UTC'<br />
<br />
<br />
Links to all tickets below can be found at: <br />
https://pagure.io/releng/issues?status=Open&tags=meeting<br />
<br />
= Alternative Architectures =<br />
#topic Alternative Architectures update<br />
<br />
= Followups =<br />
<br />
#topic #NNNN Title of ticket<br />
https://pagure.io/releng/issue/NNNN<br />
<br />
= New business =<br />
<br />
#topic #NNNN Title of ticket<br />
<br />
https://pagure.io/releng/issue/NNNN<br />
<br />
= Open Floor = <br />
<br />
For more complete details, please visit each individual ticket. The<br />
report of the agenda items can be found at<br />
https://pagure.io/releng/issues?status=Open&tags=meeting<br />
<br />
If you would like to add something to this agenda, you can reply to<br />
this e-mail, file a new ticket at https://pagure.io/releng/issues,<br />
e-mail me directly, or bring it up at the end of the meeting, during<br />
the open floor topic. Note that added topics may be deferred until<br />
the following meeting. <br />
}}<br />
<br />
Replace NNNN with the ticket numbers and add in Title of tickets.<br />
<br />
= Day of meeting =<br />
<br />
1. Send out a reminder IRC message a bit before the meeting to the #fedora-releng IRC channel. <br />
<br />
2. Generate a text file from the following template: <br />
<br />
{{#tag:pre|<br />
#startmeeting RELENG ({{#time:Y-m-d|monday}})<br />
#meetingname releng<br />
#chair dgilmore nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu<br />
#topic init process<br />
#topic #NNNN TICKET TITLE<br />
...<br />
#topic Alternative Architectures updates<br />
#topic Open Floor<br />
#endmeeting<br />
}}<br />
<br />
You can copy and paste in lines from this file as the meeting progresses. <br />
<br />
3. Start an email replying to the agenda post. Rename the subject to: Summary/Minutes for today's release engineering meeting ({{#time:Y-m-d|monday}})<br />
<br />
4. Also, CC: meetingminutes@lists.fedoraproject.org<br />
<br />
== Meeting time ==<br />
<br />
1. Use the lines up to 'init process' to start the meeting. <br />
<br />
2. Wait a few for people to show up. Confirm there are at members present for discussion. If not, cancel meeting. <br />
<br />
3. Go through each topic.<br />
<br />
== Post meeting ==<br />
<br />
1. When #endmeeting runs it displays links for the logs. Use the .txt files in your email created above. Send out right after meeting. (If you wait, it's very easy to forget). (Make sure and CC: meetingminutes@lists.fedoraproject.org too) <br />
<br />
The subject should be:<br />
<br />
{{#tag:pre|<br />
Fedora Release Engineering meeting summary for {{#time:Y-m-d|monday}}<br />
}}<br />
<br />
2. Process through tickets comment/close them as appropriate.<br />
<br />
[[Category: Release Engineering]]</div>Ausilhttps://fedoraproject.org/w/index.php?title=Architectures&diff=485727Architectures2017-02-08T21:10:30Z<p>Ausil: /* Structure */</p>
<hr />
<div>= Fedora Architectures =<br />
<br />
'''Author:''' [[TomCallaway| Tom 'spot' Callaway]], others <BR><br />
<br />
<br />
<br />
<br />
== Structure ==<br />
There are two tiers of architectures with Fedora support:<br />
* [[PrimaryArchitectures| Primary Architectures]] : These are architectures with the majority of the users, the most common architectures. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd).<br />
* [[AlternativeArchitectures| Alternative Architectures]] : These are architectures with motivated Architecture Maintainer Teams. There are two classes of Alternative Architecturs, the ones built in Primary koji where build failures are fatal and ones built on their own koji instances where build failures on the alternative architecture are not fatal: if packages successfully build for the primary koji, they push independently of any alternative architecture build successes or failures.<br />
<br />
{{Anchor|PrimaryArchitectures}}<br />
=== Primary Architectures ===<br />
* [[Architectures/ARM|ARM]]-hfp (32-bit, little-endian, hfp for ARMv7->) (as of Fedora 20)<br />
* x86 (32-bit for i686->) (until Fedora 25)<br />
* [[Architectures/x86-64|x86_64]] (64-bit)<br />
{{Anchor|SecondaryArchitectures}}<br />
<br />
=== Alternative Architectures ===<br />
* <strike>[[Architectures/ARM|ARM]]-sfp (32-bit, little-endian, sfp for ARMv5->)</strike><br />
* ARM [[Architectures/AArch64|AArch64]] (64-bit, little-endian for ARMv8->)<br />
* <strike>[[Architectures/IA64|IA64]]</strike><br />
* [[Architectures/MIPS|MIPS]]-64el (mips64r2, little endian, n64 ABI)<br />
* [[Architectures/MIPS|MIPS]]-el (mips32r2, little endian, o32 ABI)<br />
* <strike>[[Architectures/MIPS|MIPS]]-n32el (mips64r2, little endian, n32 ABI)</strike><br />
* <strike>[[Architectures/Parisc|Parisc]]</strike><br />
* <strike>[[Architectures/PowerPC|PowerPC]] (32-bit)</strike><br />
* [[Architectures/PowerPC|PowerPC64]] (64-bit, big-endian for POWER5->)<br />
* [[Architectures/PowerPC|PowerPC64le]] (64-bit, little-endian for POWER8->)<br />
* [[Architectures/RISC-V|RISC-V]] (64-bit open source ISA)<br />
* [[Architectures/s390x|s390x]] (64-bit for z10->)<br />
* <strike>[[Architectures/SPARC|SPARC]] (32-bit)</strike><br />
* <strike>[[Architectures/SPARC|SPARC64]] (64-bit for sun4u->)</strike><br />
* x86 (32-bit for i686->) (as of Fedora 26)<br />
<br />
{{Anchor|Architecture Maintainer Teams}}<br />
<br />
== Architecture Maintainer Teams ==<br />
<br />
In order to manage and support alternative architectures, each alternative architecture will have a team responsible for the Fedora release on that architecture. Each team will assign a team lead. <br />
<br />
=== Architecture Maintainer Team Responsibilities ===<br />
<br />
* Receiving notifications of alternative arch build successes and failures<br />
* Patching packages cleanly such that they build and function correctly on the alternative architecture, with a minimal amount of architecture conditionalization in the spec file (avoid %ifarch wherever possible). To enable this, architecture team members will have special grouped ACL access to all packages, permitting them special access to make changes. This ability requires a great amount of respect, and alternative architecture maintainers are expected to be extremely careful when modifying packages. With special access comes extra responsibility. Think before you commit. Consult the package maintainer before making a change, no matter how trivial.<br />
* Resolving architecture specific bugs filed against packages<br />
* Holding regular status meetings on IRC for the architecture<br />
* Meeting target dates for architecture stability, freezes, release candidates, and releases. If unable to meet target dates, release does not occur. Target dates for alternative architectures can be slightly farther out than the target dates for primary architectures, allowing for longer build times and architecture fixes for packages frozen for primary architectures. If an alternative architecture fails to make release goals for two consecutive Fedora releases, the architecture will be re-evaluated by FESCo.<br />
* Maintaining and hosting the buildserver(s) and storage for that architecture<br />
* working with [https://docs.pagure.org/releng/ Release Engineering] on Composing trees for that architecture<br />
* Maintain a section on the fedoraproject.org wiki for the architecture, documenting the effort, the maintainer team, the meeting schedule, and other useful information for users, packagers, and developers.<br />
* Participate in and give progress reports to the Release Engineering meeting on a weekly basis<br />
<br />
Each alternative architecture maintainer team will have a dedicated mailing list (e.g. fedora-arm@lists.fp.o) to serve as a contact point for architecture specific questions, bug notifications, build notifications, etc.<br />
<br />
There is a generic alternative arch list at [https://admin.fedoraproject.org/mailman/listinfo/secondary secondary@lists.fedoraproject.org] one or more team members should subscribe here.<br />
<br />
In addition, alternative architecture teams '''should''' do the following:<br />
* Run regular 'rebuild all in mock' runs (usually requires dedicated system)<br />
<br />
== Logistics ==<br />
<br />
=== Buildsystems ===<br />
Alternative architectures will need to provide their own hardware, to act as build servers for the koji buildsystem. Neither Red Hat nor the Fedora Project is able to guarantee to provide hosting space for Alternative Architecture systems at this time. Alternative Architecture koji buildsystems need to be accessible via the internet, so that they can communicate with the primary Fedora koji infrastructure and be accessed by all fedora contributors. All builds have to happen in a native environment. this means cross compiling is not allowed, you can however use virtualisation to emulate your target system.<br />
<br />
=== File Storage ===<br />
Alternative architectures will need to provide their own file storage for the buildsystem, there may be some available from Fedora Infrastructure, composed trees will be hosted at https://dl.fedoraproject.org/pub/fedora-secondary. Fedora mirrors can choose whether they wish to mirror alternative architecture trees on an arch-by-arch basis.<br />
<br />
=== Tree Composition ===<br />
Fedora Release Engineering will not have any responsibility for composing Alternative Architecture trees for Architectures that are built outside of primary koji. Composing trees and install media is the responsibility of the Alternative Architecture team. Each team should expect to have a dedicated server for compose purposes (if possible).<br />
<br />
=== Sandbox Systems ===<br />
Alternative architecture teams are encouraged to make a "sandbox", or testing system publicly available for Fedora packagers. It is possible to configure a system so that only Fedora Account System users with packager access can ssh into the box, using their FAS credentials.<br />
<br />
'''***TODO***''' Document how to set this up.<br />
<br />
While sandbox systems are very useful for Fedora packagers who would not normally have access to the hardware architecture, they are not a requirement.<br />
<br />
== Packaging Issues ==<br />
<br />
=== Divergence from Primary Architectures ===<br />
Alternative architecture package trees should be as close to primary architecture package trees as possible. Alternative architectures should not use older versions and must not use customized (hacked up) packages. Alternative architectures may include architecture specific packages where relevant (e.g. bootloaders, xorg drivers). Changes to support alternative architectures must be committed in GIT for each package.<br />
<br />
=== ExcludeArch & ExclusiveArch ===<br />
Fedora Packages should avoid using ExclusiveArch, except when absolutely correct. Only packages which are exclusively arch specific should use ExclusiveArch (e.g. a bootloader designed for only one architecture). ExcludeArch should only be set when the architecture is not relevant for the package, the package is non-functional on the architecture, or the code does not compile cleanly for the architecture.<br />
<br />
By using ExcludeArch on an arch by arch basis, it enables the majority of packages to have the chance to build on new alternative architectures, rather than being immediately ignored by a blanket ExclusiveArch. There is a process running that will notify architecture maintainers of all changes in Exclude and Exclusive Arch headers along with daily summaries of all packages with architecture specific handling<br />
<br />
=== Tracker Bugs ===<br />
Any packager which sets ExcludeArch for an architecture must open a bug against that package, and block that bug against the appropriate ExcludeArch blocker bug.<br />
<br />
This will help the Alternative Architecture team track and fix packages for their architecture.</div>Ausilhttps://fedoraproject.org/w/index.php?title=Architectures&diff=485726Architectures2017-02-08T21:09:40Z<p>Ausil: </p>
<hr />
<div>= Fedora Architectures =<br />
<br />
'''Author:''' [[TomCallaway| Tom 'spot' Callaway]], others <BR><br />
<br />
<br />
<br />
<br />
== Structure ==<br />
There are two tiers of architectures with Fedora support:<br />
* [[PrimaryArchitectures| Primary Architectures]] : These are architectures with the majority of the users, the most common architectures. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd).<br />
* [[AlternativeArchitectures| Alternative Architectures]] : These are architectures with motivated Architecture Maintainer Teams. There are two classes of Alternative Architecturs, the ones built in Primary koji where build failures are fatal and ones built on their own koji instances where build failures on the secondary architecture are not fatal: if packages successfully build for the primary koji, they push independently of any alternative architecture build successes or failures.<br />
<br />
{{Anchor|PrimaryArchitectures}}<br />
=== Primary Architectures ===<br />
* [[Architectures/ARM|ARM]]-hfp (32-bit, little-endian, hfp for ARMv7->) (as of Fedora 20)<br />
* x86 (32-bit for i686->) (until Fedora 25)<br />
* [[Architectures/x86-64|x86_64]] (64-bit)<br />
{{Anchor|SecondaryArchitectures}}<br />
<br />
=== Alternative Architectures ===<br />
* <strike>[[Architectures/ARM|ARM]]-sfp (32-bit, little-endian, sfp for ARMv5->)</strike><br />
* ARM [[Architectures/AArch64|AArch64]] (64-bit, little-endian for ARMv8->)<br />
* <strike>[[Architectures/IA64|IA64]]</strike><br />
* [[Architectures/MIPS|MIPS]]-64el (mips64r2, little endian, n64 ABI)<br />
* [[Architectures/MIPS|MIPS]]-el (mips32r2, little endian, o32 ABI)<br />
* <strike>[[Architectures/MIPS|MIPS]]-n32el (mips64r2, little endian, n32 ABI)</strike><br />
* <strike>[[Architectures/Parisc|Parisc]]</strike><br />
* <strike>[[Architectures/PowerPC|PowerPC]] (32-bit)</strike><br />
* [[Architectures/PowerPC|PowerPC64]] (64-bit, big-endian for POWER5->)<br />
* [[Architectures/PowerPC|PowerPC64le]] (64-bit, little-endian for POWER8->)<br />
* [[Architectures/RISC-V|RISC-V]] (64-bit open source ISA)<br />
* [[Architectures/s390x|s390x]] (64-bit for z10->)<br />
* <strike>[[Architectures/SPARC|SPARC]] (32-bit)</strike><br />
* <strike>[[Architectures/SPARC|SPARC64]] (64-bit for sun4u->)</strike><br />
* x86 (32-bit for i686->) (as of Fedora 26)<br />
<br />
{{Anchor|Architecture Maintainer Teams}}<br />
<br />
== Architecture Maintainer Teams ==<br />
<br />
In order to manage and support alternative architectures, each alternative architecture will have a team responsible for the Fedora release on that architecture. Each team will assign a team lead. <br />
<br />
=== Architecture Maintainer Team Responsibilities ===<br />
<br />
* Receiving notifications of alternative arch build successes and failures<br />
* Patching packages cleanly such that they build and function correctly on the alternative architecture, with a minimal amount of architecture conditionalization in the spec file (avoid %ifarch wherever possible). To enable this, architecture team members will have special grouped ACL access to all packages, permitting them special access to make changes. This ability requires a great amount of respect, and alternative architecture maintainers are expected to be extremely careful when modifying packages. With special access comes extra responsibility. Think before you commit. Consult the package maintainer before making a change, no matter how trivial.<br />
* Resolving architecture specific bugs filed against packages<br />
* Holding regular status meetings on IRC for the architecture<br />
* Meeting target dates for architecture stability, freezes, release candidates, and releases. If unable to meet target dates, release does not occur. Target dates for alternative architectures can be slightly farther out than the target dates for primary architectures, allowing for longer build times and architecture fixes for packages frozen for primary architectures. If an alternative architecture fails to make release goals for two consecutive Fedora releases, the architecture will be re-evaluated by FESCo.<br />
* Maintaining and hosting the buildserver(s) and storage for that architecture<br />
* working with [https://docs.pagure.org/releng/ Release Engineering] on Composing trees for that architecture<br />
* Maintain a section on the fedoraproject.org wiki for the architecture, documenting the effort, the maintainer team, the meeting schedule, and other useful information for users, packagers, and developers.<br />
* Participate in and give progress reports to the Release Engineering meeting on a weekly basis<br />
<br />
Each alternative architecture maintainer team will have a dedicated mailing list (e.g. fedora-arm@lists.fp.o) to serve as a contact point for architecture specific questions, bug notifications, build notifications, etc.<br />
<br />
There is a generic alternative arch list at [https://admin.fedoraproject.org/mailman/listinfo/secondary secondary@lists.fedoraproject.org] one or more team members should subscribe here.<br />
<br />
In addition, alternative architecture teams '''should''' do the following:<br />
* Run regular 'rebuild all in mock' runs (usually requires dedicated system)<br />
<br />
== Logistics ==<br />
<br />
=== Buildsystems ===<br />
Alternative architectures will need to provide their own hardware, to act as build servers for the koji buildsystem. Neither Red Hat nor the Fedora Project is able to guarantee to provide hosting space for Alternative Architecture systems at this time. Alternative Architecture koji buildsystems need to be accessible via the internet, so that they can communicate with the primary Fedora koji infrastructure and be accessed by all fedora contributors. All builds have to happen in a native environment. this means cross compiling is not allowed, you can however use virtualisation to emulate your target system.<br />
<br />
=== File Storage ===<br />
Alternative architectures will need to provide their own file storage for the buildsystem, there may be some available from Fedora Infrastructure, composed trees will be hosted at https://dl.fedoraproject.org/pub/fedora-secondary. Fedora mirrors can choose whether they wish to mirror alternative architecture trees on an arch-by-arch basis.<br />
<br />
=== Tree Composition ===<br />
Fedora Release Engineering will not have any responsibility for composing Alternative Architecture trees for Architectures that are built outside of primary koji. Composing trees and install media is the responsibility of the Alternative Architecture team. Each team should expect to have a dedicated server for compose purposes (if possible).<br />
<br />
=== Sandbox Systems ===<br />
Alternative architecture teams are encouraged to make a "sandbox", or testing system publicly available for Fedora packagers. It is possible to configure a system so that only Fedora Account System users with packager access can ssh into the box, using their FAS credentials.<br />
<br />
'''***TODO***''' Document how to set this up.<br />
<br />
While sandbox systems are very useful for Fedora packagers who would not normally have access to the hardware architecture, they are not a requirement.<br />
<br />
== Packaging Issues ==<br />
<br />
=== Divergence from Primary Architectures ===<br />
Alternative architecture package trees should be as close to primary architecture package trees as possible. Alternative architectures should not use older versions and must not use customized (hacked up) packages. Alternative architectures may include architecture specific packages where relevant (e.g. bootloaders, xorg drivers). Changes to support alternative architectures must be committed in GIT for each package.<br />
<br />
=== ExcludeArch & ExclusiveArch ===<br />
Fedora Packages should avoid using ExclusiveArch, except when absolutely correct. Only packages which are exclusively arch specific should use ExclusiveArch (e.g. a bootloader designed for only one architecture). ExcludeArch should only be set when the architecture is not relevant for the package, the package is non-functional on the architecture, or the code does not compile cleanly for the architecture.<br />
<br />
By using ExcludeArch on an arch by arch basis, it enables the majority of packages to have the chance to build on new alternative architectures, rather than being immediately ignored by a blanket ExclusiveArch. There is a process running that will notify architecture maintainers of all changes in Exclude and Exclusive Arch headers along with daily summaries of all packages with architecture specific handling<br />
<br />
=== Tracker Bugs ===<br />
Any packager which sets ExcludeArch for an architecture must open a bug against that package, and block that bug against the appropriate ExcludeArch blocker bug.<br />
<br />
This will help the Alternative Architecture team track and fix packages for their architecture.</div>Ausilhttps://fedoraproject.org/w/index.php?title=Architectures&diff=485721Architectures2017-02-08T20:40:52Z<p>Ausil: </p>
<hr />
<div>= Fedora Architectures =<br />
<br />
'''Author:''' [[TomCallaway| Tom 'spot' Callaway]], others <BR><br />
<br />
<br />
<br />
<br />
== Structure ==<br />
There are two tiers of architectures with Fedora support:<br />
* [[PrimaryArchitectures| Primary Architectures]] : These are architectures with the majority of the users, the most common architectures. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd).<br />
* [[TomCallaway/SecondaryArchitectures| Secondary Architectures]] : These are architectures with motivated Architecture Maintainer Teams, and build hardware. Build failures on secondary architectures are not fatal: if packages successfully build for the primary architectures, they push independently of any secondary architecture build successes or failures.<br />
<br />
{{Anchor|PrimaryArchitectures}}<br />
=== Primary Architectures ===<br />
* [[Architectures/ARM|ARM]]-hfp (32-bit, little-endian, hfp for ARMv7->) (as of Fedora 20)<br />
* x86 (32-bit for i686->) (until Fedora 25)<br />
* [[Architectures/x86-64|x86_64]] (64-bit)<br />
{{Anchor|SecondaryArchitectures}}<br />
<br />
=== Alternative Architectures ===<br />
* <strike>[[Architectures/ARM|ARM]]-sfp (32-bit, little-endian, sfp for ARMv5->)</strike><br />
* ARM [[Architectures/AArch64|AArch64]] (64-bit, little-endian for ARMv8->)<br />
* <strike>[[Architectures/IA64|IA64]]</strike><br />
* [[Architectures/MIPS|MIPS]]-64el (mips64r2, little endian, n64 ABI)<br />
* [[Architectures/MIPS|MIPS]]-el (mips32r2, little endian, o32 ABI)<br />
* <strike>[[Architectures/MIPS|MIPS]]-n32el (mips64r2, little endian, n32 ABI)</strike><br />
* <strike>[[Architectures/Parisc|Parisc]]</strike><br />
* <strike>[[Architectures/PowerPC|PowerPC]] (32-bit)</strike><br />
* [[Architectures/PowerPC|PowerPC64]] (64-bit, big-endian for POWER5->)<br />
* [[Architectures/PowerPC|PowerPC64le]] (64-bit, little-endian for POWER8->)<br />
* [[Architectures/RISC-V|RISC-V]] (64-bit open source ISA)<br />
* [[Architectures/s390x|s390x]] (64-bit for z10->)<br />
* <strike>[[Architectures/SPARC|SPARC]] (32-bit)</strike><br />
* <strike>[[Architectures/SPARC|SPARC64]] (64-bit for sun4u->)</strike><br />
* x86 (32-bit for i686->) (as of Fedora 26)<br />
<br />
{{Anchor|Architecture Maintainer Teams}}<br />
<br />
== Architecture Maintainer Teams ==<br />
<br />
In order to manage and support secondary architectures, each secondary architecture will have a team responsible for the Fedora release on that architecture. Each team will assign a team lead. <br />
<br />
=== Architecture Maintainer Team Responsibilities ===<br />
<br />
* Receiving notifications of secondary arch build successes and failures<br />
* Patching packages cleanly such that they build and function correctly on the secondary architecture, with a minimal amount of architecture conditionalization in the spec file (avoid %ifarch wherever possible). To enable this, architecture team members will have special grouped ACL access to all packages (with some exceptions, such as, glibc, kernel, anaconda), permitting them special access to make changes. This ability requires a great amount of respect, and secondary architecture maintainers are expected to be extremely careful when modifying packages. With special access comes extra responsibility. Think before you commit. Consult the package maintainer before making a change, no matter how trivial.<br />
* Resolving architecture specific bugs filed against packages<br />
* Holding regular status meetings on IRC for the architecture<br />
* Meeting target dates for architecture stability, freezes, release candidates, and releases. If unable to meet target dates, release does not occur. Target dates for secondary architectures will be slightly farther out than the target dates for primary architectures, allowing for longer build times and architecture fixes for packages frozen for primary architectures. If a secondary architecture fails to make release goals for two consecutive Fedora releases, the architecture will be re-evaluated by FESCo.<br />
* Maintaining and hosting the buildserver(s) and storage for that architecture<br />
* Composing trees for that architecture<br />
* Maintain a section on the fedoraproject.org wiki for the architecture, documenting the effort, the maintainer team, the meeting schedule, and other useful information for users, packagers, and developers.<br />
* Deliver progress reports to FESCo on a monthly basis<br />
<br />
Each secondary architecture maintainer team will have a dedicated mailing list (e.g. fedora-sparc-list) to serve as a contact point for architecture specific questions, bug notifications, build notifications, etc.<br />
<br />
There is a generic secondary arch list at [https://admin.fedoraproject.org/mailman/listinfo/secondary secondary@lists.fedoraproject.org] one or more team members should subscribe here.<br />
<br />
In addition, secondary architecture teams '''should''' do the following:<br />
* Run regular 'rebuild all in mock' runs (usually requires dedicated system)<br />
<br />
== Logistics ==<br />
<br />
=== Buildsystems ===<br />
Secondary architectures will need to provide their own hardware, to act as build servers for the koji buildsystem. Neither Red Hat nor the Fedora Project is able to provide hosting space for Secondary architecture systems at this time. Secondary Architecture koji buildsystems need to be accessible via the internet, so that they can communicate with the primary Fedora koji infrastructure and be accessed by all fedora contributors. All builds have to happen in a native environment. this means cross compiling is not allowed, you can however use virtualisation to emulate your target system.<br />
<br />
=== File Storage ===<br />
Secondary architectures will need to provide their own file storage for the buildsystem, composed trees will be hosted at http://secondary.fedoraproject.org/pub/fedora-secondary. Fedora mirrors can choose whether they wish to mirror secondary architecture trees on an arch-by-arch basis.<br />
<br />
=== Tree Composition ===<br />
Fedora Release Engineering will not have any responsibility for composing Secondary Architecture trees. Composing trees and install media is the responsibility of the Secondary Architecture team. Each team should expect to have a dedicated server for compose purposes (if possible).<br />
<br />
=== Sandbox Systems ===<br />
Secondary architecture teams are encouraged to make a "sandbox", or testing system publicly available for Fedora packagers. It is possible to configure a system so that only Fedora Account System users with packager access can ssh into the box, using their FAS credentials.<br />
<br />
'''***TODO***''' Document how to set this up.<br />
<br />
While sandbox systems are very useful for Fedora packagers who would not normally have access to the hardware architecture, they are not a requirement.<br />
<br />
== Packaging Issues ==<br />
<br />
=== Divergence from Primary Architectures ===<br />
Secondary architecture package trees should be as close to primary architecture package trees as possible. Secondary architectures should not use older versions or customized (hacked up) packages. Secondary architectures may include architecture specific packages where relevant (e.g. bootloaders, xorg drivers). Changes to support secondary architectures must be committed in GIT for each package.<br />
<br />
=== ExcludeArch & ExclusiveArch ===<br />
Fedora Packages should avoid using ExclusiveArch, except when absolutely correct. Only packages which are exclusively arch specific should use ExclusiveArch (e.g. a bootloader designed for only one architecture). ExcludeArch should only be set when the architecture is not relevant for the package, the package is non-functional on the architecture, or the code does not compile cleanly for the architecture.<br />
<br />
By using ExcludeArch on an arch by arch basis, it enables the majority of packages to have the chance to build on new secondary architectures, rather than being immediately ignored by a blanket ExclusiveArch.<br />
<br />
=== Tracker Bugs ===<br />
Any packager which sets ExcludeArch for an architecture must open a bug against that package, and block that bug against the appropriate ExcludeArch blocker bug.<br />
<br />
This will help the Secondary Architecture team track and fix packages for their architecture.</div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/NoMoreAlpha&diff=485669Changes/NoMoreAlpha2017-02-07T22:06:03Z<p>Ausil: /* Dependencies */</p>
<hr />
<div><!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= No More Alphas <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Fedora will no longer produce Alpha releases.<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:Ausil| Dennis Gilmore]], [[User:Adamwill| Adam Williamson]]<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: dennis@ausil.us, awilliam@redhat.com<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/27 | Fedora 27 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
By adding CI and gating on Rawhide we will enable rawhide to be more stable and generally useful to people as a daily driver. As a result rawhide should always be at alpha quality, by keeping Rawhide always at Alpha quality we will be no longer need to do Alpha releases.<br />
<br />
== Benefit to Fedora ==<br />
<br />
<br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners:<br />
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--><br />
<br />
* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--><br />
<br />
* Release engineering: [https://pagure.io/releng/issue/6621 #6621] <br />
<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: This change removes a milestone and all associated deliverables <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings --><br />
<br />
* Policies and guidelines: As there is no more Alpha we will need to update the guidelines to have changes be completed for Beta. We may want to add a new checkpoint for basic testability of changes <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --><br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. --><br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
There will be no change to existing systems.<br />
<br />
== How To Test ==<br />
<br />
See that there is no Alpha release any longer <br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
Rawhide will be more stable<br />
<br />
== Dependencies ==<br />
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --><br />
<br />
QA to have tests to detect when a new build breaks dependencies.<br />
releng to make changes to tagging in koji<br />
a tool to move builds from -pending into rawhide when it passes its tests<br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
Reinstate Alpha milestone and release. we will know if we are on target a few weeks before when Alpha would have been.<br />
<br />
== Documentation ==<br />
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --><br />
<br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SelfContainedChange]]<br />
<!-- [[Category:SystemWideChange]] --></div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/NoMoreAlpha&diff=485668Changes/NoMoreAlpha2017-02-07T21:56:53Z<p>Ausil: </p>
<hr />
<div><!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= No More Alphas <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Fedora will no longer produce Alpha releases.<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:Ausil| Dennis Gilmore]], [[User:Adamwill| Adam Williamson]]<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: dennis@ausil.us, awilliam@redhat.com<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/27 | Fedora 27 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
By adding CI and gating on Rawhide we will enable rawhide to be more stable and generally useful to people as a daily driver. As a result rawhide should always be at alpha quality, by keeping Rawhide always at Alpha quality we will be no longer need to do Alpha releases.<br />
<br />
== Benefit to Fedora ==<br />
<br />
<br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners:<br />
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--><br />
<br />
* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--><br />
<br />
* Release engineering: [https://pagure.io/releng/issue/6621 #6621] <br />
<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: This change removes a milestone and all associated deliverables <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings --><br />
<br />
* Policies and guidelines: As there is no more Alpha we will need to update the guidelines to have changes be completed for Beta. We may want to add a new checkpoint for basic testability of changes <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --><br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. --><br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
There will be no change to existing systems.<br />
<br />
== How To Test ==<br />
<br />
See that there is no Alpha release any longer <br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
Rawhide will be more stable<br />
<br />
== Dependencies ==<br />
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --><br />
<br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
Reinstate Alpha milestone and release. we will know if we are on target a few weeks before when Alpha would have been.<br />
<br />
== Documentation ==<br />
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --><br />
<br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SelfContainedChange]]<br />
<!-- [[Category:SystemWideChange]] --></div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/NoMoreAlpha&diff=485667Changes/NoMoreAlpha2017-02-07T21:42:33Z<p>Ausil: </p>
<hr />
<div><!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= No More Alphas <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
Fedora will no longer produce Alpha releases.<br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:Ausil| Dennis Gilmore]]<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: dennis@ausil.us<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/27 | Fedora 27 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
By adding CI and gating on Rawhide we will enable <br />
== Benefit to Fedora ==<br />
<br />
<br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners:<br />
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--><br />
<br />
* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--><br />
<br />
* Release engineering: [https://pagure.io/releng/issue/6621 #6621] <br />
<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: This change removes a milestone and all associated deliverables <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings --><br />
<br />
* Policies and guidelines: As there is no more Alpha we will need to update the guidelines to have changes be completed for Beta. We may want to add a new checkpoint for basic testability of changes <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --><br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. --><br />
<br />
== Upgrade/compatibility impact ==<br />
<br />
There will be no change to existing systems.<br />
<br />
== How To Test ==<br />
<br />
See that there is no Alpha release any longer <br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
Rawhide will be more stable<br />
<br />
== Dependencies ==<br />
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --><br />
<br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
Reinstate Alpha milestone and release. we will know if we are on target a few weeks before when Alpha would have been.<br />
<br />
== Documentation ==<br />
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --><br />
<br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SelfContainedChange]]<br />
<!-- [[Category:SystemWideChange]] --></div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/NoMoreAlpha&diff=485666Changes/NoMoreAlpha2017-02-07T21:34:42Z<p>Ausil: add template since I lost everything once already :(</p>
<hr />
<div>{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}<br />
<br />
<!-- Self Contained or System Wide Change Proposal?<br />
Use this guide to determine to which category your proposed change belongs to.<br />
<br />
Self Contained Changes are:<br />
* changes to isolated/leaf package without the impact on other packages/rest of the distribution<br />
* limited scope changes without the impact on other packages/rest of the distribution<br />
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG<br />
<br />
System Wide Changes are:<br />
* changes that does not fit Self Contained Changes category touching <br />
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)<br />
* changing system defaults<br />
<br />
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is <br />
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). <br />
<br />
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.<br />
--><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
<br />
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --><br />
= Change Proposal Name <!-- The name of your change proposal --> =<br />
<br />
== Summary ==<br />
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --><br />
<br />
== Owner ==<br />
<!-- <br />
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages. <br />
This should link to your home wiki page so we know who you are. <br />
--><br />
* Name: [[User:FASAcountName| Your Name]]<br />
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --><br />
* Email: <your email address so we can contact you, invite you to meetings, etc.><br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/<number> | Fedora <number> ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --><br />
<br />
== Benefit to Fedora ==<br />
<br />
<br />
<br />
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--><br />
<br />
== Scope ==<br />
* Proposal owners:<br />
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--><br />
<br />
* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--><br />
<br />
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engeneering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES --><br />
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuid required? include a link to the releng issue. <br />
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --><br />
<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings --><br />
<br />
* Policies and guidelines: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --><br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. --><br />
<br />
== Upgrade/compatibility impact ==<br />
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --><br />
<br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== How To Test ==<br />
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. <br />
<br />
Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.<br />
<br />
A good "how to test" should answer these four questions:<br />
<br />
0. What special hardware / data / etc. is needed (if any)?<br />
1. How do I prepare my system to test this change? What packages<br />
need to be installed, config files edited, etc.?<br />
2. What specific actions do I perform to check that the change is<br />
working like it's supposed to?<br />
3. What are the expected results of those actions?<br />
--><br />
<br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== User Experience ==<br />
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --><br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Dependencies ==<br />
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --><br />
<br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Contingency Plan ==<br />
<br />
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --><br />
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --><br />
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --><br />
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next --><br />
<br />
== Documentation ==<br />
<!-- Is there upstream documentation on this change, or notes you have written yourself? Link to that material here so other interested developers can get involved. --><br />
<br />
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
N/A (not a System Wide Change) <br />
<br />
== Release Notes ==<br />
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --><br />
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. <br />
<br />
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. <br />
--><br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SelfContainedChange]]<br />
<!-- [[Category:SystemWideChange]] --></div>Ausilhttps://fedoraproject.org/w/index.php?title=Changes/Policy&diff=485641Changes/Policy2017-02-07T16:40:13Z<p>Ausil: /* Release Engineering */ typo</p>
<hr />
<div>{{admon/tip | Quick Links | If you know the process already, you can jump immediately to [[Changes/EmptyTemplate | an empty Change Proposal form]]. Looking for help? Contact the [[Change Wrangler]].}}<br />
<br />
== Fedora Release Planning Process ==<br />
<br />
The motivation for the planning process is to raise the visibility of planned changes and make coordination and planning effort easier. Otherwise it is nearly impossible to follow all changes happening in a big project such as Fedora. It must be easy to submit the change proposal as early as possible, before the change is implemented and even in the very early state of the idea, to gather community feedback and review. <br />
<br />
The list of accepted changes, or change set, is used by different teams across the project. For example, the change set may be used to prepare external facing materials like release notes and release announcements. <br />
<br />
Change owners are trusted ''and depended upon'' to highlight all relevant changes. Not noting important changes (whether due to oversight, different opinion of importance, or intentionally) breaks the Change process. <br />
<br />
The planning process is an internal planning and tracking tool, and the final release is not required to reflect all proposed changes. <br />
<br />
== Change categories ==<br />
Fedora Engineering and Steering Committee (FESCo) defined two Change categories:<br />
# Self contained changes<br />
# Complex system wide changes<br />
<br />
=== Self contained changes ===<br />
A self contained change is a change to isolated package(s), or a general change with limited scope and impact on the rest of distribution/project. Examples include addition of a group of leaf packages, or a coordinated effort within a [[SIG]] with limited impact outside the SIG's functional area. Self contained changes could be used for early idea state proposals for wider and complex changes.<br />
<br />
Public announcement of a new self contained change promotes cooperation on the change, and extends its visibility. Change owners may find help from the community or useful comments. These changes don't have to be thoroughly reviewed by [[FESCo]]. Based on the community review, the self contained change can be updated to the complex system wide change category, and the owner may be asked to provide more details and extend the change proposal page.<br />
<br />
{{hidden|header=The process for self contained changes|content=<br />
* The owner submits the change proposal according to the change proposal submission policy.<br />
* The [[Change_Wrangler]] checks the proposed change page for formal correctness.<br />
* Once the change proposal is correct, the Wrangler announces it on the {{fplist|devel-announce}} mailing list.<br />
* '''WHO?''' advertises the change in the release notes. Other formal documentation process is optional.<br />
* The Wrangler adds the aggregated list of change proposals to the FESCo agenda no sooner than a week after the announcement on the mailing list.<br />
** In case of no complaints (possible breakage/conflicts, coordination needed) on the {{fplist|devel}} mailing list or from FESCo members, FESCo approves those change proposals without further investigation or scoping. Any team can share their views on {{fplist|devel}} and escalate a proposed change to FESCo to go through the regular complex system wide changes process. The change owner may be asked to provide more details or move the change to the "complex system wide changes" category. FESCo members are encouraged to ask questions on the mailing list instead of waiting for the meeting.<br />
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}<br />
<br />
=== Complex system wide changes ===<br />
Complex system wide changes involve system-wide defaults, critical path components, or other changes that are not eligible as self contained changes.<br />
<br />
{{hidden|header=The process for complex system wide changes|content=<br />
* The owner submits the change proposal according to the change proposal submission policy below.<br />
* The [[Change Wrangler]] checks the proposed change page for formal correctness.<br />
* Once the change proposal is correct, the Wrangler announces it on the {{fplist|devel-announce}} list.<br />
* After at least one week on the mailing list, the Wrangler sends the change to FESCo for discussion and formal approval in their meeting.<br />
** Optionally, FESCo assigns the change to one of the FESCo members or a trusted community member within the functional area (a ''change shepherd''), who follows the detailed status of the change with FESCo and helps with processes within Fedora. For example, the change shepherd may communicate high-impact aspects of the change, or point out that a buildroot will be neccessary. The shepherd follows the status of the change until final release.<br />
** Fedora QA reviews announced changes on the {{fplist|devel-announce}} list to commit to testing of the change, or adjust release criteria as necessary.<br />
* FESCo will re-review the status of complex changes one week before the [[Milestone freezes|Beta freeze]] ([[Schedule|see current schedule]]). At this time, FESCo typically decides whether to activate the contingency plan. Any change for which FESCo can't make this decision one week before beta must include a note on its Change wiki page and tracking bug.<br />
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}<br />
<br />
<br />
== Essential Communications ==<br />
<br />
=== Fedora Packaging Committee ===<br />
For changes that require modifications to the [[Packaging:Guidelines|Fedora Packaging Guidelines]]:<br />
* The person or group proposing the Change is responsible for providing a first draft of packaging guideline changes to the FPC.<br />
* This draft does not need to be prepared prior to submitting the Change request, but must be complete by Alpha Freeze or the Contingency Plan will be invoked.<br />
<br />
=== Release Engineering ===<br />
For all changes you need to file an issue in [https://pagure.io/releng/issues releng pagure] to check if your change requires Release Engineering involvement:<br />
* You must work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook.<br />
** File a ticket with Release Engineering when working on your change and link to it in your change page, with a detailed breakdown of changes needed.<br />
* Work must be substantially complete and in place by Alpha Freeze or the contingency plan will be invoked.<br />
<br />
=== Trademark Approval ===<br />
<br />
If your Change may require trademark approval (for example, if it is a new Spin), [https://fedorahosted.org/council/ file a ticket] requesting trademark approval from the [[Fedora Council]]. This approval will be done via the Council's consensus-based process; if the request receives at least three positive votes and no negative votes within an approved period, it is considered approved.<br />
<br />
For Change-related trademark approval, the Council has decided that 14 days is the normal time to reach consensus. This may be extended when it seems necessary to allow an adequate period for input.<br />
<br />
== HOWTOs ==<br />
<br />
=== For everyone ===<br />
<br />
In general, Changes are for coordination of development effort and for communication (both internally and externally). They aren't mandates that someone else implement an idea (no matter how good that idea). If you have improvement in mind, work to get implementers committed to the effort ''before'' filing a Change, rather than expecting them to show up for work once the Change is accepted — that's simply unlikely to happen and the effort will likely fail, leading to sadness and disappointment all around.<br />
<br />
=== For developers ===<br />
<br />
==== How do I propose a new change? ====<br />
In order to be considered an official change proposal accepted for the next Fedora release, the change proposal must be formally documented on a separate wiki page.<br />
# Read the policies for self contained changes and complex system wide changes mentioned above.<br />
# Pick the right category. Remember, the category can be changed to another one based on community or FESCo review!<br />
# Fill in the [[Changes/EmptyTemplate | empty change proposal form]] with all details required for selected category (see inline comments).<br />
# Once you're satisfied with the change proposal page, set the wiki page category to [[:Category:ChangeReadyForWrangler]], ''and'' set the appropriate change category -- [[:Category:SelfContainedChange]] or [[:Category:SystemWideChange]]. Both categories must be set! Also ensure that the proposal URL follows the "Changes/<proposalname>" scheme.<br />
# Make sure to finish your change proposal by the change proposal submission deadline! If you do not meet this deadline, you must seek an exception from FESCo.<br />
<br />
The [[Change_Wrangler]] is responsible for the actual announcement of the change proposal, creating the FESCo ticket and tracking bug in Bugzilla. For status tracking, see the next section.<br />
<br />
{{admon/tip | ''Change Template'' | Start with the [[Changes/EmptyTemplate | empty change proposal template]] — but don't edit it; copy its contents to a new wiki page and work from there.}}<br />
<br />
==== How is a change accepted? ====<br />
Self contained changes that pass community review (the announcement) are accepted by FESCo without further investigation in a batch, no sooner than one week after the announcement. Complex system wide changes must be accepted by FESCo individually in the weekly meeting. The scope and dependencies are thoroughly reviewed to determine influence on the other parts of Fedora. It's beneficial for the change proposal owner to be available in the FESCo ticket for the change proposal, and in the relevant FESCo meeting (announced in advance). The change proposal owner is notified when the change is accepted for inclusion in the planned release.<br />
<br />
==== How do I show the status of a change I own? ====<br />
The progress of development is shown in Bugzilla with defined bug states as explained in the change proposal template. Use this tracking bug to show blockers, using the Blocks/Depends on fields (for example package reviews), update the bug description with an actual status, and modify the bug status to reflect current state. You may be asked by the [[Change_Wrangler]] or FESCo members to provide more detailed status (specifically for complex system wide changes).<br />
<br />
A Change is considered ''code complete'' when the bug state is moved to ON_QA and when there are no blocking bugs open.<br />
<br />
==== What are the change process deadline dates (Checkpoints)? ====<br />
For specific dates refer to the current release's [[Schedule]]. For the general template of a Fedora release, to see when the Change Checkpoints relate to the rest of the cycle, see [[Fedora_Release_Life_Cycle]].<br />
<br />
===== Change Checkpoint: Proposal submission deadline (System Wide Changes) =====<br />
New change proposals may be submitted using the guidelines described elsewhere and accepted by [[FESCo]] until the ''change proposals submission deadline''. For a given release, this date falls three months before the release is [[Releases/Branched|Branched]], and will be announced well in advance. It's a strict deadline for System Wide Changes. Self Contained changes may be proposed after this deadline but we prefer developers to follow it as it helps with release planning.<br />
<br />
===== Change Checkpoint: Completion deadline =====<br />
This deadline falls on the same day as the Alpha [[Milestone freezes|milestone freeze]] (see [[Schedule]]).<br />
<br />
* New changes must be feature complete or close enough to completion by the ''Change Checkpoint: Completion deadline'' date that a majority of its functionality can be tested during the Alpha and Beta releases.<br />
* If a change proposal page specifies a change will be enabled by default, it must be so by this date.<br />
* Changes meeting the preceding bullets are considered ''testable''.<br />
* Use the MODIFIED status in the tracker bug to show the change made the change deadline and is ''testable''.<br />
{{Admon/tip | ''Testable'' | This means the change is substantially complete and can be tested when the change is not 100% completely implemented. This is an attempt to provide some flexibility without completely losing the understood meaning of a change being ''feature complete''. All new changes are tested during the Alpha and Beta releases.}}<br />
{{admon/warning| ''Cutting it close?'' | At this point, Rawhide and the immediately-upcoming "N+1" release are already separate branches. If development, testing, integration — and integration testing! — are not really all lined up by this point, there is no shame in re-targeting for the ''next'' (N+2) release. Now is the time for you to bring that to [[FESCo]]. Or, if this change is time-sensitive but needs more resources or attention from across the community, bring ''that'' to FESCo, to the Fedora [[Council]], and to the Fedora community at large.}}<br />
<br />
===== Change Checkpoint: 100% code complete deadline =====<br />
This date falls on the same day as the [[Schedule|Beta Freeze]].<br />
<br />
* New accepted changes must be ''code complete'', meaning '''all''' the code required to ''enable'' to the new change is finished.<br />
* The level of ''code completeness'' is reflected as tracker bug state ON_QA. The change does not have to be fully tested by this deadline.<br />
<br />
{{admon/note|Relationship to milestone freezes|Change Checkpoint: 100% code complete deadline coincides with the [[Milestone freezes|Beta Freeze]] date because that is the last date on which it can be ensured that a build will appear in a milestone release. The idea is really that these requirements be met in the Beta ''release'', but due to the nature of the milestone freezes, in order to ensure this is the case, the requirements must be met by the freeze date.}}<br />
<br />
<!--<br />
=== For documentation team ===<br />
<br />
=== For marketing team ===<br />
--><br />
<br />
== FAQs ==<br />
Feel free to ask the [[Change_Wrangler]] for help.</div>Ausil