Fedora Rawhide-20160309.n.2 compose check report
Missing expected images: Atomic raw-xz x86_64 Kde raw-xz armhfp Images in this compose but not Rawhide-20160308.n.0: Cloud vagrant-libvirt x86_64 Cloud vagrant-virtualbox x86_64 Cloud raw-xz i386 Cloud vagrant-virtualbox i386 Cloud vagrant-libvirt i386 Cloud qcow2 i386 Cloud qcow2 x86_64 Cloud raw-xz x86_64 No images in Rawhide-20160308.n.0 but not this. Failed openQA tests: 62 of 78 ID: 8378Test: i386 universal package_set_kde URL: https://openqa.fedoraproject.org/tests/8378 ID: 8377Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/8377 ID: 8376Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/8376 ID: 8375Test: i386 universal server_lvmthin URL: https://openqa.fedoraproject.org/tests/8375 ID: 8374Test: i386 universal server_ext3 URL: https://openqa.fedoraproject.org/tests/8374 ID: 8373Test: i386 universal server_btrfs URL: https://openqa.fedoraproject.org/tests/8373 ID: 8372Test: i386 universal server_software_raid URL: https://openqa.fedoraproject.org/tests/8372 ID: 8371Test: i386 universal server_simple_encrypted URL: https://openqa.fedoraproject.org/tests/8371 ID: 8370Test: i386 universal server_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/8370 ID: 8369Test: i386 universal server_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/8369 ID: 8368Test: i386 universal package_set_minimal URL: https://openqa.fedoraproject.org/tests/8368 ID: 8367Test: x86_64 universal european_language_install URL: https://openqa.fedoraproject.org/tests/8367 ID: 8366Test: x86_64 universal server_shrink_ntfs URL: https://openqa.fedoraproject.org/tests/8366 ID: 8365Test: x86_64 universal server_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/8365 ID: 8364Test: x86_64 universal server_updates_img_local URL: https://openqa.fedoraproject.org/tests/8364 ID: 8363Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/8363 ID: 8361Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/8361 ID: 8358Test: x86_64 universal server_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/8358 ID: 8357Test: x86_64 universal server_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/8357 ID: 8356Test: x86_64 universal server_xfs@uefi URL: https://openqa.fedoraproject.org/tests/8356 ID: 8355Test: x86_64 universal server_ext3@uefi URL: https://openqa.fedoraproject.org/tests/8355 ID: 8354Test: x86_64 universal server_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/8354 ID: 8353Test: x86_64 universal server_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/8353 ID: 8352Test: x86_64 universal server_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/8352 ID: 8351Test: x86_64 universal server_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/8351 ID: 8350Test: x86_64 universal server_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/8350 ID: 8349Test: x86_64 universal server_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/8349 ID: 8348Test: x86_64 universal package_set_kde URL: https://openqa.fedoraproject.org/tests/8348 ID: 8347Test: x86_64 universal server_no_swap URL: https://openqa.fedoraproject.org/tests/8347 ID: 8346Test: x86_64 universal server_lvmthin URL: https://openqa.fedoraproject.org/tests/8346 ID: 8345Test: x86_64 universal server_xfs URL: https://openqa.fedoraproject.org/tests/8345 ID: 8344Test: x86_64 universal server_ext3 URL: https://openqa.fedoraproject.org/tests/8344 ID: 8343Test: x86_64 universal server_btrfs URL: https://openqa.fedoraproject.org/tests/8343 ID: 8342Test: x86_64 universal server_delete_partial URL: https://openqa.fedoraproject.org/tests/8342 ID: 8341Test: x86_64 universal server_software_raid URL: https://openqa.fedoraproject.org/tests/8341 ID: 8340Test: x86_64 universal server_multi_empty URL: https://openqa.fedoraproject.org/tests/8340 ID: 8339Test: x86_64 universal server_simple_free_space URL: https://openqa.fedoraproject.org/tests/8339 ID: 8338Test: x86_64 universal server_simple_encrypted URL: https://openqa.fedoraproject.org/tests/8338 ID: 8337Test: x86_64 universal server_multi@uefi URL: https://openqa.fedoraproject.org/tests/8337 ID: 8336Test: x86_64 universal server_multi URL: https://openqa.fedoraproject.org/tests/8336 ID: 8335Test: x86_64 universal server_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/8335 ID: 8333Test: x86_64 universal server_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/8333 ID: 8332Test: x86_64 universal server_delete_pata URL: https://ope
Fedora 24 updates-testing report
The following Fedora 24 Security updates need testing: Age URL 0 https://bodhi.fedoraproject.org/updates/FEDORA-2016-4b55f00d00 samba-4.4.0-0.7.rc4.fc24 0 https://bodhi.fedoraproject.org/updates/FEDORA-2016-9d6b6d0689 php-pecl-http-2.5.6-1.fc24 0 https://bodhi.fedoraproject.org/updates/FEDORA-2016-cdb5052362 python-tgcaptcha2-0.3.1-1.fc24 0 https://bodhi.fedoraproject.org/updates/FEDORA-2016-2982f06845 libotr-4.1.1-1.fc24 0 https://bodhi.fedoraproject.org/updates/FEDORA-2016-f0bb0dad51 drupal6-emfield-2.7-1.fc24 The following Fedora 24 Critical Path updates have yet to be approved: Age URL 0 https://bodhi.fedoraproject.org/updates/FEDORA-2016-d85d9ad927 anaconda-24.13.1-1.fc24 0 https://bodhi.fedoraproject.org/updates/FEDORA-2016-4b55f00d00 samba-4.4.0-0.7.rc4.fc24 0 https://bodhi.fedoraproject.org/updates/FEDORA-2016-67f816ae6b iputils-20160308-2.fc24 0 https://bodhi.fedoraproject.org/updates/FEDORA-2016-71d6f90d9b nss-3.23.0-1.2.fc24 The following builds have been pushed to Fedora 24 updates-testing 3Depict-0.0.18-6.fc24 OSGi-bundle-ant-task-0.2.0-0.15.svn1242.fc24 anaconda-24.13.1-1.fc24 ardour2-2.8.16-21.fc24 ardour4-4.7.0-2.fc24 check-mk-1.2.6p16-3.fc24 cinnamon-2.8.7-1.fc24 cinnamon-desktop-2.8.1-1.fc24 cinnamon-settings-daemon-2.8.4-1.fc24 cmake-3.5.0-1.fc24 device-mapper-persistent-data-0.6.2-0.1.rc6.fc24 drupal6-ctools-1.15-1.fc24 drupal6-emfield-2.7-1.fc24 drupal6-login_destination-2.13-1.fc24 drupal6-pathauto-2.1-1.fc24 dynaplugz-0.0.0.0-0.4.git20160309.597ce9f.fc24 eclipse-epic-0.6.57-2.fc24 eclipse-mdt-ocl-6.0.2-1.fc24 eclipse-mdt-uml2-5.1.2-1.fc24 eclipse-mpc-1.4.2-1.fc24 eclipse-pdt-3.7.0-1.fc24 eclipse-subclipse-1.10.11-2.fc24 evince-3.18.2-5.fc24 fail2ban-0.9.4-2.fc24 fasd-1.0.1-2.fc24 firebird-2.5.5.26952.0-5.fc24 fleet-commander-admin-0.7.4-1.fc24 geoclue2-2.4.3-1.fc24 gperftools-2.4.91-1.fc24 httrack-3.48.20-5.fc24 i7z-0.27.2-13.20131012git5023138.fc24 ipe-7.2.2-1.fc24 iputils-20160308-2.fc24 libblockdev-1.4-4.fc24 libbytesize-0.4-1.fc24 libfabric-1.2.0-1.fc24 libotr-4.1.1-1.fc24 libvirt-1.3.2-2.fc24 mock-1.2.16-1.fc24 mosquitto-1.4.8-1.fc24 muffin-2.8.5-1.fc24 nemo-2.8.7-1.fc24 nss-3.23.0-1.2.fc24 oggvideotools-0.8-22.fc24 openqa-4.3-19.fc24 perl-Apache-Session-Browseable-1.2-1.fc24 perl-ExtUtils-HasCompiler-0.012-1.fc24 perl-XML-XPath-1.34-1.fc24 php-horde-Horde-Core-2.23.0-1.fc24 php-horde-Horde-Crypt-2.7.1-1.fc24 php-horde-Horde-Form-2.0.13-1.fc24 php-horde-Horde-JavascriptMinify-1.1.3-1.fc24 php-horde-Horde-Mail-Autoconfig-1.0.3-1.fc24 php-horde-Horde-Perms-2.1.7-1.fc24 php-horde-Horde-Prefs-2.7.6-1.fc24 php-horde-horde-lz4-1.0.10-1.fc24 php-pecl-http-2.5.6-1.fc24 php-pecl-yaml-1.2.0-1.fc24 pmix-1.1.3-1.fc24 python-etcd-0.4.3-1.fc24 python-lazyarray-0.2.8-3.fc24 python-netaddr-0.7.18-6.fc24 python-nmrglue-0.5-3.fc24 python-pykalman-0.9.5-9.20140827git2aeb4ad.fc24 python-social-auth-0.2.14-4.fc24 python-tgcaptcha2-0.3.1-1.fc24 python3-cherrypy-5.0.1-2.fc24 qemu-2.5.0-9.fc24 rubygem-benchmark-ips-2.5.0-1.fc24 samba-4.4.0-0.7.rc4.fc24 scl-utils-2.0.1-10.fc24 starplot-0.95.5-19.fc24 traceroute-2.1.0-1.fc24 wine-1.9.5-2.fc24 wine-mono-4.6.0-1.fc24 xfce4-power-manager-1.5.2-6.fc24 Details about builds: 3Depict-0.0.18-6.fc24 (FEDORA-2016-0267f4bd6d) Valued 3D point cloud visualization and analysis Update Information: Rebuild with gsl 2.1 OSGi-bundle-ant-task-0.2.0-0.15.svn1242.fc24 (FEDORA-2016-470a0cb3e8) A wrapper around Bnd to allow easy bundle creation from ant builds Update Information: * Fix FTBFS References: [ 1 ] Bug #1307287 - OSGi-bundle-ant-task: FTBFS in rawhide https://bugzilla.redhat.com/show_bug.cgi?id=1307287 anaconda-24.13.1-1.fc24 (FEDORA-2016-d85d9ad927) Graphical system installer Update Information: Various bugfixes, some translation fixes, some s390x UI fixes, some locale fixes, some CSS fixes, and a few other misc. issues fixed. -
Fedora rawhide compose report: 20160309.n.2 changes
OLD: Fedora-Rawhide-20160308.n.0 NEW: Fedora-Rawhide-20160309.n.2 = SUMMARY = Added packages: 6 Dropped packages:1 Upgraded packages: 154 Downgraded packages: 0 Size of added packages: 1.29 MiB Size of dropped packages:433.54 KiB Size of upgraded packages: 1.63 GiB Size of downgraded packages: 0.00 B Size change of upgraded packages: -84.41 MiB Size change of downgraded packages: 0.00 B = ADDED PACKAGES = Package: oci-systemd-hook-0.1.4-1.gitde345df.fc25 Summary: OCI systemd hook for docker RPMs:oci-systemd-hook Size:90246 bytes Package: perl-ExtUtils-HasCompiler-0.012-1.fc25 Summary: Check for the presence of a compiler RPMs:perl-ExtUtils-HasCompiler Size:19554 bytes Package: pmix-1.1.3-1.fc25 Summary: Exascale version of PMI RPMs:pmix pmix-devel Size:643024 bytes Package: python-etcd-0.4.3-1.fc25 Summary: A python client library for etcd RPMs:python2-python-etcd python3-python-etcd Size:160348 bytes Package: python-notario-0.0.11-2.fc25 Summary: A dictionary validator RPMs:python2-notario python3-notario Size:153836 bytes Package: rubygem-benchmark-ips-2.5.0-1.fc25 Summary: An iterations per second enhancement to Benchmark RPMs:rubygem-benchmark-ips rubygem-benchmark-ips-doc Size:288412 bytes = DROPPED PACKAGES = Package: php-pecl-solr-1.1.1-5.fc24 Summary: Object oriented API to Apache Solr RPMs:php-pecl-solr Size:443946 bytes = UPGRADED PACKAGES = Package: 3Depict-0.0.18-6.fc25 Old package: 3Depict-0.0.18-3.fc24 Summary: Valued 3D point cloud visualization and analysis RPMs: 3Depict Size: 16713930 bytes Size change: -37496 bytes Changelog: * Wed Feb 03 2016 Fedora Release Engineering - 0.0.18-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild * Mon Feb 22 2016 Orion Poplawski - 0.0.18-5 - Rebuild for gsl 2.1 - Cleanup spec * Tue Mar 08 2016 Orion Poplawski - 0.0.18-6 - Add patch for fix compilation with gcc 6 Package: GeoIP-GeoLite-data-2016.03-1.fc25 Old package: GeoIP-GeoLite-data-2016.02-1.fc24 Summary: Free GeoLite IP geolocation country database RPMs: GeoIP-GeoLite-data GeoIP-GeoLite-data-extra Size: 25460276 bytes Size change: 837332 bytes Changelog: * Tue Mar 08 2016 Paul Howarth - 2016.03-1 - Update to March 2016 databases Package: OSGi-bundle-ant-task-0.2.0-0.15.svn1242.fc25 Old package: OSGi-bundle-ant-task-0.2.0-0.13.svn1242.fc23 Summary: A wrapper around Bnd to allow easy bundle creation from ant builds RPMs: OSGi-bundle-ant-task Size: 14278 bytes Size change: -878 bytes Changelog: * Wed Feb 03 2016 Fedora Release Engineering - 0.2.0-0.14.svn1242 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild * Fri Feb 12 2016 gil cattaneo 0.2.0-0.15.svn1242 - fix FTBFS rhbz#1307287 - introduce license macro Package: adplug-2.1-21.fc25 Old package: adplug-2.1-19.fc23 Summary: A software library for AdLib (OPL2) emulation RPMs: adplug adplug-devel Size: 801316 bytes Size change: -14668 bytes Changelog: * Wed Feb 03 2016 Fedora Release Engineering - 2.1-20 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild * Tue Mar 08 2016 Yaakov Selkowitz - 2.1-21 - Fix FTBFS with GCC 6 (#1307307) Package: american-fuzzy-lop-2.07b-1.fc25 Old package: american-fuzzy-lop-2.04b-1.fc24 Summary: Practical, instrumentation-driven fuzzer for binary formats RPMs: american-fuzzy-lop american-fuzzy-lop-clang Size: 1650468 bytes Size change: -924 bytes Changelog: * Tue Mar 08 2016 Richard W.M. Jones - 2.07b-1 - New upstream version 2.07b (RHBZ#1311776). Package: apache-commons-lang3-3.4-5.fc25 Old package: apache-commons-lang3-3.4-4.fc24 Summary: Provides a host of helper utilities for the java.lang API RPMs: apache-commons-lang3 apache-commons-lang3-javadoc Size: 900208 bytes Size change: -1660 bytes Changelog: * Wed Mar 09 2016 Michael Simacek - 3.4-5 - Fix unapplied patch Package: ardour2-2.8.16-22.fc25 Old package: ardour2-2.8.16-20.fc24 Summary: Digital Audio Workstation RPMs: ardour2 Size: 11488290 bytes Size change: 286128 bytes Changelog: * Wed Feb 03 2016 Fedora Release Engineering - 2.8.16-21 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild * Tue Mar 08 2016 Tom Callaway - 2.8.16-22 - replace non-free dmalloc.cc with a freely licensed version (bz1313285) - fix FTBFS with gcc6 (bz1307324) Package: ardour4-4.7.0-2.fc25 Old package: ardour4-4.7.0-1.fc24 Summary: Digital Audio Workstation RPMs: ardour4 ardour4-audiobackend-alsa ardour4-audiobackend-dummy ardour4-audiobackend-jack Size: 24912404 bytes Size change: -27560 bytes Changelog: * Tue Mar 08 2016 Nils Philippsen - 4.7.0-2 - determine CPU features correctly on
Fedora 24 compose report: 20160309.n.1 changes
OLD: Fedora-24-20160308.n.0 NEW: Fedora-24-20160309.n.1 = SUMMARY = Added packages: 0 Dropped packages:2 Upgraded packages: 32 Downgraded packages: 1 Size of added packages: 0.00 B Size of dropped packages:1.50 MiB Size of upgraded packages: 85.41 MiB Size of downgraded packages: 123.50 MiB Size change of upgraded packages: 1.11 MiB Size change of downgraded packages: -2.04 MiB = ADDED PACKAGES = = DROPPED PACKAGES = Package: openstack-ceilometer-2015.1.3-1.fc23 Summary: OpenStack ceilometer collector RPMs:openstack-ceilometer-alarm openstack-ceilometer-api openstack-ceilometer-central openstack-ceilometer-collector openstack-ceilometer-common openstack-ceilometer-compute openstack-ceilometer-ipmi openstack-ceilometer-notification openstack-ceilometer-polling python-ceilometer Size:1299444 bytes Package: openstack-tuskar-0.4.15-3.fc23 Summary: A service for managing OpenStack deployments RPMs:openstack-tuskar Size:269516 bytes = UPGRADED PACKAGES = Package: GeoIP-GeoLite-data-2016.03-1.fc24 Old package: GeoIP-GeoLite-data-2016.02-1.fc24 Summary: Free GeoLite IP geolocation country database RPMs: GeoIP-GeoLite-data GeoIP-GeoLite-data-extra Size: 25462488 bytes Size change: 839544 bytes Changelog: * Tue Mar 08 2016 Paul Howarth - 2016.03-1 - Update to March 2016 databases Package: adplug-2.1-21.fc24 Old package: adplug-2.1-19.fc23 Summary: A software library for AdLib (OPL2) emulation RPMs: adplug adplug-devel Size: 807964 bytes Size change: -8020 bytes Changelog: * Wed Feb 03 2016 Fedora Release Engineering - 2.1-20 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild * Tue Mar 08 2016 Yaakov Selkowitz - 2.1-21 - Fix FTBFS with GCC 6 (#1307307) Package: dnsdist-1.0.0-0.9.alpha2.fc24 Old package: dnsdist-1.0.0-0.8.alpha2.fc24 Summary: Highly DNS-, DoS- and abuse-aware loadbalancer RPMs: dnsdist Size: 2075502 bytes Size change: -1168 bytes Changelog: * Tue Mar 08 2016 Ruben Kerkhof 1.0.0-0.9.alpha2 - Rebuild for libsodium soname bump Package: fedora-release-24-0.14 Old package: fedora-release-24-0.11 Summary: Fedora release files RPMs: fedora-release fedora-release-atomichost fedora-release-cloud fedora-release-server fedora-release-workstation Added RPMs: fedora-release-atomichost Size: 117910 bytes Size change: 61058 bytes Changelog: * Mon Feb 29 2016 Stephen Gallagher - 24-0.12 - Only run grub2-mkconfig for platforms that support it - Remove erroneous RPM_BUILD_ROOT variables in convert-to-edition * Thu Mar 03 2016 Stephen Gallagher - 24-0.13 - Rewrite scriptlets in Lua to avoid a circular dependency on coreutils - Be more specific with fedora-release-server's Cockpit requirement (Do not pull in all of the optional Cockpit components as mandatory) * Tue Mar 08 2016 Stephen Gallagher - 24-0.14 - Add a subpackage for Atomic Host to provide /usr/lib/os-release differences Package: gdb-7.11-59.fc24 Old package: gdb-7.11-58.fc24 Summary: A GNU source-level debugger for C, C++, Fortran, Go and other languages RPMs: gdb gdb-doc gdb-gdbserver Size: 14846046 bytes Size change: -39944 bytes Changelog: * Tue Mar 08 2016 Jan Kratochvil - 7.11-59.fc24 - Fix strict-aliasing rules compilation error (RH BZ 1315191). Package: gfal2-2.11.0-1.fc24 Old package: gfal2-2.10.3-2.fc24 Summary: Grid file access library 2.0 RPMs: gfal2 gfal2-all gfal2-devel gfal2-doc gfal2-plugin-dcap gfal2-plugin-file gfal2-plugin-gridftp gfal2-plugin-http gfal2-plugin-lfc gfal2-plugin-rfio gfal2-plugin-srm gfal2-plugin-xrootd Size: 1501560 bytes Size change: 13896 bytes Changelog: * Mon Mar 07 2016 Alejandro Alvarez Ayllon - 2.11.0-1 - Upgraded to upstream release 2.11.0 Package: gfal2-python-1.8.4-4.fc24 Old package: gfal2-python-1.8.4-3.fc24 Summary: Python bindings for gfal 2 RPMs: gfal2-python gfal2-python-doc Size: 365080 bytes Size change: 2020 bytes Changelog: * Tue Mar 08 2016 Alejandro Alvarez - 1.8.4-4 - Add patch to work with newer versions of Boost Package: gfal2-util-1.3.2-1.fc24 Old package: gfal2-util-1.3.1-1.fc24 Summary: GFAL2 utility tools RPMs: gfal2-util Size: 68634 bytes Size change: 512 bytes Changelog: * Wed Feb 03 2016 Fedora Release Engineering - 1.3.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild * Tue Mar 08 2016 Alejandro Alvarez - 1.3.2-1 - Update for new upstream 1.3.2 release Package: ghc-ltk-0.15.0.5-1.fc24 Old package: ghc-ltk-0.14.3.0-4.fc24 Summary: Leksah tool kit RPMs: ghc-ltk ghc-ltk-devel Size: 4526412 bytes Size change: 49392 bytes Changelog: * Mon Mar 07 2016 Jens Petersen - 0.15.0.5-1 - update to 0.15.0.5 Package: htop-2.
Re: Pungi 4 milestone builds: proposals
On Wed, 2016-03-09 at 13:57 -0700, Chris Murphy wrote: > > So if "RC-1.8" passes all tests and is a go, how is this renamed? Or > is it not renamed? > I assume you don't want to do a production compose at this point > because then it's a compose that isn't tested, while ostensibly > identical the process has any number of non-deterministic aspects to > it, right? If so, is there an foreseen consequence of just renaming > the filename of the ISOs? Or does the final distributed ISO need to > retain the "RC-1.8" add-on? I believe Dennis' position is that the RC is *exactly what we ship* - we don't rebuild or rename the images. We just sync the entire tree exactly as is into the release location. So it wouldn't be a directory called '24-RC-1.8' or whatever any more, but the image filenames and volume labels would still contain that identifier, if they originally did. > It's sort of a minor point. There are build artifacts now as a single > digit since I think Fedora 20, that don't mean anything to the outside > world (e.g. for workstation it's 21-5, 22-3, 23-10 for the past three > releases). But I don't think they hurt anything really, so if this > RC-1.8 add-on is in the distributed ISO, it's only very slightly > crusty. Right, exactly. -- Adam WilliamsonFedora QA Community MonkeyIRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . nethttp://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Pungi 4 milestone builds: proposals
On Wed, 2016-03-09 at 13:52 -0500, John Dulaney wrote: > > == 2. N indicates TC/RC, R indicates number == > > > > > > > > In this scheme, we'd build e.g. 'Alpha 1.1' (Alpha TC1), 'Alpha > > > > 1.2' > > > > (Alpha TC2), 'Alpha 2.1' (Alpha RC1), 'Alpha 2.2' (Alpha RC2). > > > > > > > > This seems like the closest possible way to map to our current > > > > system. > > > > Again it's a bit weird at Final because there is no 'Final' > > > > milestone, > > > > only 'RC', so 'RC1.1' would be 'TC1' and 'RC2.1' would be > > > > 'RC1', which > > > > is kinda strange; again we could add a 'Final' milestone to > > > > Pungi, I > > > > guess. > > > > > > > > I'm just not sure, as per 1), if we really *need* to maintain > > > > the TC/RC > > > > distinction at least in terms of how the composes are labelled > > > > and > > > > distributed. > > > > > > > I'm a fan of this approach, personally. > > With weirdly-named RCs, or by adding a 'Final' milestone to Pungi? > > With Alpha 1.1' (Alpha TC1), 'Alpha 1.2' (Alpha TC2), etc. My question was what you thought about the awkward 'Final' case, where there is currently no 'Final' milestone (only 'RC'). > The modification I would suggest, however, is that instead of RC2.x > for Final, > simply start doing 'Production' builds. If a particular production > build passes, > then that's what we ship as final. I don't think you quite get the Pungi requirements here. Pungi has three compose types, 'nightly', 'test', 'and 'production'. All milestone builds would be expected to be 'production' builds - that is all TCs and RCs for all milestones, Alpha Beta and Final. All 'production' composes are, I believe, required to specify a milestone, it cannot be omitted. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Pungi 4 milestone builds: proposals
On Wed, 2016-03-09 at 13:47 -0700, Chris Murphy wrote: > a. Work with Pungi's currently-expected label format > In this format option, MILESTONE-N.R would be > MILESTONE= alpha, beta, RC > N = arbitrary integer > R = arbitrary integer > > Can N and R be 0? Or must it be 1-9? At least according to the regex that tests their validity, they can be 0, yes. > At least from the test side, I'm not thinking there was ever a > meaningful distinction between TC and RC for alpha and beta. Right, this is my take on it too. The *definition* is clear enough: it's only an RC if it happens after the freeze *and* there are no outstanding blockers *and* releng flipped any necessary switches for 'release' behaviour. There's also a distinction in terms of the content of the compose: for an RC compose, the filenames and volume labels are supposed to be in the form of the 'final' release, whereas for TCs, the filenames and volume labels are supposed to indicate TC-ness. But so far as the actual test process goes, I don't think there's any need to distinguish them. Of course when it comes to Go/No-Go time we need to be sure the thing we're going-or-not-going-with meets all the 'RC' requirements, but it doesn't have to be explicitly labelled an 'RC' for that purpose, I don't think. For Pungi 4 I'm assuming the 'label' winds up in the image filenames and volume labels, though I haven't explicitly checked that. So I suppose if we went with a scheme that didn't distinguish between a TC and an RC, you couldn't tell just from looking at some random image's filename or volume label whether it was a TC or RC. But the value of this has always seemed quite small to me, since you also can't tell an earlier RC from the final release in this way; if you just have an image called 'Fedora 24' you don't know if it's actually the final release, or an earlier RC of the final release. The TC/RC naming was pretty much done for human consumption, but I'm not sure it really does much for us. > For > final, I vaguely think TCs and RCs did change behavior in some ways, > maybe it was disabling u-t by default? Or maybe some installer > labeling or warning goes away? Aside from the image naming, the primary difference is that the 'betanag' warning - the Timbuktu screen in the installer - is disabled. The point where we disable updates-testing by default is actually independent of the compose process, I think. > If you want to keep some granularity to distinguish between TC/RC you > could use N=0 to indicate "TC" and N=1 to indicate "RC". :-P Hmm, yeah, I like that more than 1 and 2 if we're gonna go that path, now you suggest it. 0 makes clear that this is something a bit different, and it lets us use '1' as the number for the solitary actual milestone release, which is natural. > TC's > alpha-0.1 > alpha-0.2 > alpha-0.3 > alpha-0.4 > beta-0.1 > beta-0.2 > beta-0.3 > RC-0.1 > RC-0.2 > > legit RC's > alpha-1.1 > alpha-1.2 > alpha-1.3 > alpha-1.4 > beta-1.1 > beta-1.2 > beta-1.3 > RC-1.1 > RC-1.2 I think this still works a bit better if we add a 'Final' milestone rather than using the 'RC' milestone, but yeah, this isn't bad. Dennis, WDYT? I know releng has kinda treated Final a bit differently in the past; they basically left out all milestone-y indicators in Final builds (so they went into directories like 23_TC1 or 23_RC1, for instance, not 23_Final_TC1 and 23_Final_RC1, and the string 'Final' does not appear in their filenames or volume IDs). But I don't think Pungi 4 really allows for that, unless I'm missing something, production builds are required to have some kind of milestone identifier, so the question is only do we use the 'RC' milestone or add a new one, I guess. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Pungi 4 milestone builds: proposals
On Wed, Mar 9, 2016 at 1:47 PM, Chris Murphy wrote: > On Wed, Mar 9, 2016 at 11:16 AM, Adam Williamson > wrote: >> Hi folks! >> >> So we're now frozen for Alpha and we have an anaconda build with >> blocker fixes in updates-testing...I guess this means it's a good time >> to decide what to do about milestone builds with Pungi 4. :) >> >> I'm assuming here that we're going to use more or less the same "TCs >> and RCs" approach for F24 and just try to adapt it to Pungi 4. It seems >> a bit late to make radical changes to the process itself at this point. >> >> I have a couple of ideas. I'm gonna recap, briefly, what (as I >> understand it) Pungi 4 expects us to do for milestone builds: >> >> We're expected to run 'pungi-koji --label foo', where 'foo' is a >> compose 'label' in Pungi's expected format. AIUI, this is the format >> Pungi expects for a compose 'label': >> >> MILESTONE-N.R >> >> where MILESTONE is the milestone (there is a list of valid milestones; >> for our purposes we're likely to use Alpha, Beta and RC), 'N' is the >> release number, and 'R' is a respin number. Both N and R have to be >> integers (though they can have multiple digits; Alpha-11.23 would be a >> valid label). >> >> Fedora does not do numbered milestone releases; we just have Alpha, >> Beta and Final. RHEL does, which is why the label format has 'N'. In >> the RHEL process, as I understand it, they build "Alpha-1.1", then if >> it passes whatever requirements are needed for an "Alpha 1" release, >> they ship it as Alpha 1; otherwise they build "Alpha-1.2" and ship that >> if it passes, etc etc. The "respin" value is considered "private", and >> respins are used for about the same purpose we use TCs/RCs. >> >> It *is* possible to do a 'production' compose with no label, I believe, >> by calling 'pungi-koji --no-label'. It would *also* be technically >> possible to add new label formats to Pungi. So we do have three options >> at the high level: >> >> a. Work with Pungi's currently-expected label format > > In this format option, MILESTONE-N.R would be > MILESTONE= alpha, beta, RC > N = arbitrary integer > R = arbitrary integer > > Can N and R be 0? Or must it be 1-9? > >> So we could >> instead lock down R and only increment N, so we'd do 'RC 1.1', 'RC >> 2.1', 'RC 3.1' and so on. > > To reduce granularity, lock down either N or R. But if locked down, I > suggest a value of 0 rather than 1 to indicate nullification. > > >> The build called 'RC 1.1' would likely not >> really be a "real" RC (in the sense it'd happen while we were not >> frozen and not have all blocker bugs fixed), but that's not horrible. I >> suppose we could relatively easily add 'Final' to Pungi's list of >> milestones too, if we wanted (or 'TC', come to that). > > At least from the test side, I'm not thinking there was ever a > meaningful distinction between TC and RC for alpha and beta. For > final, I vaguely think TCs and RCs did change behavior in some ways, > maybe it was disabling u-t by default? Or maybe some installer > labeling or warning goes away? > > If you want to keep some granularity to distinguish between TC/RC you > could use N=0 to indicate "TC" and N=1 to indicate "RC". :-P > > TC's > alpha-0.1 > alpha-0.2 > alpha-0.3 > alpha-0.4 > beta-0.1 > beta-0.2 > beta-0.3 > RC-0.1 > RC-0.2 > > legit RC's > alpha-1.1 > alpha-1.2 > alpha-1.3 > alpha-1.4 > beta-1.1 > beta-1.2 > beta-1.3 > RC-1.1 > RC-1.2 > > Further, if there is no meaningful distinction between TC/RC during > alpha and beta, then those would always be N=1. You'd only nullify > "RC" with a trailing 0 for the final TC's. > > > -- > Chris Murphy So if "RC-1.8" passes all tests and is a go, how is this renamed? Or is it not renamed? I assume you don't want to do a production compose at this point because then it's a compose that isn't tested, while ostensibly identical the process has any number of non-deterministic aspects to it, right? If so, is there an foreseen consequence of just renaming the filename of the ISOs? Or does the final distributed ISO need to retain the "RC-1.8" add-on? It's sort of a minor point. There are build artifacts now as a single digit since I think Fedora 20, that don't mean anything to the outside world (e.g. for workstation it's 21-5, 22-3, 23-10 for the past three releases). But I don't think they hurt anything really, so if this RC-1.8 add-on is in the distributed ISO, it's only very slightly crusty. But compare this to how Windows eval downloads are named: 9600.17050.WINBLUE_REFRESH.140317-1640_X64FRE_ENTERPRISE_EVAL_EN-US-IR3_CENA_X64FREE_EN-US_DV9.ISO 10586.0.151029-1700.TH2_RELEASE_CLIENTENTERPRISEEVAL_OEMRET_X64FRE_EN-US.ISO So yea, that's pretty terrible. One of those is Windows 8 the other Windows 10. But the world continues to function. -- Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Pungi 4 milestone builds: proposals
On Wed, Mar 9, 2016 at 11:16 AM, Adam Williamson wrote: > Hi folks! > > So we're now frozen for Alpha and we have an anaconda build with > blocker fixes in updates-testing...I guess this means it's a good time > to decide what to do about milestone builds with Pungi 4. :) > > I'm assuming here that we're going to use more or less the same "TCs > and RCs" approach for F24 and just try to adapt it to Pungi 4. It seems > a bit late to make radical changes to the process itself at this point. > > I have a couple of ideas. I'm gonna recap, briefly, what (as I > understand it) Pungi 4 expects us to do for milestone builds: > > We're expected to run 'pungi-koji --label foo', where 'foo' is a > compose 'label' in Pungi's expected format. AIUI, this is the format > Pungi expects for a compose 'label': > > MILESTONE-N.R > > where MILESTONE is the milestone (there is a list of valid milestones; > for our purposes we're likely to use Alpha, Beta and RC), 'N' is the > release number, and 'R' is a respin number. Both N and R have to be > integers (though they can have multiple digits; Alpha-11.23 would be a > valid label). > > Fedora does not do numbered milestone releases; we just have Alpha, > Beta and Final. RHEL does, which is why the label format has 'N'. In > the RHEL process, as I understand it, they build "Alpha-1.1", then if > it passes whatever requirements are needed for an "Alpha 1" release, > they ship it as Alpha 1; otherwise they build "Alpha-1.2" and ship that > if it passes, etc etc. The "respin" value is considered "private", and > respins are used for about the same purpose we use TCs/RCs. > > It *is* possible to do a 'production' compose with no label, I believe, > by calling 'pungi-koji --no-label'. It would *also* be technically > possible to add new label formats to Pungi. So we do have three options > at the high level: > > a. Work with Pungi's currently-expected label format In this format option, MILESTONE-N.R would be MILESTONE= alpha, beta, RC N = arbitrary integer R = arbitrary integer Can N and R be 0? Or must it be 1-9? > So we could > instead lock down R and only increment N, so we'd do 'RC 1.1', 'RC > 2.1', 'RC 3.1' and so on. To reduce granularity, lock down either N or R. But if locked down, I suggest a value of 0 rather than 1 to indicate nullification. > The build called 'RC 1.1' would likely not > really be a "real" RC (in the sense it'd happen while we were not > frozen and not have all blocker bugs fixed), but that's not horrible. I > suppose we could relatively easily add 'Final' to Pungi's list of > milestones too, if we wanted (or 'TC', come to that). At least from the test side, I'm not thinking there was ever a meaningful distinction between TC and RC for alpha and beta. For final, I vaguely think TCs and RCs did change behavior in some ways, maybe it was disabling u-t by default? Or maybe some installer labeling or warning goes away? If you want to keep some granularity to distinguish between TC/RC you could use N=0 to indicate "TC" and N=1 to indicate "RC". :-P TC's alpha-0.1 alpha-0.2 alpha-0.3 alpha-0.4 beta-0.1 beta-0.2 beta-0.3 RC-0.1 RC-0.2 legit RC's alpha-1.1 alpha-1.2 alpha-1.3 alpha-1.4 beta-1.1 beta-1.2 beta-1.3 RC-1.1 RC-1.2 Further, if there is no meaningful distinction between TC/RC during alpha and beta, then those would always be N=1. You'd only nullify "RC" with a trailing 0 for the final TC's. -- Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
RE: Pungi 4 milestone builds: proposals
> Subject: Re: Pungi 4 milestone builds: proposals > From: adamw...@fedoraproject.org > To: test@lists.fedoraproject.org; rel-...@lists.fedoraproject.org > Date: Wed, 9 Mar 2016 10:33:41 -0800 > > On Wed, 2016-03-09 at 13:26 -0500, John Dulaney wrote: >> . >>> >>> >>> == 2. N indicates TC/RC, R indicates number == >>> >>> In this scheme, we'd build e.g. 'Alpha 1.1' (Alpha TC1), 'Alpha 1.2' >>> (Alpha TC2), 'Alpha 2.1' (Alpha RC1), 'Alpha 2.2' (Alpha RC2). >>> >>> This seems like the closest possible way to map to our current system. >>> Again it's a bit weird at Final because there is no 'Final' milestone, >>> only 'RC', so 'RC1.1' would be 'TC1' and 'RC2.1' would be 'RC1', which >>> is kinda strange; again we could add a 'Final' milestone to Pungi, I >>> guess. >>> >>> I'm just not sure, as per 1), if we really *need* to maintain the TC/RC >>> distinction at least in terms of how the composes are labelled and >>> distributed. >>> >> I'm a fan of this approach, personally. > > With weirdly-named RCs, or by adding a 'Final' milestone to Pungi? With Alpha 1.1' (Alpha TC1), 'Alpha 1.2' (Alpha TC2), etc. It does map over to our current process rather well, and won't involve changes to Pungi that might break things. The modification I would suggest, however, is that instead of RC2.x for Final, simply start doing 'Production' builds. If a particular production build passes, then that's what we ship as final. John. -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Pungi 4 milestone builds: proposals
On Wed, 2016-03-09 at 13:26 -0500, John Dulaney wrote: > . > > > > > > == 2. N indicates TC/RC, R indicates number == > > > > In this scheme, we'd build e.g. 'Alpha 1.1' (Alpha TC1), 'Alpha 1.2' > > (Alpha TC2), 'Alpha 2.1' (Alpha RC1), 'Alpha 2.2' (Alpha RC2). > > > > This seems like the closest possible way to map to our current system. > > Again it's a bit weird at Final because there is no 'Final' milestone, > > only 'RC', so 'RC1.1' would be 'TC1' and 'RC2.1' would be 'RC1', which > > is kinda strange; again we could add a 'Final' milestone to Pungi, I > > guess. > > > > I'm just not sure, as per 1), if we really *need* to maintain the TC/RC > > distinction at least in terms of how the composes are labelled and > > distributed. > > > I'm a fan of this approach, personally. With weirdly-named RCs, or by adding a 'Final' milestone to Pungi? -- Adam WilliamsonFedora QA Community MonkeyIRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . nethttp://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
RE: Pungi 4 milestone builds: proposals
. > > == 2. N indicates TC/RC, R indicates number == > > In this scheme, we'd build e.g. 'Alpha 1.1' (Alpha TC1), 'Alpha 1.2' > (Alpha TC2), 'Alpha 2.1' (Alpha RC1), 'Alpha 2.2' (Alpha RC2). > > This seems like the closest possible way to map to our current system. > Again it's a bit weird at Final because there is no 'Final' milestone, > only 'RC', so 'RC1.1' would be 'TC1' and 'RC2.1' would be 'RC1', which > is kinda strange; again we could add a 'Final' milestone to Pungi, I > guess. > > I'm just not sure, as per 1), if we really *need* to maintain the TC/RC > distinction at least in terms of how the composes are labelled and > distributed. > I'm a fan of this approach, personally. John. -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Pungi 4 milestone builds: proposals
Hi folks! So we're now frozen for Alpha and we have an anaconda build with blocker fixes in updates-testing...I guess this means it's a good time to decide what to do about milestone builds with Pungi 4. :) I'm assuming here that we're going to use more or less the same "TCs and RCs" approach for F24 and just try to adapt it to Pungi 4. It seems a bit late to make radical changes to the process itself at this point. I have a couple of ideas. I'm gonna recap, briefly, what (as I understand it) Pungi 4 expects us to do for milestone builds: We're expected to run 'pungi-koji --label foo', where 'foo' is a compose 'label' in Pungi's expected format. AIUI, this is the format Pungi expects for a compose 'label': MILESTONE-N.R where MILESTONE is the milestone (there is a list of valid milestones; for our purposes we're likely to use Alpha, Beta and RC), 'N' is the release number, and 'R' is a respin number. Both N and R have to be integers (though they can have multiple digits; Alpha-11.23 would be a valid label). Fedora does not do numbered milestone releases; we just have Alpha, Beta and Final. RHEL does, which is why the label format has 'N'. In the RHEL process, as I understand it, they build "Alpha-1.1", then if it passes whatever requirements are needed for an "Alpha 1" release, they ship it as Alpha 1; otherwise they build "Alpha-1.2" and ship that if it passes, etc etc. The "respin" value is considered "private", and respins are used for about the same purpose we use TCs/RCs. It *is* possible to do a 'production' compose with no label, I believe, by calling 'pungi-koji --no-label'. It would *also* be technically possible to add new label formats to Pungi. So we do have three options at the high level: a. Work with Pungi's currently-expected label format b. Patch Pungi to support a more Fedora-y label format c. Don't apply a label to our TC/RC composes at all I would suggest that a is the best practical choice, though, because we know this is how Pungi is kind of expected to be used. b is likely to take time to work out any kinks, and c seems unnecessarily extreme; we should be able to come up with a usable label format that gives us valuable information. So assuming we go with 1) at the high level, I see a few possibilities for how to do this. == 1. Just use one value == In this design, we'd set one of the numbers to 1 (or I guess 0) for every single Fedora compose, and just increment the other. I was thinking we'd lock down the release number (N) and just increment the respin (R) - so we'd do Alpha-1.1 then Alpha-1.2 then Alpha-1.3 and so on. This seems like it'd work fine for Alpha and Beta but be a little odd for Final. 'Final' is not a valid milestone for Pungi 4, it expects you to use 'RC' as a milestone and build 'RC1.1', 'RC1.2', 'RC1.3', 'RC2.1' etc etc. It'd be a bit odd for us to have 'RC1.1' as 'Final TC1', 'RC1.2' as 'Final TC2', 'RC1.3' as 'Final RC1', etc. So we could instead lock down R and only increment N, so we'd do 'RC 1.1', 'RC 2.1', 'RC 3.1' and so on. The build called 'RC 1.1' would likely not really be a "real" RC (in the sense it'd happen while we were not frozen and not have all blocker bugs fixed), but that's not horrible. I suppose we could relatively easily add 'Final' to Pungi's list of milestones too, if we wanted (or 'TC', come to that). The other possible problem with this is it makes it hard to keep the TC/RC distinction. We could build the composes as 'Alpha 1.1', 'Alpha 2.1', 'Alpha 3.1' and put 'Alpha 1.1' in a directory called 'Alpha_TC1', 'Alpha 2.1' in 'Alpha_TC2', and 'Alpha 3.1' in 'Alpha_RC1' if we wanted, but you couldn't easily map from one name to the other, because there's no way to know the cutoff where we switched over - if you only know you're dealing with 'Alpha 2.1', you can't tell if that's 'Alpha TC2' or 'Alpha RC1'. The question then is, do we actually need the TC/RC distinction for anything? I'm not sure we really do. But if we want to keep it, we could try... == 2. N indicates TC/RC, R indicates number == In this scheme, we'd build e.g. 'Alpha 1.1' (Alpha TC1), 'Alpha 1.2' (Alpha TC2), 'Alpha 2.1' (Alpha RC1), 'Alpha 2.2' (Alpha RC2). This seems like the closest possible way to map to our current system. Again it's a bit weird at Final because there is no 'Final' milestone, only 'RC', so 'RC1.1' would be 'TC1' and 'RC2.1' would be 'RC1', which is kinda strange; again we could add a 'Final' milestone to Pungi, I guess. I'm just not sure, as per 1), if we really *need* to maintain the TC/RC distinction at least in terms of how the composes are labelled and distributed. == 3. Some kinda hybrid == We could combine things, so we do 1.n for Alpha and Beta, then n.1 for RC (so we have Alpha 1.1, Alpha 1.2, Alpha 1.3, Alpha 1.4, Beta 1.1, Beta 1.2, Beta 1.3, RC1.1, RC2.1, RC3.1 etc). This is viable, but I'm not really sure it's necessary. It seems simpler to pick some variant of 1 or 2. There's a final question, which is whether we a
Re: [Test-Announce] Fedora 24 Branched 20160308 nightly compose nominated for testing
Fedora-SoaS-Live-x86_64-24-20160308.0.iso now has sugar 108.1 and renders correctly but liveinst crashes and NM does not connect * satellit_e qemu/kvm f23 On 03/09/2016 09:47 AM, Adam Williamson wrote: [again, an event was created but the notification email got lost. I've figured out why now - they're being sent from an address that wasn't subscribed to the list. I've fixed that, so future notification emails should work. Again sending this one manually.] Announcing the creation of a new nightly release validation test event for Fedora 24 Branched 20160308. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/24 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160308_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160308_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160308_Base https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160308_Server https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160308_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160308_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160308_Security_Lab https://fedoraproject.org/wiki/Template:Fedora_24_Branched_20160308_Download Thank you for testing! -- Adam WilliamsonFedora QA Community MonkeyIRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . nethttp://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org -- devel mailing list de...@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/de...@lists.fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
[Test-Announce] Fedora 24 Branched 20160308 nightly compose nominated for testing
[again, an event was created but the notification email got lost. I've figured out why now - they're being sent from an address that wasn't subscribed to the list. I've fixed that, so future notification emails should work. Again sending this one manually.] Announcing the creation of a new nightly release validation test event for Fedora 24 Branched 20160308. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/24 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160308_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160308_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160308_Base https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160308_Server https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160308_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160308_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_24_Branched_20160308_Security_Lab https://fedoraproject.org/wiki/Template:Fedora_24_Branched_20160308_Download Thank you for testing! -- Adam WilliamsonFedora QA Community MonkeyIRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . nethttp://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
OT: Looking for examples of badly written bug reports
Hello everyone, I'm working on beginner QA and Automation training curricula for a local hack school in Sofia (https://github.com/atodorov/QA-101). I'm looking for examples of badly written bug reports which students can read and discuss what information is missing from them (e.g. why are they badly written). Bugs can be on any bug tracker, not necessarily bugzilla.redhat.org. Strong favor for Mozilla, Gnome or GitHub issues in particular. They only need to be publicly accessible. If you have any such examples please send them to me. Thanks, Alex -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
