Fedora Rawhide 20151125 compose check report
Missing expected images: Cloud disk raw i386 Cloud disk raw x86_64 Cloud_atomic disk raw x86_64 Workstation live i386 Workstation live x86_64 No images in this compose but not Rawhide 20151124 No images in Rawhide 20151124 but not this. Failed openQA tests: 28 of 49 ID: 9021Test: x86_64 universal server_no_swap@uefi ID: 9020Test: i386 universal server_lvmthin ID: 9012Test: x86_64 kde_live default_install ID: 9011Test: i386 kde_live default_install ID: 9008Test: x86_64 generic_boot default_install ID: 9007Test: i386 universal upgrade_desktop_32bit ID: 9005Test: i386 universal server_ext3 ID: 9002Test: i386 universal server_simple_encrypted ID: 9001Test: i386 universal server_repository_http_graphical ID: 8997Test: x86_64 universal server_lvmthin@uefi ID: 8995Test: x86_64 universal server_btrfs@uefi ID: 8990Test: x86_64 universal server_delete_partial@uefi ID: 8988Test: x86_64 universal server_sata_multi@uefi ID: 8987Test: x86_64 universal european_language_install ID: 8986Test: x86_64 universal server_shrink_ntfs ID: 8985Test: x86_64 universal server_shrink_ext4 ID: 8983Test: x86_64 universal upgrade_desktop_64bit ID: 8981Test: x86_64 universal server_kickstart_hdd ID: 8980Test: x86_64 universal server_no_swap ID: 8978Test: x86_64 universal server_ext3 ID: 8976Test: x86_64 universal server_software_raid ID: 8972Test: x86_64 universal server_delete_partial ID: 8971Test: x86_64 universal server_repository_http_variation ID: 8970Test: x86_64 universal server_repository_http_graphical ID: 8969Test: x86_64 universal server_mirrorlist_graphical ID: 8968Test: x86_64 universal server_delete_pata ID: 8967Test: x86_64 universal server_kickstart_user_creation ID: 8966Test: x86_64 universal server_scsi_updates_img Passed openQA tests: 21 of 49 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: criterion proposal: upgrading across 2 releases
On Wed, 2015-11-25 at 09:46 -0500, Richard Ryniker wrote: > System-upgrade across two releases raises an interesting End-of-Life > policy issue. If system-upgrade from N-2 to N is so important it will > block release of N until it works, how do we explain why it is no > longer important after four weeks when N-2 reaches End of Life? It's not like dnf-system-upgrade would magically stop working when N-2 reaches EOL, so honestly, overall, I just don't really see the problem you're describing in this mail. We've had the current release scheme for years, people are fairly used to it; I don't honestly see that officially supporting N-2 upgrades changes the overall story much, we're just giving people another tool to use in the one month transition period (and of course, in practice, dnf-system-upgrade should usually continue to work just fine after EOL). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: testcase proposal: joining bios+uefi in system upgrade section
On Tue, 2015-11-24 at 06:33 -0500, Kamil Paral wrote: > As a middle ground, what about having: > .---. > | BIOS UEFI| > |Testcase_upgrade_dnf_previous_any | > '---' > > I think that's reasonable? Maybe we don't even need to modify and use > the template content, just reference other test cases and say that > any of them is fine. Yeah, that would be OK, I think. Of course in a sane TCMS we'd have a better way of saying 'out of these tests, at least one needs to be done for each environment' and calculating coverage and such, but this is Wikitcms ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Fedora 23 updates-testing report
The following Fedora 23 Security updates need testing: Age URL 113 https://bodhi.fedoraproject.org/updates/FEDORA-2015-12739 python-kdcproxy-0.3.2-1.fc23 95 https://bodhi.fedoraproject.org/updates/FEDORA-2015-5eb2131441 conntrack-tools-1.4.2-9.fc23 66 https://bodhi.fedoraproject.org/updates/FEDORA-2015-16240 nagios-4.0.8-1.fc23 53 https://bodhi.fedoraproject.org/updates/FEDORA-2015-dd52a54fa1 python-pymongo-3.0.3-1.fc23 53 https://bodhi.fedoraproject.org/updates/FEDORA-2015-c76c1c84cf mod_nss-1.0.12-1.fc23 40 https://bodhi.fedoraproject.org/updates/FEDORA-2015-66439aa9e2 openstack-glance-2015.1.2-1.fc23 24 https://bodhi.fedoraproject.org/updates/FEDORA-2015-84a95e39d4 perl-HTML-Scrubber-0.15-1.fc23 24 https://bodhi.fedoraproject.org/updates/FEDORA-2015-81ded368fe miniupnpc-1.9-6.fc23 15 https://bodhi.fedoraproject.org/updates/FEDORA-2015-3d17682c15 putty-0.66-1.fc23 11 https://bodhi.fedoraproject.org/updates/FEDORA-2015-7852ea201b potrace-1.13-2.fc23 7 https://bodhi.fedoraproject.org/updates/FEDORA-2015-28e56e52e7 seamonkey-2.39-1.fc23 6 https://bodhi.fedoraproject.org/updates/FEDORA-2015-8b5ea2dc53 rubygem-flexmock-2.0.2-1.fc23 6 https://bodhi.fedoraproject.org/updates/FEDORA-2015-4ad4998d00 libpng-1.6.17-3.fc23 6 https://bodhi.fedoraproject.org/updates/FEDORA-2015-1943310658 libpng15-1.5.22-3.fc23 6 https://bodhi.fedoraproject.org/updates/FEDORA-2015-5d1f935811 imapsync-1.644-2.fc23 5 https://bodhi.fedoraproject.org/updates/FEDORA-2015-13668fff74 mingw-libpng-1.6.19-1.fc23 1 https://bodhi.fedoraproject.org/updates/FEDORA-2015-79c1758468 abrt-2.7.1-1.fc23 1 https://bodhi.fedoraproject.org/updates/FEDORA-2015-e3ec4cbf8f lxdm-0.5.3-1.fc23 0 https://bodhi.fedoraproject.org/updates/FEDORA-2015-a8c8f60fbd python-django-1.8.7-1.fc23 0 https://bodhi.fedoraproject.org/updates/FEDORA-2015-df0f324367 knot-2.0.2-1.fc23 The following Fedora 23 Critical Path updates have yet to be approved: Age URL 12 https://bodhi.fedoraproject.org/updates/FEDORA-2015-37706c9c35 mash-0.6.19-1.fc23 6 https://bodhi.fedoraproject.org/updates/FEDORA-2015-cf51e6b9dc evolution-data-server-3.18.2-2.fc23 6 https://bodhi.fedoraproject.org/updates/FEDORA-2015-4ad4998d00 libpng-1.6.17-3.fc23 6 https://bodhi.fedoraproject.org/updates/FEDORA-2015-65152c5896 koji-1.10.1-1.fc23 5 https://bodhi.fedoraproject.org/updates/FEDORA-2015-82bc055b3f perl-PathTools-3.60-1.fc23 5 https://bodhi.fedoraproject.org/updates/FEDORA-2015-22dbc37884 perl-Socket-2.021-1.fc23 3 https://bodhi.fedoraproject.org/updates/FEDORA-2015-0d84d6c75f selinux-policy-3.13.1-155.fc23 2 https://bodhi.fedoraproject.org/updates/FEDORA-2015-9b1b3e9a5c xkeyboard-config-2.16-1.fc23 1 https://bodhi.fedoraproject.org/updates/FEDORA-2015-fb80693245 chkconfig-1.7-1.fc23 1 https://bodhi.fedoraproject.org/updates/FEDORA-2015-2ae867c402 NetworkManager-vpnc-1.0.8-1.fc23 NetworkManager-openconnect-1.0.8-1.fc23 NetworkManager-openvpn-1.0.8-1.fc23 NetworkManager-openswan-1.0.8-1.fc23 NetworkManager-fortisslvpn-1.0.8-1.fc23 NetworkManager-1.0.8-1.fc23 1 https://bodhi.fedoraproject.org/updates/FEDORA-2015-3e75abf2a3 krb5-1.14-2.fc23 0 https://bodhi.fedoraproject.org/updates/FEDORA-2015-498b25667e perl-BSD-Resource-1.290.900-1.fc23 0 https://bodhi.fedoraproject.org/updates/FEDORA-2015-f26dec73e9 kernel-4.2.6-301.fc23 The following builds have been pushed to Fedora 23 updates-testing GMT-5.2.1-1.fc23 antlr3-3.5.2-10.fc23 antlr32-3.2-12.fc23 carbon-c-relay-1.1-1.fc23 eclipse-xtext-antlr-generator-2.1.1-3.git18383dd.fc23 fedmsg-0.16.2-6.fc23 fwknop-2.6.7-1.fc23 gegl03-0.3.4-1.fc23 gogoc-1.2-47.fc23 gssdp-0.14.12-1.fc23 icecat-38.4.0-1.fc23 kernel-4.2.6-301.fc23 knot-2.0.2-1.fc23 kwalletmanager-15.04.3-2.fc23 libblockdev-1.3-4.fc23 lilypond-2.19.32-1.fc23 lilypond-doc-2.19.32-1.fc23 lirc-0.9.3a-2.fc23 mingw-p11-kit-0.23.1-3.fc23 mock-1.2.14-1.fc23 mozjs38-38.2.1-4.fc23 nodejs-is-my-json-valid-2.12.3-1.fc23 odb-2.4.0-7.fc23 perl-BSD-Resource-1.290.900-1.fc23 perl-String-Compare-ConstantTime-0.311-1.fc23 perl-Text-Autoformat-1.73-1.fc23 python-Traits-4.5.0-7.gitac5d029.fc23 python-alembic-0.8.3-3.fc23 python-cagraph-1.2-18.fc23 python-django-1.8.7-1.fc23 python-editor-0.4-4.fc23 python-faker-0.5.3-6.fc23 python-humblewx-0.2.1-1.fc23 python-isodate-0.5.4-1.fc23 python-pyface-5.0.0-6.fc23 python-pyrfc3339-1.0-1.fc23 python-requestsexceptions-1.1.1-2.fc23 python-rpdb-0.1.5-2.fc23 python-traitsui-5.0.0-2.fc23 python3-script-1.7.2-7.fc23 pytorctl-0-0.18.20130920git4fdd203.fc23 rpg-0.0.5-1.fc23 rubber-1.3-1.fc23 sxc-0.8-1.fc23 tint2-0.12.3-1.fc23 umlgraph-5.7.2-12.fc23 viking-1.6.1-1.fc23 Details
Re: criterion proposal: upgrading across 2 releases
On Wed, 2015-11-25 at 13:36 -0500, Richard Ryniker wrote: > My reading of the EOL policy says "If it isn't fixed before EOL, it is > unlikely to be fixed." If I encounter a problem with release-skipping > system-upgrade, too bad. There is probably no time to fix it before EOL. That's not really accurate. A month is a pretty long time in Fedora development, certainly long enough to diagnose and fix typical upgrade issues. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: criterion proposal: upgrading across 2 releases
On Wed, 2015-11-25 at 16:51 -0500, Richard Ryniker wrote: > > A month is a pretty long time in Fedora development > > True, but a month is only available if the problem is reported on day 1. > If it takes a week or two for a user to report a problem, that interval > lessens the remaining time to EOL. On the other other hand, you can test upgrades at any time, with dnf- system-upgrade. We're already testing 22-24 upgrades daily in openQA at present. > On the other hand, there is no prohibition against a fix after EOL. There is, in fact; you can't push updates for EOL releases, it's simply disabled by policy. > We also do not know there will be serious problems. We know it is > impossible to test more than a miniscule fraction of possible upgrade > cases. That does not mean there will be lots of bugs, it means we have > little confidence the test plan has found most bugs. We might say there > is no reason to believe experience with the current release will be any > worse than the last. This is basically what I'm saying: we can't actually make any guarantees about *most* upgrade experiences, and N-2 upgrades aren't really some special case which is massively more likely to go wrong than any other. Will we have people who have issues doing N-2 upgrades? Probably, sure. Do we have people who have issues doing N-1 upgrades? yep! This isn't something new. We *do*, I think, mention in all the relevant documentation that upgrades are complex operations and success is never guaranteed, that's not what 'supported' means, especially in this context. > As far as I know, this is the first time "dnf system-upgrade" has been > generally available for a release-skip upgrade. It is way too early to > have any historical perspective. F23 is the first release where the dnf-system-upgrade mechanism has been available, yes. But it's really not hugely different from fedup - it's just an even lighter implementation of the same basic idea (just boot to a minimal environment and run a dnf transaction). The experience of fedup should be a reasonable indicator of future dnf- system-upgrade experiences. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Non-image blocker process change proposal
On Fri, 2015-11-20 at 16:18 +0530, Sudhir D wrote: > > > I don't think it's appropriate to turn FEs into blockers automatically, > > in fact there are obvious cases where it certainly wouldn't be > > appropriate: bugs in non-blocking desktops are typically taken as FEs, > > for instance, as are bugs in secondary arches. Neither of those can > > ever be blockers by policy. > > Ok. We should probably stop calling them as FEs in that case :) and have > a mechanism to track them on basis of priority and have them fixed > before RC. So just to be clear on the terms here: in Fedora we have 'blocker' and 'freeze exception' bugs. A 'blocker' bug must be fixed for the release to go ahead. A 'freeze exception' bug doesn't *have* to be fixed, but we will accept a fix during the milestone freeze period. Sudhir explained his broader meaning to me on the phone, and it's a good point: so long as we don't actually have any process/mechanism for ensuring that 'special' blockers are fixed on time, calling them blockers is really misleading, because we aren't really having them 'block' the release. You're certainly right about that. At Monday's meeting, though, we agreed that we're generally in favour of changing the release process such that we *do* effectively block the release for these bugs, so if we do go ahead and implement that, it will still be correct to refer to them as 'blockers'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: criterion proposal: upgrading across 2 releases
>A month is a pretty long time in Fedora development True, but a month is only available if the problem is reported on day 1. If it takes a week or two for a user to report a problem, that interval lessens the remaining time to EOL. On the other hand, there is no prohibition against a fix after EOL. We also do not know there will be serious problems. We know it is impossible to test more than a miniscule fraction of possible upgrade cases. That does not mean there will be lots of bugs, it means we have little confidence the test plan has found most bugs. We might say there is no reason to believe experience with the current release will be any worse than the last. As far as I know, this is the first time "dnf system-upgrade" has been generally available for a release-skip upgrade. It is way too early to have any historical perspective. -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Non-image blocker process change proposal
On Wed, 2015-11-18 at 16:36 -0800, Adam Williamson wrote: > #2 MOAR METADATA > > > The alternative is to make the existing Blocker trackers do more work. > In this model we wouldn't add any new tracker bugs; we'd just add new > 'magic words' in the Whiteboard field. Right now, an accepted blocker > is identified by the string 'AcceptedBlocker' appearing in the > whiteboard field. We could simply add some more magical strings like > that: 'Accepted0Day' and 'AcceptedStable', say (better suggestions > welcome). > > I kind of like this idea as it's less change and involves creating > fewer new bugs. We'd have to make some changes to blockerbugs either > way - tflink can say if either approach would be more work in > blockerbugs, but I'm gonna guess they'd be fairly similar. Hi again folks! So it sounds like this option was preferred by everyone who expressed a preference, and it's my choice too, so I figure we should just go for it. I think we still have some more research/discussion/co-ordination to do before we can propose changes to the release process (especially the go/no-go process) to 'enforce' special blockers, but I think we can go ahead and implement the *tracking* side of the changes now. So I'm gonna propose that we add these new terms for the Whiteboard field: Accepted0Day (for bugs where the fix must appear in 0-day updates for the new release) AcceptedStable (for bugs where the fix must appear in updates for the previous stable release(s) by release day of the new release) I'm not 100% married to either of those, especially the second. If anyone has a better idea, please send it! Once we decide on the terms, the next step would be to edit the blocker SOPs: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - the changes shouldn't be too onerous - and to update blockerbugs for the new world order. I know tflink has a lot on his plate, so I might take a cut at that to try and save him the work. Comments, thoughts, questions as always - thanks folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: criterion proposal: upgrading across 2 releases
>It's not like dnf-system-upgrade would magically stop working when N-2 >reaches EOL, so honestly, overall, I just don't really see the problem >you're describing Like most of Fedora, dnf-system-upgrade gets limited testing before release. When N is released, a large number of users who did not install N-1 will think it is time to upgrade before their current N-2 reaches End-of-Life in four weeks. These users will try system-upgrade from a much larger set of initial states than could be tested before release. This is the time the greatest number of (N-2 to N) problems will be found. It is also the time when problems in the brand-new release N are most likely, as users of N-1 eagerly try N. With an abundance of bug reports in the just-released N, and some new reports of problems with N-2 that will be closed by EOL in a handful of days, where do you think maintenance should focus? I admit this view is based on what is probable, not on actual fact. My point is not do this or avoid that, I want the Fedora user to have an accurate understanding of upgrade choices. My reading of the EOL policy says "If it isn't fixed before EOL, it is unlikely to be fixed." If I encounter a problem with release-skipping system-upgrade, too bad. There is probably no time to fix it before EOL. In effect, release-skipping system-upgrade is not supported. Either I upgrade every release (when system-upgrade is supported and bug fixes are likely), I plan to do a new install, or I hope to be lucky with EOL code. That is not a bad set of choices. Bad is a user in trouble because he reasonably thought they were different. "Release-skipping system-upgrade is a release-blocking requirement" sounds likely to obscure the support risks that attend its use. Fedora is certainly better for a robust system-upgrade facility. No point is filing bugs now for my 21-23 failure, though. 21 is EOL, and the failure did not occur with 22. -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
rawhide report: 20151125 changes
Compose started at Wed Nov 25 05:15:03 UTC 2015 Broken deps for i386 -- [IQmol] IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2 [alliance] alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2 [eclipse-jbosstools] eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires osgi(org.eclipse.tm.terminal) [fawkes] fawkes-core-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10 fawkes-plugin-player-0.5.0-26.fc24.i686 requires libgeos-3.4.2.so fawkes-plugin-xmlrpc-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10 [gnash] 1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-plugin-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 [golang-github-kraman-libcontainer] golang-github-kraman-libcontainer-devel-0-0.4.gitd700e5b.fc24.noarch requires golang(github.com/docker/docker/pkg/netlink) [golang-github-kubernetes-heapster] golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/google/cadvisor/info/v1) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/google/cadvisor/client) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/schema) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/registry) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/pkg) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/machine) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/etcd) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/client) [golang-github-prometheus-prometheus]
Introduction
Hello everyone, I'm Tiago. I've been using Fedora for many many years and I'm a Fedora Ambassador in the UK. As an Ambassador I haven't been very active due to personal reasons, but I now want to get traction again and be as active as I can. I have more than 14 years of professional experience with software development and I love Python and C. For the past 6-8 years I've been working within different release, build and quality assurance teams. I currently work with the product interoperability testing team at Red Hat, where I help the team to develop tools to automate the testing of the interoperability of Red Hat products. I plan to get few hours a week of my spare time to collaborate with the QA group whatever I can. Don't hesitate to reach me if you think I can help with anything. IRC: tmoreira (#fedora-qa, #fedora-ambassadors, #fedora-python, ...) -- Tiago -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: criterion proposal: upgrading across 2 releases
System-upgrade across two releases raises an interesting End-of-Life policy issue. If system-upgrade from N-2 to N is so important it will block release of N until it works, how do we explain why it is no longer important after four weeks when N-2 reaches End of Life? Four weeks is little time to allow users who chose not to upgrade to N-1 to move from N-2 to N. Do we say "After four weeks, the only supported mechanismm is new installation of N"? That is clear and simple, consistent with the EOL schedule, but denies system-upgrade is such a critical facility. Should system-upgrade be formally supported for three releases (18 months?) That would tell users they may count on it for their upgrade plan, but it is a significant change that could involve FESCo. -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
