Re: criterion adjustment proposal: demote optical media support

[Petr Schindler]

+1 looks great.

On Tue, 2017-01-17 at 08:41 -0500, Kamil Paral wrote:
> Hi,
> 
> as discussed in "future of official optical media support in Fedora"
> thread in devel list [1], we agreed to decrease the importance and
> testing of optical media support for Fedora release composes, and
> block on just several specific images. This is a concrete proposal to
> adjust our release criteria to match the outcome of the discussion.
> The outcome is that we will not block on broken optical support for
> any Alpha/Beta composes, and we will block on optical support for
> Final composes only for Workstation Live and Everything netinst image
> (please note that I didn't receive much feedback for my last point
> where I suggested Everything netinst is made release blocking [2] -
> if you have something to add, there's still time).
> 
> 
> == Don't block on Alpha/Beta adjustment ==
> 
> 1. On page https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Cri
> teria#Release-blocking_images_must_boot the first sentence under
> "Supported media types" section changes from:
> > Release-blocking live and dedicated installer images must boot when
> > written to optical media of an appropriate size (if applicable) and
> > when written to a USB stick with at least one of the officially
> > supported methods.
> 
> to
> > Release-blocking live and dedicated installer images must boot when
> > written to a USB stick with at least one of the officially
> > supported methods.
> 
> 2. On page https://fedoraproject.org/wiki/Fedora_26_Beta_Release_Crit
> eria#Release-blocking_images_must_boot the first sentence under
> "Supported media types" section changes from:
> > Release-blocking live and dedicated installer images must boot when
> > written to optical media of an appropriate size (if applicable) and
> > when written to a USB stick with any of the officially supported
> > methods.
> 
> to
> > Release-blocking live and dedicated installer images must boot when
> > written to a USB stick with any of the officially supported
> > methods.
> 
> 3. On page https://fedoraproject.org/wiki/Fedora_26_Final_Release_Cri
> teria we add "Initialization requirements" header with "Release-
> blocking images must boot" sub-header (same as in Alpha/Beta) with
> text:
> > All release-blocking images must boot in their supported
> > configurations.
> > Supported media types [hide]
> > Release-blocking live and dedicated installer images must boot when
> > written to optical media of an appropriate size (if applicable) and
> > when written to a USB stick with any of the officially supported
> > methods.
> > Difference from Beta [hide]
> > This criterion differs from the similar Beta criterion only in that
> > it requires all supported images to work when written also to an
> > optical media, not just USB sticks.
> 
> 
> == Block only on Workstation Live and Everything netinst change ==
> 
> 1. On page https://fedoraproject.org/wiki/Fedora_Program_Management/R
> eleaseBlocking/Fedora26 we add another column to the all the tables
> called "optical boot is release blocking". The cells will have value
> "yes" for Workstation Live x86_64 and Everything netinst x86_64,
> value "no" for all other rows containing "release blocking = yes",
> and will be grayed out for rows containing "release blocking = no".
> 
> (We link to this page from Alpha/Beta/Final release criteria pages
> from the last sentence in the description in the top of the page.)
> 
> 
> == Wiki adjustments ==
> 
> 1. On page https://fedoraproject.org/wiki/Template:Installation_test_
> matrix#Default_boot_and_install_.28x86_64.29 we change "Expected
> coverage" box from:
> > For Alpha and Beta, we expect a reasonable sampling of tests across
> > the table, with at least some testing for all three media types,
> > both firmware types, and each major class of deliverable (netinst,
> > live and DVD). For Final, we expect full coverage for all the Alpha
> > / Final rows.
> 
> to
> > For Alpha and Beta, we expect a reasonable sampling of tests across
> > the table, with at least some testing for VM and USB boot method,
> > both firmware types, and each major class of deliverable (netinst,
> > live and DVD). Optical boot testing is optional at this stage. For
> > Final, we expect full coverage for the Alpha / Final rows with VM
> > and USB boot method. Optical boot testing in Final is mandatory for
> > [[Fedora_Program_Management/ReleaseBlocking/Fedora26|supported
> > images]].
> 
> 
> Wording improvements or any other feedback welcome.
> 
> Thanks,
> Kamil
> 
> [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedorap
> roject.org/thread/KICRVUS3YHNTLHY47O5A2XL2C5YMCFIH/
> [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedorap
> roject.org/message/VQQXMJ7QMTLNRFRI5VYIKGIU5IV2W6KB/
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org

[Test-Announce] 2016-07-20 @ 16:00 UTC - Fedora 25 Blocker Review

[Petr Schindler]

# F25 Blocker Review meeting
# Date: 2016-07-20
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net

Hi folks! We have currently few blockers proposed for future Fedora 25
so it would be great to look at them now when they aren't overpopulated
yet. There are 3 proposed Beta blockers, 1 Beta blocker and 1 Final
blocker.

If you have some time, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ . Remember to check
each outstanding milestone (Alpha, Beta and Final).

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F25 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria

Have a nice day,
Petr Schindler, Fedora QA
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

[Test-Announce] 2016-07-20 @ 16:00 UTC - Fedora 25 Blocker Review

[Petr Schindler]

# F25 Blocker Review meeting
# Date: 2016-07-20
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net

Hi folks! We have currently few blockers proposed for future Fedora 25
so it would be great to look at them now when they aren't overpopulated
yet. There are 3 proposed Beta blockers, 1 Beta blocker and 1 Final
blocker.

If you have some time, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ . Remember to check
each outstanding milestone (Alpha, Beta and Final).

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F25 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria

Have a nice day,
Petr Schindler, Fedora QA
___
test-announce mailing list
test-announce@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/test-announce@lists.fedoraproject.org

Re: 2016-04-11 @ 16:00 UTC - Fedora QA Meeting - Minutes

[Petr Schindler]

On Út, 2016-04-12 at 05:34 -0400, Sumantro Mukherjee wrote:
> Hey All,
> 
> As we discussed in the meeting yesterday,I have listed test cases of
> the upcoming Fedora Test Day on Fedora Media Writer on this wiki[1].
> Let me know if you have any feedbacks and inputs.
> 
> [1] https://fedoraproject.org/wiki/QA:Testcase_Fedora_Media_Writer

Hi Sumantro,

firstly welcome to our team. It's always nice to meet another man who
wants to make Fedora better :)

I have few notes on that test case. Overall it looks great I followed
steps and was able to make it work (ehm, the tool itself tried to make
it harder, but still it worked). These notes are my feedback. What I
think could make it easier to follow:

1. Could you put there links for downloading package for different
Fedora releases instead of giving link just to f22 version?
2. In the second step you ask to check if the tool wipes the content.
How can user find out that it really wiped it? 

I tried it (just with freshly partitioned usb stick, because it
couldn't find it otherwise) and it just wrote that it is writing. But
there was message in terminal (from where I run it): "Overwriting
device with live image".

3. You could probably divide the "How to test" section to two parts:
* how to create a media (for Fedora and Windows)
* how to test it (this is same for Fedora and Windows)

4. I'm not sure what UEFI boot/BIOS boot bullets mean.

Thank you,
Petr (pschindl)


> 
> Thanks,
> Sumantro
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

[Test-Announce] Test day announcement: Integration of Qt applications in Fedora Workstation

[Petr Schindler]

Hi,

I would like to inform you that tomorrow (2016-03-17) is going to be a
test 
day focusing on integration of Qt applications in Fedora Workstation
(Gnome 
shell). There are two packages/components making Qt applications more 
integrated into Gnome world. The first one is adwaita-qt, which is a Qt
theme 
trying to look identical to adwaita theme in gtk. The second one is 
QGnomePlatform, which is a Qt platform plugin forcing Qt applications
to use 
adwaita-qt theme and also same font and icons as Gnome does.

If you use any Qt application while you use Gnome, then help us to make
this 
integration better and attend the test day, report your issues or
propose your 
ideas. You can find more information about the test day here [1].

[1] - https://fedoraproject.org/wiki/Test_Day:2016-03-17_Qt_Gtk_Integra
tion

Regards,
Jan
-- 
Jan Grulich 
Software Engineer, Desktop team
Red Hat Czech
___
test-announce mailing list
test-announce@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/test-announce@lists.fedoraproject.org

[Test-Announce] Test day announcement: Integration of Qt applications in Fedora Workstation

[Petr Schindler]

Hi,

I would like to inform you that tomorrow (2016-03-17) is going to be a
test 
day focusing on integration of Qt applications in Fedora Workstation
(Gnome 
shell). There are two packages/components making Qt applications more 
integrated into Gnome world. The first one is adwaita-qt, which is a Qt
theme 
trying to look identical to adwaita theme in gtk. The second one is 
QGnomePlatform, which is a Qt platform plugin forcing Qt applications
to use 
adwaita-qt theme and also same font and icons as Gnome does.

If you use any Qt application while you use Gnome, then help us to make
this 
integration better and attend the test day, report your issues or
propose your 
ideas. You can find more information about the test day here [1].

[1] - https://fedoraproject.org/wiki/Test_Day:2016-03-17_Qt_Gtk_Integra
tion

Regards,
Jan
-- 
Jan Grulich 
Software Engineer, Desktop team
Red Hat Czech
___
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

Re: Non-image blocker process change proposal

[Petr Schindler]

Stephen Gallagher píše v Čt 19. 11. 2015 v 15:50 -0500:
> On 11/18/2015 07:36 PM, Adam Williamson wrote:
> 
> > With either approach, the basic goal is to make it more feasible
> > to keep an eye on each of the different categories of 'release
> > blocker' bugs; right now we have solid processes in place for
> > ensuring the 'normal' blockers are all addressed in the release
> > media, but we don't have any processes in place for ensuring 0Day
> > and Stable bugs actually get updates shipped when we say they
> > must.
> > 
> > My suggestion would be that we make sure 'blockerbugs' includes
> > lists of each type of blocker. Ahead of and at Go/No-Go meetings,
> > we would want to have a formal assurance from the person
> > responsible for fixing the bug that the fix would be provided by a
> > certain time - say, one day or two days ahead of the release date -
> > and it would be QA's responsibility to ensure the updates are
> > tested promptly, and releng's responsibility to ensure they are
> > pushed on time after being tested. I would suggest the Program
> > Manager ought to have overall responsibility for keeping an eye on
> > the 0Day and Stable blocker lists and making sure the maintainer,
> > QA, and releng all did their jobs on time.
> 
> The biggest issue is this, I think. We probably need to encode
> "Special Blockers" into the Go/No-Go process. I don't think that
> assurance that it will be fixed on time is necessarily good enough.
> Particularly given the time that it takes stable updates to make it
> to
> the mirrors, I'd say that we probably want to say that any such
> special blockers have to be queued for stable before the Go/No-Go
> decision is made. (This may in some cases mean *during* the Go/No-Go
> meeting, of course.)

+1. I think that even 0day bugs should block the release. When the
update for 0day bug would be available after Go/No-Go and we would
found that it is buggy (doesn't fix bug properly or it creates another
problems) then we would end up with unresolved blocker in release time.
Maybe we could add some rule for delaying release in such cases
(something like big red button - stop release now!).

From those two proposed solutions I like the second more. To have
another magic words for White board. As I said I think that 0day
blockers should still block the release. But I agree that we should
treat them differently so we should track them somehow.

> -- 
> test mailing list
> test@lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/test
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Call for testing: 32-bit AMD CPU owners

[Petr Schindler]

On Wed, 2015-09-16 at 18:20 -0600, Kevin Fenzi wrote:
> On Wed, 16 Sep 2015 19:39:57 -0400
> Fred Smith  wrote:
> 
> > FYI, using the f23 alpha  iso: 
> > Fedora-Server-DVD-i386-23_Alpha.isoFedora-Server-DVD-i386
> > -23_Alpha.iso
> > 
> > gives a panic message that looks very much like the one shown in 
> > Bugzilla.
> > 
> > This is on an AMD FX6300 six-core processor.
> > 
> > If this hits the thing you wanted to know about, and if you need
> > any
> > more info, you need only ask.
> 
> Out of curiosity if this is the upstream bug it might be... does
> booting with: 
> 
> maxcpus=1
> 
> or
> 
> maxcpus=0
> 
> get it booted?

I tried those parameters and it boots with both of them. I'll update
the bug.

> 
> kevin
> 
> 
> -- 
> test mailing list
> test@lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/test
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Call for testing: 32-bit AMD CPU owners

[Petr Schindler]

On Wed, 2015-09-16 at 17:37 -0700, Adam Williamson wrote:
> On Wed, 2015-09-16 at 18:11 -0400, Stephen Gallagher wrote:
> > On Wed, 2015-09-16 at 12:08 -0700, Adam Williamson wrote:
> > > Hi, folks!
> > > 
> > > We've found an issue in Fedora 23 Beta testing which seems to
> > > affect
> > > AMD CPUs when booting the 32-bit images:
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1263762
> > > 
> > > unfortunately, so far all those who've tested have only had 64
> > > -bit
> > > CPUs. So we know there's a problem booting the 32-bit images on
> > > some
> > > 64-bit AMD CPUs, but we don't know yet if there's a problem
> > > booting
> > > the 32-bit images on 32-bit AMD CPUs, which is obviously the main
> > > reason we still keep the 32-bit images around (people with 64-bit
> > > CPUs
> > > can just use the 64-bit images).
> > 
> > 
> > One additional request: it's unclear right now (and we don't have
> > available hardware to test) if there is also a failure happening on
> > 64-
> > bit AMD systems that are running on i686 Fedora.
> > 
> > If someone out there has access to hardware that hits BZ #1263762,
> > would you please try installing Fedora 22 i686, updating to all the
> > latest stable packages, plus dnf-plugin-system-upgrade from updates
> > -
> > testing and then do an upgrade using the supported mechanism[1] and
> > verify whether A) the upgrade runs or aborts, leaving F22 present
> > and
> > B) if it completes the upgrade, is the system bootable and
> > runnable.
> > 
> > This will help us figure out how serious to rate this issue. (For
> > new
> > installs, we can probably advocate simply using the 64-bit media;
> > for
> > existing installs, irrecoverably breaking on upgrade could be a
> > show-
> > stopper).
> 
> Upgraded systems will at least still have an old kernel around to try
> and boot with, of course.

I tried to install F22 and upgrade it. It doesn't boot with 4.2.0-300
kernel, but it can boot with F22's kernel. So upgraded system could be
booted and used.

> -- 
> 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:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Introduction

[Petr Schindler]

On Po, 2015-07-20 at 09:29 -0300, Priscila Apocalypse wrote:
 Hi all,
 I'm a software developer for 5 years and work most of time with Linux 
 embedded systems.
 Recently,I have a lot of interest in contributing in the fedora 
 community with tests and bug fixing.
 
 So, let me introduce myself.
 My name is Priscila Apocalypse, I'm 27 years old and live at Campinas 
 - Sao Paulo,
 Brazil. My first contact with Linux was approximately 7 years ago and
 since that year I have been working with Linux kernel (new 
 development for embedded/device drivers and bug fixing)  and recently 
 (2 years) with Android framework/kernel (new modules and API's)
 
 I'm sending my contacts fell free if anyone want to contact me:
 
 Skype: priscila.apocalypse
 IRC: pryxas at irc.freenode.net
 gtalk: priscila.apocalypse
 twitter : priscil4_
 LinkedIn: 
 https://br.linkedin.com/pub/priscila-pereira-apocalypse/29/4a9/374
 
 I hope to contribute asap! :)
 
 -- 
 ---
 Regards,
 
 Priscila P. Apocalypse.
 
 

Welcome to our team Priscila,

you can find some information about how to start here [1]. You come to
as in the right time as we are at the beginning of F23 testing. First
testing compose is on the way so you can take a look on it when it will
be out.

You can also test updates for F2{1,2} (fedora-gooey-karma utility is
very helpfull for this). I would also recommend to follow our callendar
for upcoming events (such as test days and meetings) - [2].

If you have some question you can ask them by irc (freenode - #fedora
-qa) or here on the mailing list. One more time - welcome to the team
and enjoy making fedora better.

With best regards
Petr Schindler


[1] https://fedoraproject.org/wiki/QA/Join
[2] https://apps.fedoraproject.org/calendar/QA/

 
 
 
 -- 
 test mailing list
 test@lists.fedoraproject.org
 To unsubscribe:
 https://admin.fedoraproject.org/mailman/listinfo/test

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[Test-Announce] Fedora 22 Final Release Candidate 3 (RC3) Available Now!

[Petr Schindler]

As per the Fedora 22 schedule [1], Fedora 22 Final Release Candidate 3
(RC3) is now available for testing.

Content information, including changes, can be found at
https://fedorahosted.org/rel-eng/ticket/6166#comment:14. Please see 
the following pages for download links and testing instructions. 
Normally dl.fedoraproject.org should provide the fastest download, but 
download-ib01.fedoraproject.org is available as a mirror (with an 
approximately 1 hour lag) in case of trouble. To use it, just replace 
dl with download-ib01 in the download URL.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Workstation and Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Server:

https://fedoraproject.org/wiki/Test_Results:Current_Server_Test

Cloud:

https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test

Summary:

https://fedoraproject.org/wiki/Test_Results:Current_Summary

All Final priority test cases for each of these test pages [2] must  
pass in order to meet the Final Release Criteria [3]. Help is available
on #fedora-qa on irc.freenode.net [4], or on the test list [5].

Create Fedora 22 Final test compose (TC) and release candidate (RC)  
https://fedorahosted.org/rel-eng/ticket/6166

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1]  
http://fedorapeople.org/groups/schedule/f-22/f-22-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://admin.fedoraproject.org/mailman/listinfo/test

-- 
// Mike 
--
Fedora QA
freenode: roshi
http://roshi.fedorapeople.org
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[Test-Announce] Fedora 22 Final Release Compose 1 (RC1) Available Now!

[Petr Schindler]

Fedora 22 Final Release Compose 1 (RC1) is now available for testing.
Please help us complete as much of the validation testing as we can!

This is first release compose so everything should be tested properly.

Content information, including changes, can be found at 
https://fedorahosted.org/rel-eng/ticket/6166#comment:9 . Please see the
following pages for
download links and testing instructions. Normally dl.fedoraproject.org 
should provide the fastest download, but download-
ib01.fedoraproject.org is available as a mirror (with an approximately 
1 hour lag) in case of trouble. To use it, just replace dl with 
download-ib01 in the download URL.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Workstation and Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Server:

https://fedoraproject.org/wiki/Test_Results:Current_Server_Test

Cloud:

https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test

Summary:

https://fedoraproject.org/wiki/Test_Results:Current_Summary

All non-Optional test cases for each of these test pages [2] must 
pass in order to meet the Final Release Criteria [3].

Help is available on #fedora-qa on irc.freenode.net [4], or on the 
test list [5].

Create Fedora 22 Final test compose (TC) and release candidate (RC) 
https://fedorahosted.org/rel-eng/ticket/6166

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

Fedora 22 QA schedule: 
http://fedorapeople.org/groups/schedule/f-22/f-22-quality-tasks.html

[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://admin.fedoraproject.org/mailman/listinfo/test
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[Test-Announce] FedUp Tesday tomorrow

[Petr Schindler]

Hi all,

there is going to be FedUp [0] test day tomorrow (April 21st). You can 
join us to test Fedora's upgrading tool. The main purpose is to test 
that transition from yum to dnf and usage of different depsolving in 
Fedora 22 won't break upgrades.

If you will find some time to help us with testing, you can visit test 
day page [1], where you will find all the needed information, test 
cases and place to save your results.

You can also find someone to help you on irc channel #fedora-test-day 
on freenode.


Best regards
Petr Schindler, Fedora QA

[0] https://fedoraproject.org/wiki/FedUp
[1] https://fedoraproject.org/wiki/Test_Day:2015-04-21_FedUp
___
test-announce mailing list
test-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce

[Test-Announce] FedUp Tesday tomorrow

[Petr Schindler]

Hi all,

there is going to be FedUp [0] test day tomorrow (April 21st). You can 
join us to test Fedora's upgrading tool. The main purpose is to test 
that transition from yum to dnf and usage of different depsolving in 
Fedora 22 won't break upgrades.

If you will find some time to help us with testing, you can visit test 
day page [1], where you will find all the needed information, test 
cases and place to save your results.

You can also find someone to help you on irc channel #fedora-test-day 
on freenode.


Best regards
Petr Schindler, Fedora QA

[0] https://fedoraproject.org/wiki/FedUp
[1] https://fedoraproject.org/wiki/Test_Day:2015-04-21_FedUp
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Regarding Self Introduction (Ashutosh Bhakare)

[Petr Schindler]

On Út, 2015-04-14 at 11:54 +0530, Ashutosh Bhakare wrote:
 hi All
 
 
 My name is Ashutosh Bhakare; I am currently Trainer / Owner @ Red Hat
 Authorised Training Institute located in Aurangabad MS India. 
 
 I am eager to work with QA team; I am having 14+ years experience in 
 C C
 ++, Java. Since 6 years teaching RedHat Linux Courses too.
 
 Willing to contribute in QA team. 
 
 Looking forward for positive reply.
 
 Regards
 Ashutosh S.Bhakare 
 
Hi Ashutosh,

welcome to QA. You can find some information about how to start here 
[1]. Today there is ABRT test day [2] so you can start with that. Also 
we can use some help with RC2 testing which was release today. Look on 
[3]. If you need something you can ask on irc (freenode #fedora-qa).

[1] https://fedoraproject.org/wiki/QA/Join
[2] https://fedoraproject.org/wiki/Test_Day:2015-04-14_ABRT
[3] 
https://lists.fedoraproject.org/pipermail/test-announce/2015-April/001040.html

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How To Do Testing (was: Re: test Digest, Vol 134, Issue 49)

[Petr Schindler]

On Po, 2015-04-13 at 16:38 +, Andre Robatino wrote:
 Kalev Lember kalevlember at gmail.com writes:
 
  4) Run 'fedora-easy-karma' daily, and give -1 karma to updates that
  regress anything and +1 karma to those that don't
 
 Chances are f-e-k won't work. See
  https://bugzilla.redhat.com/show_bug.cgi?id=1144587and
  https://fedorahosted.org/bodhi/ticket/778. You'll have to use the 
 bodhi web
 interface to give karma.

Or there is also gui application - fedora-gooey-karma it works well 
and it makes updates testing quite easy task.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[Test-Announce] 2015-03-24 Fedora 22 Cockpit Test Day

[Petr Schindler]

The Fedora Project holds regular Test Days to help put releases or 
individual components through their paces. Tomorrow, Fedora’s Test Day 
will focus on Cockpit.

Cockpit is a modern lightweight server admin interface:

http://cockpit-project.org/

Cockpit comes by default in Fedora Server 22.

When: Tuesday, 2015-03-24

Where: https://fedoraproject.org/wiki/Test_Day:2015-03-24_Cockpit
   #fedora-test-day at Freenode

You can download the test images from here: 
https://fedorapeople.org/groups/qa/test_days/

You're welcome to join in. See you tomorrow o/

Stef
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[Test-Announce] 2015-03-24 Fedora 22 Cockpit Test Day

[Petr Schindler]

The Fedora Project holds regular Test Days to help put releases or 
individual components through their paces. Tomorrow, Fedora’s Test Day 
will focus on Cockpit.

Cockpit is a modern lightweight server admin interface:

http://cockpit-project.org/

Cockpit comes by default in Fedora Server 22.

When: Tuesday, 2015-03-24

Where: https://fedoraproject.org/wiki/Test_Day:2015-03-24_Cockpit
   #fedora-test-day at Freenode

You can download the test images from here: 
https://fedorapeople.org/groups/qa/test_days/

You're welcome to join in. See you tomorrow o/

Stef
___
test-announce mailing list
test-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce

[Test-Announce] Fedora 21 Alpha Test Compose 7 (TC7) Available Now!

[Petr Schindler]

As per the Fedora 21 schedule [1], Fedora 21 Alpha Test Compose 7 (TC7)
is now available for testing. Content information, including changes,
can be found at
https://fedorahosted.org/rel-eng/ticket/5940#comment:11 .
Please see the following pages for download links (including delta ISOs)
and testing instructions. Normally dl.fedoraproject.org should provide
the fastest download, but download-ib01.fedoraproject.org is available
as a mirror (with an approximately 1 hour lag) in case of trouble. To
use it, just replace dl with download-ib01 in the download URL.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Workstation and Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Server:

https://fedoraproject.org/wiki/Test_Results:Current_Server_Test

Ideally, all Alpha priority test cases for each of these test pages [2]
should pass in order to meet the Alpha Release Criteria [3]. Help is
available on #fedora-qa on irc.freenode.net [4], or on the test list
[5].

Create Fedora 21 Alpha test compose (TC) and release candidate (RC)
https://fedorahosted.org/rel-eng/ticket/5940

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-21/f-21-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://admin.fedoraproject.org/mailman/listinfo/test


___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[Test-Announce] Fedora 21 Alpha Test Compose 7 (TC7) Available Now!

[Petr Schindler]

As per the Fedora 21 schedule [1], Fedora 21 Alpha Test Compose 7 (TC7)
is now available for testing. Content information, including changes,
can be found at
https://fedorahosted.org/rel-eng/ticket/5940#comment:11 .
Please see the following pages for download links (including delta ISOs)
and testing instructions. Normally dl.fedoraproject.org should provide
the fastest download, but download-ib01.fedoraproject.org is available
as a mirror (with an approximately 1 hour lag) in case of trouble. To
use it, just replace dl with download-ib01 in the download URL.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Workstation and Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Server:

https://fedoraproject.org/wiki/Test_Results:Current_Server_Test

Ideally, all Alpha priority test cases for each of these test pages [2]
should pass in order to meet the Alpha Release Criteria [3]. Help is
available on #fedora-qa on irc.freenode.net [4], or on the test list
[5].

Create Fedora 21 Alpha test compose (TC) and release candidate (RC)
https://fedorahosted.org/rel-eng/ticket/5940

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-21/f-21-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://admin.fedoraproject.org/mailman/listinfo/test


___
test-announce mailing list
test-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce

[Test-Announce] Fedora 21 Alpha Test Compose 5 (TC5) Available Now!

[Petr Schindler]

NOTE: There are no cloud images in TC5 due to some issue with anaconda
and kickstart parsing.

As per the Fedora 21 schedule [1], Fedora 21 Alpha Test Compose 5 (TC5)
is now available for testing. Content information, including changes,
can be found at https://fedorahosted.org/rel-eng/ticket/5940#comment:7
. Please see the following pages for download links (including delta
ISOs) and testing instructions. Normally dl.fedoraproject.org should
provide the fastest download, but download-ib01.fedoraproject.org is
available as a mirror (with an approximately 1 hour lag) in case of
trouble. To use it, just replace dl with download-ib01 in the
download URL.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Server:

https://fedoraproject.org/wiki/Test_Results:Current_Server_Test

Ideally, all Alpha priority test cases for Installation [2], Base [3],
and Desktop [4] should pass in order to meet the Alpha Release Criteria
[5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the
test list [7].

Create Fedora 21 Alpha test compose (TC) and release candidate (RC)
https://fedorahosted.org/rel-eng/ticket/5940

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1]
https://fedorapeople.org/groups/schedule/f-21/f-21-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[3] https://fedoraproject.org/wiki/QA:Base_validation_testing
[4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
[5] https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria
[6] irc://irc.freenode.net/fedora-qa
[7] https://admin.fedoraproject.org/mailman/listinfo/test


___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[Test-Announce] 2014-08-13 @ 16:00 UTC ** F21 Blocker Review #6

[Petr Schindler]

# F21 Blocker Review meeting #6
# Date: 2014-08-13
# Time: 16:00 UTC (12:00 EDT, 09:00 PDT)
# Location: #fedora-blocker-review on irc.freenode.net

We've got another blocker meeting coming up this week. As of today
there are 6 proposed blockers and 1 proposed FE for F21 Alpha. The full
list can be found here:
https://qa.fedoraproject.org/blockerbugs/milestone/21/alpha/buglist

We'll be evaluating these bugs to see if they violate the Alpha
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F21 can be found on the
wiki [0]. Product specific plans are still being solidified, but that
should be sorted quickly.

For more information about the Blocker and Freeze exception process,
check out these links:
  - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
  - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go - check out the SOP on the wiki:
  - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

See you in 213 minutes!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria




___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

2014-08-13 @ ** 16:00 UTC ** - F21 Blocker Review #6 Minutes

[Petr Schindler]

==
#fedora-blocker-review: F21-blocker-review-6
==


Meeting started by pschindl at 16:00:03 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-blocker-review/2014-08-13/f21-blocker-review.2014-08-13-16.00.log.html
.



Meeting summary
---
* Roll Call  (pschindl, 16:00:03)

* Introduction  (pschindl, 16:02:15)
  * Our purpose in this meeting is to review proposed blocker and
nice-to-have bugs and decide whether to accept them, and to monitor
the progress of fixing existing accepted blocker and nice-to-have
bugs.  (pschindl, 16:02:15)
  * We'll be following the process outlined at:  (pschindl, 16:02:15)
  * LINK: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
(pschindl, 16:02:15)
  * The bugs up for review today are available at:  (pschindl, 16:02:16)
  * LINK: http://qa.fedoraproject.org/blockerbugs/current   (pschindl,
16:02:16)
  * The criteria for release blocking bugs can be found at:  (pschindl,
16:02:17)
  * LINK:
https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria
(pschindl, 16:02:17)
  * LINK: https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria
(pschindl, 16:02:18)
  * LINK:
https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria
(pschindl, 16:02:18)
  * 7 Proposed Blockers  (pschindl, 16:03:25)
  * 6 Accepted Blockers  (pschindl, 16:03:25)
  * 1 Proposed Freeze Exceptions  (pschindl, 16:03:25)
  * 0 Accepted Freeze Exceptions  (pschindl, 16:03:25)

* (1127280) OSError: [Errno 2] No such file or directory  (pschindl,
  16:03:34)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1127280
(pschindl, 16:03:34)
  * Proposed Blocker, anaconda, NEW  (pschindl, 16:03:34)
  * We will discuss bug 1127280 after bug 1127103 will be resolved.
(pschindl, 16:05:36)

* (1129507) Anaconda deletes default EFI boot entry  (pschindl,
  16:06:40)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1129507
(pschindl, 16:06:41)
  * Proposed Blocker, anaconda, NEW  (pschindl, 16:06:41)
  * AGREED: - 1129507 - RejectedBlocker - Anaconda doesn't support UEFI
multiboot of Fedoras yet.  (pschindl, 16:28:43)

* (1129629) Anaconda doesn't recognize insufficient size of /boot
  partition  (pschindl, 16:29:25)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1129629
(pschindl, 16:29:25)
  * Proposed Blocker, anaconda, ASSIGNED  (pschindl, 16:29:25)
  * AGREED: - 1129629 - RejectedBlocker - Creating small /boot partition
involves custom partitioning which is in beta criterion. Reproposing
for beta blocker.  (pschindl, 16:35:13)

* (1129695) please provide minimal iso images for offline use
  (pschindl, 16:35:34)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1129695
(pschindl, 16:35:34)
  * Proposed Blocker, distribution, NEW  (pschindl, 16:35:34)
  * AGREED: - 1129695 - RejectedBlocker - Demand for minimal isos
doesn't violate any criterion. This is feature request which should
be discussed elsewhere.  (pschindl, 16:43:10)

* (1127450) Black screen after userless installation of KDE live
  (pschindl, 16:43:26)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1127450
(pschindl, 16:43:27)
  * Proposed Blocker, initial-setup, ON_QA  (pschindl, 16:43:27)
  * AGREED: - 1127450 - AcceptedBlocker - This bug clearly violates the
alpha criterion: A working mechanism to create a user account must
be clearly presented during installation and/or first boot of the
installed system.  (pschindl, 16:50:30)

* (1128675) missing crucial specfile changes  (pschindl, 16:50:42)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1128675
(pschindl, 16:50:42)
  * Proposed Blocker, java-1.8.0-openjdk, ASSIGNED  (pschindl, 16:50:42)
  * AGREED: - 1128675 - RejectedBlocker - Missing components in specfile
isn't blocker by itself. If needed this could be re-proposed as
Freeze Exception  (pschindl, 17:04:56)

* (1119251) [abrt] tracker: vasprintf(): tracker-store killed by SIGSEGV
  (pschindl, 17:05:18)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1119251
(pschindl, 17:05:18)
  * Proposed Blocker, tracker, ASSIGNED  (pschindl, 17:05:18)
  * AGREED: - 1119251 - RejectedBlocker - This seems to happen only on
upgraded systems which doesn't block alpha. If this is still an
issue at beta with fedup upgrades, please re-propose as a beta
blocker if it violates any of those criteria  (pschindl, 17:11:59)

* (1127103) Workstation image compose sometimes fails due to filesystem
  consistency issues (caused by sssd library being held open)
  (pschindl, 17:15:57)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1127103
(pschindl, 17:15:57)
  * Accepted Blocker, distribution, NEW  (pschindl, 17:15:57)
  * Releng team works hard on bug 1127103. No need for action from our
side for now.  (pschindl, 17:18:10)

* (1109603) dracut unable to boot 

Re: Testcase Review

[Petr Schindler]

Mike Ruckman píše v Čt 17. 07. 2014 v 11:29 -0600:
 Greetings Testers!
 
 I've been working on some testcases and general wiki work for the Cloud
 SIG [0]. While I was doing this I created a few testcases and edited a
 couple of our others. I'd like to these get reviewed and placed on the 
 matrices.

Hi Mike,
sorry for late response. I went through testcases you wrote and it looks
fine to me, we should use them in matrices. I have just two questions:

 
 Below is a list of what I've done so far:
 
 * Desktop Updates
 
   Split out the command line bits into their own testcase.
 
   Edited version:
 https://fedoraproject.org/wiki/User:Roshi/QA/Testcase_Desktop_updates

In point 4 of How to test you suggest to use the yum, but in Expected
results you talk just about graphical update. Shouldn't yum be there
too?

   New CLI updates testcase:
 https://fedoraproject.org/wiki/User:Roshi/QA/Testcase_CLI_updates

What is point 3 of How to test for? Isn't it just leftover from
copy-paste (I guess)?

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

F20 Final Blocker Bug Review #2 Minutes

[Petr Schindler]

#fedora-blocker-review: f20final-blocker-review-2


Minutes:
http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-20/f20-blocker-review.2013-11-20-17.00.html
Minutes (text):
http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-20/f20-blocker-review.2013-11-20-17.00.txt
Log:
http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-20/f20-blocker-review.2013-11-20-17.00.log.html

Meeting summary
---
* Roll Call  (pschindl, 17:00:42)

* Introduction  (pschindl, 17:03:30)
  * Our purpose in this meeting is to review proposed blocker and
nice-to-have bugs and decide whether to accept them, and to monitor
the progress of fixing existing accepted blocker and nice-to-have
bugs.  (pschindl, 17:03:44)
  * We'll be following the process outlined at:  (pschindl, 17:03:47)
  * LINK: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
(pschindl, 17:03:49)
  * The bugs up for review today are available at:  (pschindl, 17:03:51)
  * LINK: http://qa.fedoraproject.org/blockerbugs/current   (pschindl,
17:03:53)
  * The criteria for release blocking bugs can be found at:  (pschindl,
17:03:55)
  * LINK:
https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria
(pschindl, 17:03:57)
  * LINK: https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
(pschindl, 17:03:59)
  * LINK:
https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria
(pschindl, 17:04:01)
  * 9 Proposed Blockers  (pschindl, 17:04:12)
  * 14 Accepted Blockers  (pschindl, 17:04:15)
  * 2 Proposed Freeze Exceptions  (pschindl, 17:04:17)
  * 4 Accepted Freeze Exceptions  (pschindl, 17:04:19)

* (1029616) ValueError: ('invalid size specification', '0.00 MB')
  (pschindl, 17:05:45)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1029616
(pschindl, 17:05:47)
  * Proposed Blocker, anaconda, NEW  (pschindl, 17:05:49)
  * AGREED: 1029616 - AcceptedBlocker - Anaconda crashes when some
languages are choosen for installation (for example French). This
violates the criterion: The installer must run when launched
normally from the release-blocking images.  (pschindl, 17:13:37)

* (1032620) Doesn't remember POP password  (pschindl, 17:13:56)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1032620
(pschindl, 17:13:59)
  * Proposed Blocker, evolution, NEW  (pschindl, 17:14:01)
  * AGREED: #1032620 would be accepted as a blocker so long as it can be
reproduced from a fresh install by someone else. roshi will attempt
to reproduce and mark as accepted if so  (adamw, 17:23:07)

* (1013280) Slideshow in Anaconda 20.21 is only in Enlish language while
  in other distros like Ubuntu the language of the slideshow in the
  installer is according to the selected language for installation
  (pschindl, 17:23:34)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1013280
(pschindl, 17:23:37)
  * Proposed Blocker, fedora-logos, MODIFIED  (pschindl, 17:23:39)
  * AGREED: 1013280 - RejectedBlocker AcceptedFreezeException -
Translation in ad banners doesn't break any criteria. But it's worth
to have possibility of having translated banners. The size of images
have to be checked after this patch is pushed.  (pschindl, 17:31:51)

* (960381) gnome-shell eats a lot of mem  (pschindl, 17:32:12)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=960381
(pschindl, 17:32:15)
  * Proposed Blocker, gnome-shell, NEW  (pschindl, 17:32:17)
  * This bug needs more info to have good decision. We will discuss it
next time  (pschindl, 17:41:48)

* (1031530) Switching between messages in message-tray doesn't work
  (pschindl, 17:42:34)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1031530
(pschindl, 17:42:37)
  * Proposed Blocker, gnome-shell, NEW  (pschindl, 17:42:39)
  * AGREED: 1031530 - RejectedBlocker - Even though the notification
area doesn't work properly basic funtionality is working well. There
is no need to block release.  (pschindl, 17:50:57)

* (1031848) xkb-converted layouts do not include multiple mappings where
  they are commonly expected  (pschindl, 17:51:07)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1031848
(pschindl, 17:51:10)
  * Proposed Blocker, kbd, NEW  (pschindl, 17:51:12)
  * AGREED: 1031848 - AcceptedBlocker - Impossibility of changing layout
in console makes console unusable for some layouts (for example
russian).  (pschindl, 18:02:01)

* (1026860) Instantiated service is not run, it stays in inactive state
  (and systemd debug log does not state why)  (pschindl, 18:02:21)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1026860
(pschindl, 18:02:23)
  * Proposed Blocker, lvm2, NEW  (pschindl, 18:02:25)
  * There are still some information missing. We will try to get more
information and return to this bug next meeting  (pschindl,
18:13:24)

* (1026283) 

Re: Fedora 20 Swastika

[Petr Schindler]

On Čt, 2013-11-21 at 07:57 +0200, Gilboa Davara wrote:
 On Tue, Nov 19, 2013 at 9:25 PM, James Patterson
 jamespatter...@operamail.com wrote:
 
  Hello,
 
  I noticed the new Fedora 20 wallpaper looks like a swastika. It would be
  great if it didn't for the final release, it would upset a few people.
 
  I filed a bug here under wallpapers, but moved it to distro since it's a
  policy decision:
   https://bugzilla.redhat.com/show_bug.cgi?id=1030643
 
 
 Hi,
 
 I do see the swastika, but it you I doubt that I would have seen it
 unless I knew what I was looking for.
 In my view, given the fact that the image was never designed to
 resemble the swastika, there's no reason to change it.

Hi,

I'm trying to see swastika there but I haven't been able to do so. There
is nothing what could be interpreted as swastika. Can someone draw it
and send a picture? I think that this thread is totally insane and sad.
But it is probably because people always tend to see things they don't
like everywhere (like conspiracies).

Petr Schindler

 
 ... Just to be safe, we can always add a small Israeli flag on the
 bottom right :P
 
 - Gilboa
 (Note: I'm Jewish and Israeli :))


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

F20 Beta Blocker Bug Review #7 Minutes

[Petr Schindler]

#fedora-blocker-review: f20beta-blocker-review-7


Minutes:
http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-06/f20-blocker-review.2013-11-06-17.00.html
Minutes (text):
http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-06/f20-blocker-review.2013-11-06-17.00.txt
Log:
http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-06/f20-blocker-review.2013-11-06-17.00.log.html


Meeting summary
---
* Roll Call  (pschindl, 17:00:27)

* Introduction  (pschindl, 17:02:42)
  * Our purpose in this meeting is to review proposed blocker and
nice-to-have bugs and decide whether to accept them, and to monitor
the progress of fixing existing accepted blocker and nice-to-have
bugs.  (pschindl, 17:02:51)
  * We'll be following the process outlined at:  (pschindl, 17:02:53)
  * LINK: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
(pschindl, 17:02:55)
  * The bugs up for review today are available at:  (pschindl, 17:02:57)
  * LINK: http://qa.fedoraproject.org/blockerbugs/current   (pschindl,
17:02:59)
  * The criteria for release blocking bugs can be found at:  (pschindl,
17:03:01)
  * LINK:
https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria
(pschindl, 17:03:03)
  * LINK: https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
(pschindl, 17:03:05)
  * LINK:
https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria
(pschindl, 17:03:07)
  * 6 Proposed Blockers  (pschindl, 17:04:26)
  * 10 Accepted Blockers  (pschindl, 17:04:28)
  * 3 Proposed Freeze Exceptions  (pschindl, 17:04:30)
  * 12 Accepted Freeze Exceptions  (pschindl, 17:04:32)

* (1027160) Kickstarts don't work on Live  (pschindl, 17:04:46)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1027160
(pschindl, 17:04:48)
  * Proposed Blocker, anaconda, NEW  (pschindl, 17:04:50)
  * AGREED: 1027160 - RejectedBlocker - Kickstarts aren't supposed to
work with livecd. Kickstarts work fine with pxe and netinst.
(pschindl, 17:10:55)

* (1000669) [abrt] florence-0.6.0-1.fc20: gtk_main_do_event: Process
  /usr/bin/florence was killed by signal 11 (SIGSEGV)  (pschindl,
  17:11:16)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1000669
(pschindl, 17:11:18)
  * Proposed Blocker, florence, NEW  (pschindl, 17:11:20)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1000752
(pschindl, 17:16:51)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1000756
(pschindl, 17:17:05)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1007121
(pschindl, 17:17:17)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1015347   (tflink,
17:21:24)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1016935   (tflink,
17:21:35)
  * AGREED: 1000669 1000752 1000756 1007121 1015347 1016935 -
RejectedBlocker - All these crashes (reported by abrt) don't have
reproducers and aren't in crucial components. We can re-propose them
later when reproducers are known.  (pschindl, 17:29:15)

* (1026466) blivet shows existing LVs as not taking up any space in the
  VG  (pschindl, 17:29:57)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1026466
(pschindl, 17:29:59)
  * Proposed Blocker, python-blivet, ASSIGNED  (pschindl, 17:30:01)
  * AGREED: 1026466 - AcceptedBlocker - This bug lets user to set a
layout which cannot be created. Also it violates criterion: When
using the custom partitioning flow, the installer must be able to:
Correctly interpret, and modify as described below, any disk with a
valid ms-dos or gpt disk label and partition table containing ext4
partitions, LVM and/or btrfs volumes, and/or software RAID arrays at
RAID levels 0, 1 and 5 co  (pschindl, 17:38:21)

* (929177) in text install, Create user and Set root password are
  swapped in i386 vs. x86_64  (pschindl, 17:39:23)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=929177
(pschindl, 17:39:25)
  * Proposed Freeze Exceptions, anaconda, POST  (pschindl, 17:39:27)
  * AGREED: 929177 - RejectedFreezeException - Fix for this bug can
bring more problems then benefits to bring it before go/no-go.Please
push the patch once Beta freeze is over.  (pschindl, 17:45:36)

* (1025347) kickstart sometimes hangs in summary hub  (pschindl,
  17:45:51)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1025347
(pschindl, 17:45:53)
  * Proposed Freeze Exceptions, anaconda, ON_QA  (pschindl, 17:45:55)
  * Fix for 1025347 has been already pulled. Skipping to more important.
(pschindl, 17:48:48)

* (1004621) plasma-nm doesn't attempt to connect to any listed networks
  on Fedora KDE live  (pschindl, 17:50:16)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1004621
(pschindl, 17:50:18)
  * Proposed Freeze Exceptions, kde-plasma-nm, ASSIGNED  (pschindl,
17:50:20)
  * AGREED: 1004621 - 

Alpha karma requests

[Petr Schindler]

Hi testers.

There are updates which needs your attention. They needs to be pushed to
the stable, so please test them and add karma.

* solves blocker bug:
1.
https://admin.fedoraproject.org/updates/FEDORA-2013-16308/kde-settings-20-1.fc20,schroedinger-cat-kde-theme-18.91.6-2.fc20,heisenbug-kde-theme-19.90.2-1.fc20

* solve FE:
2. https://admin.fedoraproject.org/updates/lorax-20.1-1.fc20
3. https://admin.fedoraproject.org/updates/rdesktop-1.8.0-2.fc20
4. https://admin.fedoraproject.org/updates/sagemath-5.10-3.fc20

If you haven't done updates testing yet here is how it's done:
1. Install the update (download the build from koji or use 'yum install
--enablerepo=updates-testing name of package)
2. Test it - look if it works correctly
3. ...
4. Profit! (Get new badge!!!)

Thank you!


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Blocker process: tracker bug / whiteboard naming proposal

[Petr Schindler]

On Po, 2013-01-21 at 04:48 -0500, Kamil Paral wrote:
  The proposal is this:
  
  fXXalpha
  fXXalpha-freezebreak
  fXXbeta
  fXXbeta-freezebreak
  fXXfinal
  fXXfinal-freezebreak
  
  acceptedblocker
  acceptedfb
 
 Big thumbs up. A few things for consideration:
 
 1. Do we need numbers in the alias? We always release just a single Fedora at 
 a time.
 
 2. Do we need F in the alias? Unless our aliases clash, we don't need to 
 distinguish Fedora from the other projects in Bugzilla.
 
 3. As Jared mentioned, a freeze exception sounds better (and explains 
 better) than a freeze break. Unfortunately it's longer.
 
 
 So we can end up also with this:
 AlphaBlocker
 AlphaFreezeException
 BetaBlocker
 BetaFreezeException
 FinalBlocker
 FinalFreezeException
 
 
 But that's just an idea. Your proposal above is great improvement as well and 
 I don't have any objections to it.

That sounds great. Easy to remember, easy to use :) I'm +1. 

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[test-case] kickstarts and release notes TC

[Petr Schindler]

Hi,

as part of my work on final criteria/test cases interconnection I wrote
this test case [1]. It should check that criteria:

* A spin-kickstarts package which contains the exact kickstart files
used to build the release must be present in the release repository. The
included kickstarts must define the correct set of release repositories 
*  The final branded release notes from the Documentation team must be
present on ISO media and the appropriately versioned generic release
notes must be available in the online release repository 
*  A fedora-release package containing the correct names, information
and repository configuration for a final Fedora release (as opposed to a
pre-release) must be present on ISO media while the appropriately
versioned Package-x-generic-16.pnggeneric-release package must be
available in the online release repository 

are properly tested.

Please if send me any suggestions or objections you have.

Thank you
Petr Schindler

[1]
https://fedoraproject.org/wiki/User:Pschindl/Draft_QA_Testcase_Repository_completeness


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Final criteria/Test cases interconnection

[Petr Schindler]

On Út, 2012-12-04 at 10:02 -0800, Adam Williamson wrote:
 On Tue, 2012-12-04 at 17:28 +0100, Petr Schindler wrote:
  Obsolete TCs:
  * Hardware and BIOS RAID TCs -  Do we support those now?
 
 Yes. Why would they be obsolete?
 
  https://fedoraproject.org/wiki/QA:Testcase_dualboot_with_windows
 
 Ditto?

I'm sorry, my fault, I used wrong word. The right word is outdated.
Those TCs should be amended to reflect changes in anaconda.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Final criteria/Test cases interconnection

[Petr Schindler]

Final release criteria:
http://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria

I went through all criteria and connect them to test cases. I found
following problems:

We don't have TCs for: 
* The release live images must properly support mounting and using a
persistent storage overlay for the entire system and/or one for
the /home partition, if such an overlay or overlays have been correctly
written to the medium from which the image is booted
* All critical path actions on release-blocking desktop environments
should correctly display all sufficiently complete translations
available for use - I don't think that this one is needed
* All known bugs that can cause corruption of user data must be fixed or
documented at Common F18 bugs - it doesn't make sence to have TC for
this one.
* No notices or alerts about pre-release status should be present -
there is no TC for anaconda
* The release must contain no known security bugs of 'important' or
higher impact according to the Red Hat severity classification scale
which cannot be satisfactorily resolved by a package update (e.g. issues
during installation) - I don't think we need TC for this.
* A Package-x-generic-16.pngspin-kickstarts package which contains the
exact kickstart files used to build the release must be present in the
release repository. The included kickstarts must define the correct set
of release repositories
* The final branded release notes from the Documentation team must be
present on ISO media and the appropriately versioned generic release
notes must be available in the online release repository
* A Package-x-generic-16.pngfedora-release package containing the
correct names, information and repository configuration for a final
Fedora release (as opposed to a pre-release) must be present on ISO
media while the appropriately versioned
Package-x-generic-16.pnggeneric-release package must be available in the
online release repository

Obsolete TCs:
* Hardware and BIOS RAID TCs -  Do we support those now?
https://fedoraproject.org/wiki/QA:Testcase_dualboot_with_windows

Other problems:
* I'm not sure which network-attached storage devices are supported. We
have only this 
https://fedoraproject.org/wiki/QA:Testcase_EC2_AMI_Validation

Here is summary of all criteria/TC interconnections:
1. All Fedora 18 Beta Release Criteria must be met 
2. All bugs blocking the F18Blocker tracker must be CLOSED 
3. If there is an embedded checksum in the image, it must match. If
there is a related UI element displayed after booting the image, it must
work and display the correct result -
https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Checksums
4. The release live images must properly support mounting and using a
persistent storage overlay for the entire system and/or one for
the /home partition, if such an overlay or overlays have been correctly
written to the medium from which the image is booted - we don't have
test case for this
5. The installer must be able to use all supported local and remote
package source options - We have TC for: DVD, mirrorlist, http, ftp, nfs
and nfsiso
6. The installer must be able to complete an installation using any
network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel) -
Only TC we have now is
https://fedoraproject.org/wiki/QA:Testcase_EC2_AMI_Validation Are other
devices supported in F18?
7. The installer must be able to complete an installation using all
supported interfaces - We have TCs for: graphical, basic video driver,
text, vnc and serial console
8. The installer must be able to create and install to any workable
partition layout using any file system offered in a default installer
configuration, LVM, software, hardware or BIOS RAID, or combination of
the above - We have TCs for: custom partitioning, software, hardware and
BIOS RAID. Hardware and BIOS RAID TCs are obsolete.
9. The installer must be able to install into free space alongside an
existing clean single-partition Windows installation and either install
a bootloader which can boot into the Windows installation, or leave the
Windows bootloader untouched and working -
https://fedoraproject.org/wiki/QA:Testcase_dualboot_with_windows it is
obsolete.
10. The installer must be able to use an installer update image
retrieved from removable media, remote installation source and HTTP
server - We have TCs for: URL, inst. source and local media
11. For each one of the release-blocking package sets ('minimal', and
the package sets for each one of the release-blocking desktops), it must
be possible to successfully complete an upgrade from a fully updated
installation of the previous stable Fedora release with that package set
installed, using all officially recommended upgrade mechanisms. The
upgraded system must meet all release criteria -  The only TC we have is
https://fedoraproject.org/wiki/QA:Testcase_upgrade_fedup_cli_previous_desktop
12. The release must boot successfully as Xen DomU with releases
providing a functional, supported Xen 

Re: How to set up layout switch shortcut

[Petr Schindler]

Hi,

There is a link to 'Shortcut Settings' in 'Regional  Language'-'Input
Sources'. You can set up the shortcut for switching to next source (and
previous).

On Po, 2012-12-03 at 13:46 +0200, Pasha R wrote:
 I'm trying to set up keyboard layout switching in F18 beta. I addeds
 needed layouts in Regional  Language, but I can't see where is the
 option for layout switching. Currently, the only way to switch layout
 which works is clicking on layout indicator on panel, but it is not an
 acceptable solution.
 
 Am I missing something trivial here?
 
 Thanks.


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Update of uncategorized package groups criterion

[Petr Schindler]

On Út, 2012-09-11 at 14:59 +0200, Petr Schindler wrote:
 On Čt, 2012-09-06 at 10:08 -0700, Adam Williamson wrote:
  On 2012-09-06 6:54, Kamil Paral wrote:
   Hi,
  
   we should amend the beta criterion:
  
   'At the package installation stage, the install should show no
   uncategorized package groups'
  
   There should be something like 'Software selection spoke' instead of
   'package installation stage', also I'm not sure if 'uncategorized
   package groups' makes sense. I would propose to change it to:
  
   'At the software selection spoke, there mustn't be any uncategorized
   package groups'
  
   Another option is to remove this criterion. The software selection 
   is
   changed in new ui and I'm not sure if this criterion is still
   applicable.
  
   First of all, I don't like the word 'spoke'. I know anaconda
   developers use it internally, but people from outside won't have any
   idea what it means. We need a better term.
  
   Secondly, it seems this criterion is no longer needed at all. In old
   Anaconda there used to be categories of software and this was to make
   sure every software is categorized (not in some kind of Other
   category). Now we have some add-ons, but without categories. So I
   don't think this criterion really applies anymore.
  
   Of course we can consider whether we need to add a new one, something
   similar but not the same (I don't see anything like it at the 
   moment).
   But this one should be deleted in any case, in my opinion.
  
  That sounds fairly reasonable to me. I guess we need to consider what 
  could 'break' about the list of groups displayed on the software 
  selection screen in newUI.
 
 OK, so it looks like this criterion is not usable anymore. If there are
 no objections I would delete it. If there will be some problem within
 package selection, we should create a new criterion which will be more
 accurate for newUI.

I went ahead and removed this criterion. If there will be some problems
with package selection in the future we will have to add new criterion.


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Package set

[Petr Schindler]

On Čt, 2012-09-06 at 09:57 -0700, Adam Williamson wrote:
 On 2012-09-06 0:59, Kamil Paral wrote:
  Hi,
 
  Because of changes in package set selection in new anaconda, I
  propose
  to amend the alpha criterion:
 
  'The installer must be able to complete package installation with 
  the
  default package set for each supported installation method'
 
  to:
 
  'The installer must be able to install the default desktop for each
  supported installation method (DVD, live, netinst, PXE, ...)'
 
  I chose default desktop because in f17 every installation method had
  it
  as default package set.
 
  It makes sense to adjust it, because there is no longer default
  package set. Also big thanks for clarifying what installation
  methods mean.
 
 Do we know if it's *intended* that there's no default package set, or 
 is that a bug? It only makes sense to amend the criterion if the lack of 
 a default package set is actually intended. Also, if it's intended that 
 there's no default package set, can there be said to be a 'default 
 desktop' any more? GNOME is only the 'default' in that it's the desktop 
 in the 'default package set'. If there's no 'default package set', GNOME 
 becomes simply a choice on the package set selection screen, co-equal 
 with all the others. I can't see how it can be called 'the default'.
 
  I wonder - we require only the default desktop (GNOME) to be
  installable, but we have further Alpha criteria for other
  release-blocking desktops (KDE)? That's funny :-)
 
  Maybe we should say:
  'The installer must be able to (successfully) install *all
  release-blocking desktops* for each supported installation method
  (DVD, live, netinst, PXE, ...)'
 
 I think that's better, if we assume the new behaviour in anaconda is 
 actually intended.

There is no default 'package set' now (by design, it's not a bug). User
has to choose something, so we can use the Kamil's version. It seems to
me reasonable to require installation of release blocking desktops in
Alpha phase.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Update of uncategorized package groups criterion

[Petr Schindler]

On Čt, 2012-09-06 at 10:08 -0700, Adam Williamson wrote:
 On 2012-09-06 6:54, Kamil Paral wrote:
  Hi,
 
  we should amend the beta criterion:
 
  'At the package installation stage, the install should show no
  uncategorized package groups'
 
  There should be something like 'Software selection spoke' instead of
  'package installation stage', also I'm not sure if 'uncategorized
  package groups' makes sense. I would propose to change it to:
 
  'At the software selection spoke, there mustn't be any uncategorized
  package groups'
 
  Another option is to remove this criterion. The software selection 
  is
  changed in new ui and I'm not sure if this criterion is still
  applicable.
 
  First of all, I don't like the word 'spoke'. I know anaconda
  developers use it internally, but people from outside won't have any
  idea what it means. We need a better term.
 
  Secondly, it seems this criterion is no longer needed at all. In old
  Anaconda there used to be categories of software and this was to make
  sure every software is categorized (not in some kind of Other
  category). Now we have some add-ons, but without categories. So I
  don't think this criterion really applies anymore.
 
  Of course we can consider whether we need to add a new one, something
  similar but not the same (I don't see anything like it at the 
  moment).
  But this one should be deleted in any case, in my opinion.
 
 That sounds fairly reasonable to me. I guess we need to consider what 
 could 'break' about the list of groups displayed on the software 
 selection screen in newUI.

OK, so it looks like this criterion is not usable anymore. If there are
no objections I would delete it. If there will be some problem within
package selection, we should create a new criterion which will be more
accurate for newUI.


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update]

[Petr Schindler]

On Čt, 2012-09-06 at 10:01 -0700, Adam Williamson wrote:
 On 2012-09-06 0:58, Petr Schindler wrote:
  Hi,
 
  I think that require LVM and encryption in alpha phase is quite too
  early. It isn't feature which should slow down the alpha release. I
  propose to demand it in beta phase. So I propose to change alpha
  criterion:
 
  'The installer must be able to complete an installation using the 
  entire
  disk, existing free space, or existing Linux partitions methods, with 
  or
  without encryption or LVM enabled'
 
  to:
 
  'The installer must be able to complete an installation using the 
  entire
  disk, existing free space, or existing Linux partitions.'
 
  I think, that these three options are reasonable for alpha. This 
  doesn't
  say anything about how to do it, only what should be possible, so it
  could be used with the new anaconda.
 
 I think that's going in the right direction, though possibly not far 
 enough. It's worth bearing in mind that the existing criterion is very 
 tied to the old UI design: Entire disk, Existing free space, and 
 'Existing Linux partitions are direct references to the various 
 autopart methods that oldUI presented, and encryption and LVM are in the 
 criterion precisely because they were the two checkboxes available on 
 the oldUI autopart dialog. Basically, the criterion was written to 
 encapsulate the idea 'all the options on the autopart screen should 
 work'.
 
 Given that, it's probably better just to write something entirely from 
 scratch that's appropriate to newUI rather than trying to tweak the 
 existing text...

OK, what about something like:
'The installer must be able to create a reasonable disk layout using
entire disk or enable to create custom layout using basic file systems
(ext4, swap)'

It's only draft, so I'd like to hear your comments and objections.


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[criteria update] Package set

[Petr Schindler]

Hi,

Because of changes in package set selection in new anaconda, I propose
to amend the alpha criterion:

'The installer must be able to complete package installation with the
default package set for each supported installation method'

to:

'The installer must be able to install the default desktop for each
supported installation method (DVD, live, netinst, PXE, ...)'

I chose default desktop because in f17 every installation method had it
as default package set.

Please, let me know if you have some suggestions or objections.

Regards
Petr Schindler

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[criteria update]

[Petr Schindler]

Hi,

I think that require LVM and encryption in alpha phase is quite too
early. It isn't feature which should slow down the alpha release. I
propose to demand it in beta phase. So I propose to change alpha
criterion:

'The installer must be able to complete an installation using the entire
disk, existing free space, or existing Linux partitions methods, with or
without encryption or LVM enabled'

to:

'The installer must be able to complete an installation using the entire
disk, existing free space, or existing Linux partitions.'

I think, that these three options are reasonable for alpha. This doesn't
say anything about how to do it, only what should be possible, so it
could be used with the new anaconda.

I would also add new beta criterion (instead of amending some current):

'The installer must be able to create and use partitions with or without
encryption or using LVM'

If you have some suggestions or objection send them to the list.

Regards
Petr Schindler



-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[criteria update] Update of uncategorized package groups criterion

[Petr Schindler]

Hi,

we should amend the beta criterion:

'At the package installation stage, the install should show no
uncategorized package groups'

There should be something like 'Software selection spoke' instead of
'package installation stage', also I'm not sure if 'uncategorized
package groups' makes sense. I would propose to change it to:

'At the software selection spoke, there mustn't be any uncategorized
package groups'

Another option is to remove this criterion. The software selection is
changed in new ui and I'm not sure if this criterion is still
applicable.

If you have any suggestions or objection send them to the list.

Regards
Petr Schindler




-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Package set

[Petr Schindler]

On Čt, 2012-09-06 at 08:45 +, Jóhann B. Guðmundsson wrote:
 On 09/06/2012 07:21 AM, Petr Schindler wrote:
  Please, let me know if you have some suggestions or objections.
 
 Please keep it
 
 'The installer must be able to complete package installation with the
 default package set for each supported installation method'
 
 We are try to be as broad as possible for a reason...
 

The good reason for this change is that we need to test our blocking
desktops (Gnome, KDE), so it would be nice if anaconda could install
them in alpha. We don't need any minimal system or web server. For the
start we just need a working desktop for testing.

To be as broad as possible is nice, but for now, there is nothing like
'default package set', you have to choose some, so the amending of this
criterion is necessary.

 Thanks
 
 JBG
 


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Proposed ALpha Criteria

[Petr Schindler]

Hi,

On Po, 2012-09-03 at 19:19 -0700, Chuck Forsberg WA7KGX N2469R wrote:
 I propose the inclusion of two critera for an alpha release.
 
 1.  safe and stable custom disk partitioning choice

We already have criteria, which demands usable partitioning. In
different phases we want different features (LVM, Raid, ...). The state
of things is something else.

 2.  Mate desktop install choice

There are so called 'release-blocking desktops' (currently it is  Gnome
and KDE), those are desktops on which we focus most. If someone wants to
have working DE he must test by him self (we are testing it only when we
have some spare time). If there is no spin with Mate, then you have to
find someone (or even do it yourself) to create one. If you thing, that
there is lot of users of Mate, it will be very welcomed. If you will
need some help with it, we can try to help.


 1 because Fedora needs to be a real Linux, not a toy
 2 to add a bit of excitement among Linux boffins (including Linus?)
 
 -- 
 Chuck Forsberg WA7KGX N2469R c...@omen.com   www.omen.com
 Developer of Industrial ZMODEM(Tm) for Embedded Applications
Omen Technology Inc  The High Reliability Software
 10255 NW Old Cornelius Pass Portland OR 97231   503-614-0430
 


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: 18 Alpha TC3 DVD defaulting to networked install

[Petr Schindler]

I've filled the bug: https://bugzilla.redhat.com/show_bug.cgi?id=849152

This bug shows, how bad could it be, when you can't choose custom
packages. It is impossible to install system with GNOME without this
feature now.

Hopefully no more dependency problems will appear. And this won't be
needed anymore.

On Pá, 2012-08-17 at 12:13 +, Andre Robatino wrote:
 The 18 Alpha TC3 DVD appears to default to a networked install (meaning it 
 uses
 packages from the updates repos when they are newer than the ones on the 
 DVD). I
 noticed this when choosing the GNOME Desktop and nothing else, and ended up
 getting Software Selection errors. Clicking on Error checking software
 dependencies. Click for details. gives
 
 1:control-center-3.5.5-2.fc18.x86 64 requires 
 libgnome-bluetooth.so.10()(64bit)
 shotwell-0.12.3-1.fc18.x86_64 requires libgphoto2_port.so.0()(64bit)
 
 even though shotwell is not even on the DVD and the repoclosure problem with
 control-center was fixed on the TC3 DVD. I looked under Installation Source
 and there is a box Don't install the latest available software updates. 
 Install
 the default versions provided by the install source above. which is unchecked
 by default. I checked the box, but still get the same errors, so it's not
 working. Aside from that, I'm not happy with the default of a networked 
 install
 in that
 
 1) It's less reliable than a non-networked install because of problems like 
 the
 one above (assuming the DVD itself has no repoclosure or file conflicts
 problems), and
 
 2) It means higher bandwidth use, since the default is to download updated
 packages in full, rather than installing the old version from the DVD and then
 saving bandwidth by downloading the updated version with yum-presto.
 


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: heads up on 18 Alpha TC1

[Petr Schindler]

Hi,

I went ahead and created template for f18 install results [1]. Do we
have some page with test plan for f18? There are some links to it, but
page doesn't exist.

I've also copied pages for results and set up links, so you can now use
these links [2], [3], [4] for your results. 

I think that we don't need to grey out test cases, I would say, try the
best to test the feature of test case and if there is some problem, then
write a comment. When we will know how things works with new UI we
should change testcases. 

Please be careful when proposing blockers, there are still some criteria
which are quite obsolete (due to new ui of anaconda). I will try to
propose changes as soon as I find out how the things works in new ui.

[1] https://fedoraproject.org/wiki/QA:Fedora_18_Install_Results_Template
[2]
https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
[3] https://fedoraproject.org/wiki/Test_Results:Current_Base_Test
[4] https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

On Ne, 2012-08-12 at 22:54 -0700, Adam Williamson wrote:
 On Mon, 2012-08-13 at 04:02 +, Andre Robatino wrote:
  Dgilmore just posted in https://fedorahosted.org/rel-eng/ticket/5284 that 
  the 18
  Alpha TC1 install images have just been posted (no Lives for now). There is 
  no
  18 install results template page yet (pinged Adam on IRC but no response 
  yet) so
  I'm planning on holding off on the official announcement until there is 
  one. I
  also haven't updated the redirects yet since I normally do that at the same 
  time
  as the announcement. Delta ISOs will be available soon in the usual place. 
  They
  go from 17 Final to 18 Alpha TC1 and are about 36% of full 18 Alpha TC1 ISO 
  size.
  
  http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC1/
  
  http://dl.fedoraproject.org/pub/alt/stage/deltaisos/
 
 sorry about that, folks, I wasn't actually expecting the TC to get
 posted over the weekend, figured we'd have Monday to set up the template
 page. if anyone else wants to do it in the next twelve hours or so
 please do, or else I'll get it done tomorrow morning my time, after the
 QA meeting. thanks! basically it's just a cut/paste job from the f17
 install results template, we might want to grey out some tests for
 things that are known not to be implemented in newUI yet, best sync with
 anaconda team to figure out what. We'll probably want to revise some of
 the test cases to match newUI too, but that doesn't need to happen
 before we do the template.
 -- 
 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:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: First experience with F18-ALPHA-TC1

[Petr Schindler]

Hi,

there is missing root parameter on boot line. If you add
'root=live:CDLABEL=Fedora\x2018-Alpha-TC1\x20x86_64' to boot line, you
will be able to boot. But it won't help you much, there is a problem
within anaconda, which should be fixed, so this TC is not working.

On Po, 2012-08-13 at 14:18 +0300, Vadim Rutkovsky wrote:
 Hi,
 
 This bug has been filed as
 https://bugzilla.redhat.com/show_bug.cgi?id=847644
 
 В Пн., 13/08/2012 в 12:55 +0200, A.J. Werkman пишет:
  Hi,
  
  Exactly the same here. No difference in screen output too. Only I used
  i386 on bare metal.
  
  
  Koos.
  
  Op 13-8-2012 11:59, Joachim Backes schreef:
  
   Hi Testers,
   
   I downloaded the install ISO of F18-ALPHA-TC1-x86_64 from
   
   http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC1/.
   
   If booting the burned DVD with Installation, after some seconds the
   installation stops with /dev/root does not exist. I did this inside
   VirtualBox, but same results if booting my real machine with the DVD.
   
   MoBo: Asrock ConRoe1333-DVI/H, 4 MB memory.
   
   The VirtualBox boot window (tty.jpg) and the tail of the jounalctl
   output (journalctl.jpg) have been attached.
   
   Kind regards
   
   Joachim Backes joachim.bac...@rhrk.uni-kl.de
   
   https://www-user.rhrk.uni-kl.de/~backes
   
   
  
  Op 13-8-2012 11:59, Joachim Backes schreef:
  
   Hi Testers,
   
   I downloaded the install ISO of F18-ALPHA-TC1-x86_64 from
   
   http://dl.fedoraproject.org/pub/alt/stage/18-Alpha-TC1/.
   
   If booting the burned DVD with Installation, after some seconds the
   installation stops with /dev/root does not exist. I did this inside
   VirtualBox, but same results if booting my real machine with the DVD.
   
   MoBo: Asrock ConRoe1333-DVI/H, 4 MB memory.
   
   The VirtualBox boot window (tty.jpg) and the tail of the jounalctl
   output (journalctl.jpg) have been attached.
   
   Kind regards
   
   Joachim Backes joachim.bac...@rhrk.uni-kl.de
   
   https://www-user.rhrk.uni-kl.de/~backes
   
   
  
 


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Test-Announce] 2012-08-13 @ 15:00 UTC - Fedora QA Meeting

[Petr Schindler]

Hi,

there is missing boot parameter, so you won't be able to boot TC1. You
can add 'root=live:CDLABEL=Fedora\x2018-Alpha-TC1\x20x86_64' to boot
line to boot this iso.

But, there is broken anaconda, so you won't be able to run install. I
pinged anaconda team about the problem, so they are now working on the
fix. It looks like we have to wait for some update.img or for new TC.

On Ne, 2012-08-12 at 22:57 -0700, Adam Williamson wrote:
 # Fedora Quality Assurance Meeting
 # Date: 2012-08-13
 # Time: 15:00 UTC
 (https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
 # Location: #fedora-meeting on irc.freenode.net
 
 Greetings testers!
 
 Well it's officially F18 time, everyone: Alpha TC1 is up now, so we need
 to make sure everything's in place for that.
 
 This is a reminder of the upcoming QA meeting.  Please add any topic
 suggestions to the meeting wiki page:
 https://fedoraproject.org/wiki/QA/Meetings/20120813
 
 The current proposed agenda is included below.
 
 == Proposed Agenda Topics ==
 1. F18 status, TC testing preparation
 2. Multi-image validation
 3. AutoQA update
 4. Open floor
 -- 
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
 http://www.happyassassin.net
 
 ___
 test-announce mailing list
 test-annou...@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/test-announce


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Rescue mode

[Petr Schindler]

I've already done this, I've realized it right after I post it, I'm
sorry.

!!
!PLEASE DO NOT REPLY TO THIS THREAD!!!
!!

On Pá, 2012-07-27 at 14:37 -0700, Adam Williamson wrote:
 On Fri, 2012-07-27 at 15:59 +0200, Petr Schindler wrote:
  Because of changes in new anaconda [1] and after short discussion with
  Chris Lumens, I propose to change this final criterion [2]:
  
  'The installer must be able to complete an installation using all 
  supported interfaces '
  
  to
  
  'The installer must be able to complete an installation using all
  supported interfaces (graphical and VNC for F18)'
  
  Reason (according to Chris): (Current criterion) again references 
  multiple interfaces. For F18, it's really only going to be graphical and 
  VNC.
  
  Please, if you have some suggestions or notes reply to this thread. If
  there won't be any objections I'll make changes during next week.
 
 I think you applied the wrong Subject: line to this one. Could you send
 it again with an appropriate Subject: line so things don't get confused?
 Thanks!


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[criteria update] Rescue mode

[Petr Schindler]

Because of changes in new anaconda [1] and after short discussion with
Chris Lumens, I propose to delete this alpha criterion:

'The rescue mode of the installer must start successfully and be able to
detect and mount an existing default installation'

Reason (according to Chris): There's been no work done on rescue mode
and it is highly unlikely that it does anything at all right now.

Please, if you have some suggestions or notes reply to this thread. If
there won't be any objections I'll make changes during next week.

Petr Schindler

[1] https://fedoraproject.org/wiki/Features/NewInstallerUI

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[criteria update] Serial console

[Petr Schindler]

Because of changes in new anaconda [1] and after short discussion with
Chris Lumens, I propose to delete this beta [2] criterion:

'The installer must be able to complete an installation using the serial 
console interface'

Reason (according to Chris): (This criterion) will need to be removed for this 
release, 
given that there will be no text mode interface temporarily.

Please, if you have some suggestions or notes reply to this thread. If
there won't be any objections I'll make changes during next week.

Petr Schindler

[1] https://fedoraproject.org/wiki/Features/NewInstallerUI
[2] https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[criteria update] Rescue mode

[Petr Schindler]

Because of changes in new anaconda [1] and after short discussion with
Chris Lumens, I propose to remove this beta criterion [2]:

'The rescue mode of the installer must be able to detect and mount
(read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and
software) installations'

Reason (according to Chris): There's been no work done on rescue mode
and it is highly unlikely that it does anything at all right now.

Please, if you have some suggestions or notes reply to this thread. If
there won't be any objections I'll make changes during next week.

Petr Schindler

[1] https://fedoraproject.org/wiki/Features/NewInstallerUI
[2] https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[criteria update] Anaconda and network-attached storage devices

[Petr Schindler]

Because of changes in new anaconda [1] and after short discussion with
Chris Lumens, I propose to remove this final criterion [2]:

'The installer must be able to complete an installation using any 
network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)'

Reason (according to Chris): (This feature) will not be supported for this 
release, 
but will be back for F19. There's simply not the time to do this.

Please, if you have some suggestions or notes reply to this thread. If
there won't be any objections I'll make changes during next week.

Petr Schindler

[1] https://fedoraproject.org/wiki/Features/NewInstallerUI
[2] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria



-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[criteria update] Rescue mode

[Petr Schindler]

Because of changes in new anaconda [1] and after short discussion with
Chris Lumens, I propose to change this final criterion [2]:

'The installer must be able to complete an installation using all 
supported interfaces '

to

'The installer must be able to complete an installation using all
supported interfaces (graphical and VNC for F18)'

Reason (according to Chris): (Current criterion) again references 
multiple interfaces. For F18, it's really only going to be graphical and VNC.

Please, if you have some suggestions or notes reply to this thread. If
there won't be any objections I'll make changes during next week.

Petr Schindler

[1] https://fedoraproject.org/wiki/Features/NewInstallerUI
[2] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria



-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[criteria update] Interfaces

[Petr Schindler]

Because of changes in new anaconda [1] and after short discussion with
Chris Lumens, I propose to change this final criterion [2]:

'The installer must be able to complete an installation using all 
supported interfaces '

to

'The installer must be able to complete an installation using all
supported interfaces (graphical and VNC for F18)'

Reason (according to Chris): (Current criterion) again references 
multiple interfaces. For F18, it's really only going to be graphical and VNC.

Please, if you have some suggestions or notes reply to this thread. If
there won't be any objections I'll make changes during next week.

Petr Schindler

[1] https://fedoraproject.org/wiki/Features/NewInstallerUI
[2] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria



-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Anaconda and network-attached storage devices

[Petr Schindler]

It is a big problem. Lot of things will be broken (won't be in new
anaconda for F18, but should be again in next releases, hopefully). For
example, we use serial console a lot and for f18 it won't work. I'm here
only proposing changes because of the state of anaconda and I hope that
the discussion within this threads will lead to some action - for me it
would be better to wait, but it looks like we could wait another six
month.

On Pá, 2012-07-27 at 08:55 -0500, Chris Adams wrote:
 Once upon a time, Petr Schindler pschi...@redhat.com said:
  Because of changes in new anaconda [1] and after short discussion with
  Chris Lumens, I propose to remove this final criterion [2]:
  
  'The installer must be able to complete an installation using any 
  network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)'
  
  Reason (according to Chris): (This feature) will not be supported for this 
  release, 
  but will be back for F19. There's simply not the time to do this.
 
 I understand anaconda is undergoing a significant and needed rewrite,
 but is it wise to ship a release with a whole lot of installer
 functionality removed?  Maybe F18 should wait until anaconda is ready.
 -- 
 Chris Adams cmad...@hiwaay.net
 Systems and Network Administrator - HiWAAY Internet Services
 I don't speak for anybody but myself - that's enough trouble.


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Rescue mode

[Petr Schindler]

On Pá, 2012-07-27 at 08:53 -0500, Chris Adams wrote:
 Once upon a time, Petr Schindler pschi...@redhat.com said:
  Because of changes in new anaconda [1] and after short discussion with
  Chris Lumens, I propose to remove this beta criterion [2]:
  
  'The rescue mode of the installer must be able to detect and mount
  (read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and
  software) installations'
  
  Reason (according to Chris): There's been no work done on rescue mode
  and it is highly unlikely that it does anything at all right now.
 
 You've proposed removing rescue mode criteria from both alpha and beta;
 is there going to be any requirement for a functional rescue mode for
 this release?  That's a pretty critical thing to have completely missing
 from a release; things that occasionally happen such as a broken boot
 loader would render an install virtually unrecoverable for many users.

It is about discussion to accept this change. If there will be lot of
opinions against this change, we will let it be as it is and anaconda
will have to make their best to bring rescue mod. We can also change
this criterion. It's on discussion. Note that those changes are
hopefully only for F18. In F19 there should be everything back.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: will F18 allow simultaneous installation of more than one desktop?

[Petr Schindler]

On So, 2012-07-07 at 09:15 +, Jóhann B. Guðmundsson wrote:
 On 07/06/2012 07:10 PM, Andre Robatino wrote:
  I attempted installation using Fedora-20120703-x86_64-916dfe7-netinst.iso 
  and
  found that it only allows choosing one desktop. I normally install both 
  Gnome
  and KDE at this point and asked about it on #anaconda. Dlehman it was not
  planned to support that, and regarding installing other desktops afterwards 
  and
  choosing between them at the login prompt, he said that wasn't up to them, 
  but
  personally he frowned on that practice.
 
 I agree with David the installer should not support that and also frown 
 upon that practice.
 
 I also think that once the novice end user has choose in his DE in the 
 installer he should only be presented with packages/applications 
 targeted specifically for that desktop environment if he should be 
 presented with options to install additional packages et al...

What about computers used by more users? All of them now have to use one
DE? For example: family has one computer and every member uses it. One
likes KDE, second Gnome, third Xfce. I can imagine such situation. Now,
they can install more DE on installation and then just use them. And
now? They will say something bad about developers minds and change
distribution.

I thought that possibility of choice is the biggest advantage of linux
against other systems. And also, Fedora is NOT distribution for (linux)
novices, so I can't see any reason for constraint we are talking about.

 
  If it's not possible to have more than one desktop installed, it makes 
  changing
  desktops much harder (clean install?) and someone who doesn't like Gnome 
  Shell,
  for example, may well decide to change distros rather than try a different
  desktop. Personally, I use Gnome, but install KDE just to have the KDE 
  packages
  available while using Gnome. Would this become impossible?
 
 
 I dont think this argument holds much water.
 
 Novice end users would be more likely to download an alternative ( 
 encase of an live cd/usb ) from the same distribution and try it out 
 since they are already familiar with the the process of downloading and 
 ( or re)installing the OS and experience users that want to run multiple 
 DE's can already install another one once they have successfully 
 finished installing the distribution.
 
 JBG


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Release criteria proposal: USB-written images

[Petr Schindler]

 As two people voted for it, patch. Beta proposal is unchanged. For
 Alpha, instead of adding a new criterion, the existing criterion is
 simply modified to:
 
 * The installer must boot (if appropriate) and run on all primary
 architectures, with all system firmware types that are common on those
 architectures, from default live image, DVD, and boot.iso install media
 when written to an optical disc and when written to a USB stick with at
 least one of the [[How_to_create_and_use_Live_USB|officially supported
 methods]]
 
 It's a bit of an ugly long sentence, but I can't see a way to contract
 it without losing significance, and the two people who commented
 preferred one really long criterion to two quite long ones.

+1 It is long, but understandable.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Release criteria proposal: USB-written images

[Petr Schindler]

On Pá, 2012-06-08 at 04:35 -0400, Kamil Paral wrote:
  * The installer must boot (if appropriate) and run on all primary
  architectures, with all system firmware types that are common on
  those
  architectures, from default live image, DVD, and boot.iso install
  media
  when written to an optical disc
  
  Add new criterion:
  
  * The installer must boot (if appropriate) and run on all primary
  architectures, with all system firmware types that are common on
  those
  architectures, from default live image, DVD, and boot.iso install
  media
  when written to a USB stick with at least one of the
  [[How_to_create_and_use_Live_USB|officially supported methods]]
 
 Why don't we merge these two?
 
 . when written to an optical disc, or to a USB stick with at least one of 
 the officially supported methods
 
 One criterion instead of two. Less text.

+1. I'd prefer one longer criterion then two a bit shorter (but still
long).

 
  Beta:
  
  Add new criterion:
  
  * The installer must boot (if appropriate) and run on all primary
  architectures, with all system firmware types that are common on
  those
  architectures, from default live image, DVD, and boot.iso install
  media
  when written to a USB stick with any of the
  [[How_to_create_and_use_Live_USB|officially supported methods]]
  
  The idea here is that at Alpha stage it must be possible to create a
  working USB stick _somehow_, and at Beta stage, all methods should be
  working. We could push the second criterion out to Final, I guess,
  but
  to me, this is becoming pretty core functionality. Seems like writing
  images to a stick is as common or more common than using actual media
  nowadays.
 
 Agreed, USB sticks are getting used more and more. Beta stage sounds 
 reasonable.

ACK, we should have criterion for USB sticks as it's used a lot (for
example: we've made some promotional usb sticks for university teacher).

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: new Release Criterion proposal: kernel+initrd boot

[Petr Schindler]

On Út, 2012-04-10 at 10:49 -0700, Adam Williamson wrote:
 On Fri, 2012-04-06 at 09:49 -0400, Kamil Paral wrote:
  Recently we found out that we don't have any criterion for PXE boot. Also 
  F17 anaconda separated its root image from initrd.img, adding new ways 
  where things can break. In the QA meeting we decided that new criterion is 
  required [1]. Relevant bugs are:
  https://bugzilla.redhat.com/show_bug.cgi?id=805166
  https://bugzilla.redhat.com/show_bug.cgi?id=790348
  https://bugzilla.redhat.com/show_bug.cgi?id=810513
  
  The new proposed criterion is this:
  
  The installer must be able to boot using kernel+initrd pair (some boot 
  arguments might be needed), e.g. booting a VM or from PXE. Fetching the 
  installer's root image must work using the same access protocols as are 
  required for fetching package sources in currently active milestone. 
  Installer must work correctly even if the remote location doesn't contain a 
  full installable tree including package repository, but just the root image 
  and files relevant to it.
  
  
  I propose to add it to the Alpha milestone.
  
  It covers several things:
  1. booting over PXE
  2. remote installer fetching
  3. partial repositories (missing package repository)
  
  I deliberately re-used the the definition of protocols from another 
  criterion related to package source fetching options, because it is 
  tightly related. This makes sure that PXE booting works since Alpha, but 
  the number of supported protocols increases just gradually as we reach Beta 
  and Final.
  
  The last sentence could be split to a separate milestone (and worded a bit 
  differently), because we might not require it really since Alpha. OTOH this 
  is more succinct, and I have a vested interest in having this in Alpha 
  anyway (because of our automated test suite).
  
  Better wording (and translating into proper English) is welcome.
  
  Thoughts?
 
 Wording...how about:
 
 It must be possible to install by booting the installation kernel
 directly, including via PXE, and correctly specifying a remote source
 for the installer itself, using whichever protocols are required to work
 for package retrieval at the current phase (Alpha, Beta, Final). This
 must work if the remote source is not a complete repository but contains
 only the files necessary for the installer itself to run
 
 I like the basic idea of the criterion. I'm still not really sold on
 what phase we should be applying it to, though PXE and virt-install
 together are obviously fairly good arguments for alpha or beta...

+1


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Installation interfaces criterion proposal

[Petr Schindler]

On Út, 2012-03-13 at 22:14 -0700, Adam Williamson wrote:
 
 Ack! Since we had a solid consensus on the meeting I think we should
 just go ahead and put this in the Beta criteria. 

The new criterion is right on the place. So from now, non-functional
serial console interface is beta (and final) blocker.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Installation interfaces criterion proposal

[Petr Schindler]

On St, 2012-03-07 at 18:04 -0800, Adam Williamson wrote:
 On Wed, 2012-03-07 at 08:21 -0500, Kamil Paral wrote:
   Because there are some objections for serial interface being in final
   criterion, I'd like to start discussion again. There was discussion
   on
   blocker bug meeting [1] (17:40) and it didn't end with unanimous
   decision. So, let the flame war begin. Do you want serial interface
   in
   beta criterion? I asked anaconda team for suggestion and here is
   their
   answer [2]. What is your opinion?
   
   [1] http://goo.gl/921Vo
   [2]
   https://www.redhat.com/archives/anaconda-devel-list/2012-February/msg00144.html
  
  My view is that having it Final is easier and having it Beta is more
  beneficial. Serial console is used a lot for various VM setups and
  automated testing. If we have it in Final, we might not get as much
  bug reports received from general public, because in Beta it will be
  broken.
  
  The QA team uses TCs and RCs, but still, this issue might get fixed
  just soon before Final if the requirement is Final. That makes all
  tests based on serial console useless, because they will pass only at
  the end of development cycle. Here's an example of such a test:
  http://autoqa-stg.fedoraproject.org/resultsdb/frontend/search?type=Testcaseterms=rats_install
  
  So it hurts both us and the bug reports from public. I don't know how
  hard is to maintain serial console for Anaconda team. Maybe it's a
  nightmare. But if it is doable, I would prefer having it in Beta.
 
 I think that's pretty strong reasoning, and it makes me lean towards
 Beta as well.

Hi,
because no one had objections against it and we decided on blocker bug
meeting, that serial console is blocker, I propose to add criterion:

The installer must be able to complete an installation using the serial
console interface.

So we would have text, VNC and graphical in alpha, serial console in
beta and the rest (if any) in final.

Is it right?

Petr Schindler

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Installation interfaces criterion proposal

[Petr Schindler]

Because there are some objections for serial interface being in final
criterion, I'd like to start discussion again. There was discussion on
blocker bug meeting [1] (17:40) and it didn't end with unanimous
decision. So, let the flame war begin. Do you want serial interface in
beta criterion? I asked anaconda team for suggestion and here is their
answer [2]. What is your opinion?

[1] http://goo.gl/921Vo
[2]
https://www.redhat.com/archives/anaconda-devel-list/2012-February/msg00144.html

On Po, 2012-02-13 at 14:11 +0100, Petr Schindler wrote:
 Because nobody had any objections, I've added new criterion to [1] and
 I've changed release level of [2] to final.
 
 [1] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria
 [2]
 https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_Cmdline
 
 On Fri, 2012-02-03 at 09:55 -0800, Adam Williamson wrote:
  On Fri, 2012-02-03 at 17:39 +0100, Petr Schindler wrote:
   I propose new final criterion:
   
   The installer must be able to complete an installation using all
   supported interfaces
   
   Serial port is covered by this one. As I've seen some discussion on
   anaconda-devel list, it's still supported.
   
   I'm still waiting for anaconda opinion of cmdline interface [1]. They
   should say what they want to support. This criterion ensures that all
   supported interfaces will work in final release.
   
   There is another question. Do we still need text interface?? There is an
   alpha criterion The installer must be able to complete an installation
   using the text, graphical and VNC installation interfaces, so it should
   work.
  
  +1, looks good. I don't think there's any intent to drop the text
  installer, anaconda team has already discussed how to implement a text
  installer with the UI re-design, so it looks like it's sticking around.
  -- 
  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:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: f17 alpha, dropbox

[Petr Schindler]

On Čt, 2012-03-01 at 11:48 -0800, Benjamin De Kosnik wrote:
 anybody have any luck with dropbox on F17 x86_64? It's not showing up in
 the panel, but is in the applications-internet menu. When clicked, it
 tries to install, but fails. 
 
 -benjamin

Hi,
it works for me. I use Gnome shell and dropbox icon is in the tray as
usually. Try to run 'dropbox running; echo $?' if it writes out '0' the
dropbox isn't running. In that case run 'dropbox start' and then
'dropbox autostart y'. If it is running and there still isn't the icon,
problem is elsewhere.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: f17 alpha, dropbox

[Petr Schindler]

On Pá, 2012-03-02 at 08:41 -0800, Samuel Sieb wrote:
 Petr Schindler wrote:
  Hi,
  it works for me. I use Gnome shell and dropbox icon is in the tray as
  usually. Try to run 'dropbox running; echo $?' if it writes out '0' the
  dropbox isn't running. In that case run 'dropbox start' and then
 
 Normally 0 is a successful exit code.  Are you sure that's the result you're 
 expecting here?

Yes, I'm sure. In manpage of dropbox there is:
dropbox running
Returns 1 if running 0 if not running.

You are right that it's a little bit confusing.


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New criterion for updates.img using

[Petr Schindler]

I've added new criterion to beta release criteria. Tha alpha criterion
has already been there (I proposed it in another thread). You can find
changes here [1].

[1] https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria

On Mon, 2012-02-20 at 17:51 +0100, Petr Schindler wrote:
 So I propose alpha criterion:
 
 The installer must be able to use an [[Anaconda/Updates|installer
 update image]] retrieved from HTTP url
 
 And beta criterion:
 
 The installer must be able to use an [[Anaconda/Updates|installer
 update image]] retrieved from removable media, remote installation
 source and HTTP url
 
 I think, that this should be beta for testing purposes. It will be
 easier to test patches, so it would be better if it worked earlier
 than
 later. But that's only my opinion. If you have something against it,
 please, reply to this thread.
 
 

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New testcase for installation without selinux

[Petr Schindler]

I've removed the criterion from [1].

[1] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria 

On Mon, 2012-02-20 at 17:20 +0100, Petr Schindler wrote:
 It looks like better idea to drop criterion as this option is
 obsolete.
 So, I propose to remove criterion 
 
 The installed system must run normally if the user chooses to install
 without SELinux
 
 from final criteria [1]. If someone wants to switch the selinux off it
 can be easily done from the installed system. Some objections??
 
 [1] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria 

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New criterion for updates.img via URL

[Petr Schindler]

I've added it to alpha criteria [1]. If this feature isn't working now,
we should test it and propose new blocker bug.

[1] https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria

On Thu, 2012-02-16 at 09:28 -0800, Adam Williamson wrote:
 On Thu, 2012-02-16 at 14:45 +0100, Petr Schindler wrote:
  On Mon, 2012-01-30 at 16:41 -0800, Adam Williamson wrote:
   On Mon, 2012-01-30 at 11:26 -0500, Petr Schindler wrote:
I propose new alpha criterion: 

The installer must be able to download and apply updates.img file
using a HTTP url and use it
   
   Small proofread suggestion:
   
   The installer must be able to download and use an [[Anaconda/Updates|
   installer update image]] from an HTTP server 
  
  Thanks for your suggestion Adam. If nobody has any objections I'll add
  this criterion to alpha criteria. I'm going to do it on Monday, so if
  anybody has something, please reply to this thread.
 
 No objection, but it's worth noting for the record that anaconda team
 believes update images do not actually work at present - so once this
 criterion goes into production we'll have created a new Alpha
 blocker. :) They're confident it can be fixed in time for release,
 though.



-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New criterion for Checksum

[Petr Schindler]

On Mon, 2012-02-13 at 14:23 +0100, Petr Schindler wrote:
 If you have some objection on this one, please, let me know till
 tomorrow, otherwise if there are no suggestions I'll make changes. 

I've made changes. I've added new alpha and final release criterion to
[1] [2]. And I've changed release level of test checksum testcases to
Alpha/Final in [3]

[1] https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria
[2] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria
[3] https://fedoraproject.org/wiki/QA:Fedora_17_Install_Results_Template

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Release level modification in text upgrade test cases

[Petr Schindler]

Anaconda team wants to support upgrading by text interface [1], so
everything is fine and no changes have to be done here.

[1]
https://www.redhat.com/archives/anaconda-devel-list/2012-February/msg00032.html

On Fri, 2012-02-03 at 17:56 +0100, Petr Schindler wrote:
 I propose to change release level of [1] [2] from beta to non-blocking
 (leave it blank). There is a thread [3] anaconda-devel list, but nobody
 has replied. I hope that someone from anaconda will react on this
 proposal. If text upgrade will be supported in f17, there is a bug from
 last release [3] which should be fixed.
 
 [1]
 https://fedoraproject.org/wiki/QA:Testcase_Anaconda_Upgrade_Update_Bootloader_Text_Mode
 [2]
 https://fedoraproject.org/wiki/QA:Testcase_Anaconda_Upgrade_Skip_Bootloader_Text_Mode
 [3] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=742207
 


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New testcase for installation without selinux

[Petr Schindler]

On Tue, 2012-01-31 at 12:00 -0800, Adam Williamson wrote:
 On Tue, 2012-01-31 at 11:43 -0500, Chris Lumens wrote:
   The installed system must run normally if the user chooses to install 
   without SELinux
   
   There is no test case for this now.
   
   I have one note on this. There is used noselinux option, but it doesn't 
   work now. I filled bug [2] there is another option with the same effect - 
   selinux=0 and this one works fine, but Anaconda have noselinux in 
   documentation, so it should work and they're working on it.
  
  The option to install without selinux was added at a time when selinux
  was a new, experimental feature in Fedora.  Now, it's an integral part
  of the distribution.  It's time for this option to go away.
 
 If we don't want to support that, the alternative is to ditch the
 release criterion. I'm okay with that.

It looks like better idea to drop criterion as this option is obsolete.
So, I propose to remove criterion 

The installed system must run normally if the user chooses to install
without SELinux

from final criteria [1]. If someone wants to switch the selinux off it
can be easily done from the installed system. Some objections??

[1] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New criterion for reporting failure of installer and accessing debug mode

[Petr Schindler]

On Tue, 2012-01-31 at 12:01 -0800, Adam Williamson wrote:
 On Tue, 2012-01-31 at 11:42 -0500, Chris Lumens wrote:
   The installer must be able to handle the failure and report the
 issue. The installer must be also able to access debug mode.
  
  Debug mode is intended to be used by developers to test and fix
  anaconda.  I don't think this belongs in test criteria.
 
 If it's never expected to be used by end users, then yeah, we should
 leave it out of the criteria and ditch the test or make it
 non-blocking. 

I've changed test case [1] to non-blocking. As debug mode is not
supposed to be used by users it shouldn't block release. Criterion isn't
needed too.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New criterion for updates.img using

[Petr Schindler]

On Tue, 2012-01-31 at 10:24 -0800, Adam Williamson wrote:
  Thank you for suggestions on this. I would require only methods for
  which we have test case [1] [2] and from alpha [3]. So I propose
 beta
  criterion:
  
  The installer must be able to use an [[Anaconda/Updates|installer
  update image]] retrieved from removable media, remote installation
  source and HTTP url
  
  [1]
 
 https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_installation_source
  [2]
 
 https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_local_media
  [3]
 
 https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_URL
 
 I think we do want to require at least URL to work at Alpha. So have a
 criterion just for URL at Alpha, then a broader criterion at beta or
 final. 

So I propose alpha criterion:

The installer must be able to use an [[Anaconda/Updates|installer
update image]] retrieved from HTTP url

And beta criterion:

The installer must be able to use an [[Anaconda/Updates|installer
update image]] retrieved from removable media, remote installation
source and HTTP url

I think, that this should be beta for testing purposes. It will be
easier to test patches, so it would be better if it worked earlier than
later. But that's only my opinion. If you have something against it,
please, reply to this thread.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New test case for testing if services start properly

[Petr Schindler]

I've added test case [1] to [2].

[1] https://fedoraproject.org/wiki/QA:Testcase_Services_start
[2] https://fedoraproject.org/wiki/QA:Base_validation_results_template

On Tue, 2012-01-31 at 07:23 -0500, Petr Schindler wrote:
  From: Adam Williamson awill...@redhat.com
  To: For testing and quality assurance of Fedora releases
 test@lists.fedoraproject.org
  Sent: Tuesday, January 31, 2012 1:50:46 AM
  Subject: Re: New test case for testing if services start properly
  
  On Mon, 2012-01-30 at 11:37 -0500, Petr Schindler wrote:
   I propose new test cases [1]. This test case is related to final
   criterion:
   
   All services in a default install must start properly
   
   We don't have test case for this right now.
   
   [1]
  
 https://fedoraproject.org/wiki/User:Pschindl/Draft_QA_Testcase_Services_start
  
  I think the instructions are possibly a tad too tool-specific.
  Instead
  of explicitly referring to alt-f2 and gnome-terminal, it may be more
  future-proof to simply say:
  
  'In a console, run the command {{command|systemctl --all --failed}}'
  
  You can also drop the comma from This test case tests, whether all
  services start properly in a default install. It's not needed.
 
 It's amended. Thanks for suggestion. 

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Change of release level of Kickstart Http Server test case

[Petr Schindler]

On Mon, 2012-01-30 at 16:28 -0800, Adam Williamson wrote:
 On Mon, 2012-01-30 at 11:21 -0500, Petr Schindler wrote:
  Test case [1] is associated with alpha release level in [2]. I propose to 
  change it to beta level, where is criterion: The installer must be able to 
  use all kickstart delivery methods.
  
  [1] https://fedoraproject.org/wiki/QA:Testcase_Kickstart_Http_Server_Ks_Cfg
  [2] https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
 
 Ack!
 
 In case you weren't aware, note that there are templates for the
 validation pages:
 
 https://fedoraproject.org/wiki/QA:Fedora_17_Install_Results_Template
 https://fedoraproject.org/wiki/QA:Desktop_validation_results_template
 https://fedoraproject.org/wiki/QA:Base_validation_results_template
 
 So changes like this should be made to the template pages.

I've changed it. [1] test case is now in beta release level in [2].

[1]
https://fedoraproject.org/wiki/QA:Testcase_Kickstart_Http_Server_Ks_Cfg
[2]
https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New criterion for updates.img via URL

[Petr Schindler]

On Mon, 2012-01-30 at 16:41 -0800, Adam Williamson wrote:
 On Mon, 2012-01-30 at 11:26 -0500, Petr Schindler wrote:
  I propose new alpha criterion: 
  
  The installer must be able to download and apply updates.img file
  using a HTTP url and use it
 
 Small proofread suggestion:
 
 The installer must be able to download and use an [[Anaconda/Updates|
 installer update image]] from an HTTP server 

Thanks for your suggestion Adam. If nobody has any objections I'll add
this criterion to alpha criteria. I'm going to do it on Monday, so if
anybody has something, please reply to this thread.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New criterion for Memory test

[Petr Schindler]

Because there was no objections, I've added new final criterion to [1].

[1] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria

On Tue, 2012-01-31 at 05:28 -0500, Petr Schindler wrote:
  From: Adam Williamson awill...@redhat.com
  To: For testing and quality assurance of Fedora releases 
  test@lists.fedoraproject.org
  Sent: Tuesday, January 31, 2012 1:36:38 AM
  Subject: Re: New criterion for Memory test
  
  On Mon, 2012-01-30 at 11:23 -0500, Petr Schindler wrote:
   I propose new final criterion:
   
   The installer must be able to run memory test.
   
   This feature is very useful and should work. We have test case for
   this yet [1]. I'd move it to final release level.
   
   [1] https://fedoraproject.org/wiki/QA:Testcase_Memtest86
  
  Well, it's not actually the installer. memtestx86 is a completely
  standalone thing which we just put on the images, with a boot menu
  option: if you pick it, nothing Fedora-ish at all actually runs.
  
  Perhaps:
  
  All release media must include a standalone memory test utility. A
  boot
  menu option to launch this utility must be present and must work
  correctly.
 
 I agree with that, my fault. So I propose new final criterion:
 
 All release media must include a standalone memory test utility. A boot menu 
 option to launch this utility must be present and must work correctly.
 
 Thanks Adam for your feedback.
 
 Petr Schindler


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Installation interfaces criterion proposal

[Petr Schindler]

Because nobody had any objections, I've added new criterion to [1] and
I've changed release level of [2] to final.

[1] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria
[2]
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_Cmdline

On Fri, 2012-02-03 at 09:55 -0800, Adam Williamson wrote:
 On Fri, 2012-02-03 at 17:39 +0100, Petr Schindler wrote:
  I propose new final criterion:
  
  The installer must be able to complete an installation using all
  supported interfaces
  
  Serial port is covered by this one. As I've seen some discussion on
  anaconda-devel list, it's still supported.
  
  I'm still waiting for anaconda opinion of cmdline interface [1]. They
  should say what they want to support. This criterion ensures that all
  supported interfaces will work in final release.
  
  There is another question. Do we still need text interface?? There is an
  alpha criterion The installer must be able to complete an installation
  using the text, graphical and VNC installation interfaces, so it should
  work.
 
 +1, looks good. I don't think there's any intent to drop the text
 installer, anaconda team has already discussed how to implement a text
 installer with the UI re-design, so it looks like it's sticking around.
 -- 
 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:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New criterion for Checksum

[Petr Schindler]

If you have some objection on this one, please, let me know till
tomorrow, otherwise if there are no suggestions I'll make changes.

On Wed, 2012-02-01 at 11:40 +0100, Petr Schindler wrote:
 On Tue, 2012-01-31 at 10:23 -0800, Adam Williamson wrote:
  On Tue, 2012-01-31 at 07:48 -0500, Petr Schindler wrote:
  
   OK, so test case should stay in alpha and new criterion should be in
   alpha too. I propose to drop the part about embedded checksum (that
   would be only additional check) and new criterion should be:
   
   A correct checksum must be published for each official release
   image.
   
   The second possibility is to have two criteria, first in alpha and
   second in beta. In beta, there would be included embedded checksum.
   
   I think that first option is better.
  
  Well, I think we probably want to ensure the embedded checksum is
  correct at final - it would look silly to ship a release where the
  built-in media check always fails, after all. So I think we may want to
  have that second criterion at least for final.
 
 You are right. So beside this alpha criterion I propose new final
 criterion:
 
 If there is embedded checksum on ISO media, it must be correct.
 
 Test case [1] should be mark as Alpha/Final release level.
 
 [1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Checksums
 
  BTW, Petr, can you set your mail client to wrap at 72 characters, as is
  conventional? Thanks!
 
 I'm sorry. I thought that Zimbra makes this implicitly, my fault. I
 moved to the Evolution and it seems to work well.
 
 
 


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Change of release level of Mediakit ISO Size test case

[Petr Schindler]

OK, it looks like discussion ended, so I've moved [1] to beta release
level in [2]

[1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size
[2] https://fedoraproject.org/wiki/QA:Fedora_17_Install_Results_Template

On Wed, 2012-02-01 at 08:35 -0800, Adam Williamson wrote:
 On Wed, 2012-02-01 at 08:47 +0100, drago01 wrote:
  On Tue, Jan 31, 2012 at 7:29 PM, Adam Williamson awill...@redhat.com 
  wrote:
   On Tue, 2012-01-31 at 11:05 -0500, Petr Schindler wrote:
  
We made this Beta not Alpha in the criteria on purpose, specifically
because we don't think it's a significant enough problem if the lives
are over-size at Alpha stage. It *may* be worth requiring at least
the
DVD to meet size requirements at Alpha size, although even if it's
over,
you can still test it in a VM or with a USB stick. I definitely think
we
shouldn't make the live sizes mandatory at Alpha.
  
   Here I don't know. I test in pre-alpha phase only on my VMs. When I
   want to boot on bare metal, I use USB stick. But it's truth that
   nothing new should be added after alpha. So the size of images should
   be quite the same then or not? Still I think it could be in beta.
  
   When we talk about 'nothing being added' after Alpha we're really
   talking about major features. The package sets on the media can, and do,
   change. It doesn't happen so much lately, but it's been the case in the
   past that the Alpha live images were, say, 800MB, because no-one had yet
   trimmed the package set down to keep them under a CD in size. Then they
   did get properly trimmed down for Beta or Final. We don't want to block
   the Alpha if this happens.
  
  Yes this has been discussed multiple times but ... do we really still
  care about omg it does not fit on a CD ?
  I mean it is 2012 ...
 
 It's off-topic for this thread, and it's for the spins to decide for
 themselves.
 -- 
 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:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Proposal for enhancement of criterion

[Petr Schindler]

Because there was no suggestions, I've made changes. [1] is non-blockig
now. And I have amended criterion in [2].

[1]
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_remote_system
[2] https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria

On Tue, 2012-01-31 at 09:48 -0800, Adam Williamson wrote:
 On Tue, 2012-01-31 at 07:15 -0500, Petr Schindler wrote:
 
Especially saving failures to disk is important for installation
without net access. There are test cases [1], [2] and [3] for
testing this feature.

[1]
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_bugzilla
[2]
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_disk
[3]
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_remote_system
   
   Ah, that's part of my last-reply-but-one. :) I think certainly adding
   local disk at Alpha is reasonable. I'm not so sure about supporting
   saving to a remote system via ssh at Alpha.
  
  Ok, I would propose to change test case [1] to non-blocking. I think it 
  could be enough to support saving reports only to disk and bugzilla. So I 
  propose criterion:
  
  The installer must be able to report failures to Bugzilla and local disk, 
  with appropriate information included
  
  [1] 
  https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_remote_system
 
 That seems reasonable to me. Anyone else have any thoughts on this?
 -- 
 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:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Proposal for removing Boot method efidisk test case

[Petr Schindler]

On Mon, 2012-01-30 at 16:47 -0800, Adam Williamson wrote:
 On Mon, 2012-01-30 at 11:33 -0500, Petr Schindler wrote:
  I propose to remove [1] test case as we don't need it anymore. EFI
  booting is handled by regular image.
  
  [1] https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_efidisk.img
 
 Ack. For F17, I believe, the plan is not to ship an efidisk.img image at
 all.

Done. This test case is no more in [1]

[1] https://fedoraproject.org/wiki/QA:Fedora_17_Install_Results_Template


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

New test case for repository completeness

[Petr Schindler]

Hi all,

I propose new test case [1]. This test case checks, whether all required
packages are in the release repository and on install media.

This test case should be in final release level. We have these three
final criteria [2]:

'A spin-kickstarts package which contains the exact kickstart files
used to build the release must be present in the release repository. The
included kickstarts must define the correct set of release repositories'

'The final branded release notes from the Documentation team must be
present on ISO media and the appropriately versioned generic release
notes must be available in the online release repository'

'A fedora-release package containing the correct names, information
and repository configuration for a final Fedora release (as opposed to a
pre-release) must be present on ISO media while the appropriately
versioned generic-release package must be available in the online
release repository'

I'm waiting for your thoughts and advises.

[1]
https://fedoraproject.org/wiki/User:Pschindl/Draft_QA_Testcase_Repository_completeness
[2] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Installation interfaces criterion proposal

[Petr Schindler]

I propose new final criterion:

The installer must be able to complete an installation using all
supported interfaces

Serial port is covered by this one. As I've seen some discussion on
anaconda-devel list, it's still supported.

I'm still waiting for anaconda opinion of cmdline interface [1]. They
should say what they want to support. This criterion ensures that all
supported interfaces will work in final release.

There is another question. Do we still need text interface?? There is an
alpha criterion The installer must be able to complete an installation
using the text, graphical and VNC installation interfaces, so it should
work.

Regards
Petr Schindler

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Installation interfaces criterion proposal

[Petr Schindler]

I forgot to mention that if this criterion will be accepted, we should
move test case [2] to final release level.

And I forgot to give a link to anaconda-devel thread about supported
interfaces [1]

[1]
https://www.redhat.com/archives/anaconda-devel-list/2012-January/msg00207.html
[2]
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_Cmdline

On Fri, 2012-02-03 at 17:39 +0100, Petr Schindler wrote:
 I propose new final criterion:
 
 The installer must be able to complete an installation using all
 supported interfaces
 
 Serial port is covered by this one. As I've seen some discussion on
 anaconda-devel list, it's still supported.
 
 I'm still waiting for anaconda opinion of cmdline interface [1]. They
 should say what they want to support. This criterion ensures that all
 supported interfaces will work in final release.
 
 There is another question. Do we still need text interface?? There is an
 alpha criterion The installer must be able to complete an installation
 using the text, graphical and VNC installation interfaces, so it should
 work.
 
 Regards
 Petr Schindler
 


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Release level modification in text upgrade test cases

[Petr Schindler]

I propose to change release level of [1] [2] from beta to non-blocking
(leave it blank). There is a thread [3] anaconda-devel list, but nobody
has replied. I hope that someone from anaconda will react on this
proposal. If text upgrade will be supported in f17, there is a bug from
last release [3] which should be fixed.

[1]
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_Upgrade_Update_Bootloader_Text_Mode
[2]
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_Upgrade_Skip_Bootloader_Text_Mode
[3] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=742207

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New criterion for Checksum

[Petr Schindler]

On Tue, 2012-01-31 at 10:23 -0800, Adam Williamson wrote:
 On Tue, 2012-01-31 at 07:48 -0500, Petr Schindler wrote:
 
  OK, so test case should stay in alpha and new criterion should be in
  alpha too. I propose to drop the part about embedded checksum (that
  would be only additional check) and new criterion should be:
  
  A correct checksum must be published for each official release
  image.
  
  The second possibility is to have two criteria, first in alpha and
  second in beta. In beta, there would be included embedded checksum.
  
  I think that first option is better.
 
 Well, I think we probably want to ensure the embedded checksum is
 correct at final - it would look silly to ship a release where the
 built-in media check always fails, after all. So I think we may want to
 have that second criterion at least for final.

You are right. So beside this alpha criterion I propose new final
criterion:

If there is embedded checksum on ISO media, it must be correct.

Test case [1] should be mark as Alpha/Final release level.

[1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Checksums

 BTW, Petr, can you set your mail client to wrap at 72 characters, as is
 conventional? Thanks!

I'm sorry. I thought that Zimbra makes this implicitly, my fault. I
moved to the Evolution and it seems to work well.



-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New criterion for Memory test

[Petr Schindler]

 From: Adam Williamson awill...@redhat.com
 To: For testing and quality assurance of Fedora releases 
 test@lists.fedoraproject.org
 Sent: Tuesday, January 31, 2012 1:36:38 AM
 Subject: Re: New criterion for Memory test
 
 On Mon, 2012-01-30 at 11:23 -0500, Petr Schindler wrote:
  I propose new final criterion:
  
  The installer must be able to run memory test.
  
  This feature is very useful and should work. We have test case for
  this yet [1]. I'd move it to final release level.
  
  [1] https://fedoraproject.org/wiki/QA:Testcase_Memtest86
 
 Well, it's not actually the installer. memtestx86 is a completely
 standalone thing which we just put on the images, with a boot menu
 option: if you pick it, nothing Fedora-ish at all actually runs.
 
 Perhaps:
 
 All release media must include a standalone memory test utility. A
 boot
 menu option to launch this utility must be present and must work
 correctly.

I agree with that, my fault. So I propose new final criterion:

All release media must include a standalone memory test utility. A boot menu 
option to launch this utility must be present and must work correctly.

Thanks Adam for your feedback.

Petr Schindler
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New criterion for reporting failure of installer and accessing debug mode

[Petr Schindler]

 From: Adam Williamson awill...@redhat.com
 To: For testing and quality assurance of Fedora releases 
 test@lists.fedoraproject.org
 Sent: Tuesday, January 31, 2012 1:46:45 AM
 Subject: Re: New criterion for reporting failure of installer and accessing   
 debug mode
 
 On Mon, 2012-01-30 at 11:29 -0500, Petr Schindler wrote:
  I propose final criterion:
  
  The installer must be able to handle the failure and report the
  issue. The installer must be also able to access debug mode.
  
  We have test case for this - [1]. It's useful to have this feature.
  
  [1]
  https://fedoraproject.org/wiki/QA:Testcase_Anaconda_traceback_debug_mode
 
 Well, we already have a criterion for 'reporting a failure to
 Bugzilla'.
 We also have some more test cases without matching criteria -
 QA:Testcase Anaconda save traceback to remote system and
 QA:Testcase_Anaconda_save_traceback_to_disk. Perhaps we need a more
 comprehensive approach here.
 
 The existing criterion at Alpha is:
 
 The installer must be able to report failures to Bugzilla, with
 appropriate information included
 
 So following that model, we could have:
 
 The installer must be able to enter debugging mode on encountering a
 failure

I agree, this is more logical approach then mine. So I propose new final 
criterion:

The installer must be able to enter debugging mode on encountering a failure

 at Final. Not sure if we want to also add criteria for remote system
 and
 disk, or if we want to downgrade those to non-blocking tests, but
 right
 now they're marked as Alpha, so we should do something.

This is discussed in another thread. So I will comment there.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Proposal for enhancement of criterion

[Petr Schindler]

 From: Adam Williamson awill...@redhat.com
 To: For testing and quality assurance of Fedora releases 
 test@lists.fedoraproject.org
 Sent: Tuesday, January 31, 2012 1:47:55 AM
 Subject: Re: Proposal for enhancement of criterion
 
 On Mon, 2012-01-30 at 11:35 -0500, Petr Schindler wrote:
  I propose to enhance alpha criterion
  
  The installer must be able to report failures to Bugzilla, with
  appropriate information included
  to
  The installer must be able to report failures to Bugzilla, remote
  system and local disk, with appopriate information included
  
  Especially saving failures to disk is important for installation
  without net access. There are test cases [1], [2] and [3] for
  testing this feature.
  
  [1]
  https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_bugzilla
  [2]
  https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_disk
  [3]
  https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_remote_system
 
 Ah, that's part of my last-reply-but-one. :) I think certainly adding
 local disk at Alpha is reasonable. I'm not so sure about supporting
 saving to a remote system via ssh at Alpha.

Ok, I would propose to change test case [1] to non-blocking. I think it could 
be enough to support saving reports only to disk and bugzilla. So I propose 
criterion:

The installer must be able to report failures to Bugzilla and local disk, with 
appropriate information included

[1] 
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_remote_system
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New test case for testing if services start properly

[Petr Schindler]

 From: Adam Williamson awill...@redhat.com
 To: For testing and quality assurance of Fedora releases 
 test@lists.fedoraproject.org
 Sent: Tuesday, January 31, 2012 1:50:46 AM
 Subject: Re: New test case for testing if services start properly
 
 On Mon, 2012-01-30 at 11:37 -0500, Petr Schindler wrote:
  I propose new test cases [1]. This test case is related to final
  criterion:
  
  All services in a default install must start properly
  
  We don't have test case for this right now.
  
  [1]
  https://fedoraproject.org/wiki/User:Pschindl/Draft_QA_Testcase_Services_start
 
 I think the instructions are possibly a tad too tool-specific.
 Instead
 of explicitly referring to alt-f2 and gnome-terminal, it may be more
 future-proof to simply say:
 
 'In a console, run the command {{command|systemctl --all --failed}}'
 
 You can also drop the comma from This test case tests, whether all
 services start properly in a default install. It's not needed.

It's amended. Thanks for suggestion.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New criterion for Checksum

[Petr Schindler]

 From: Adam Williamson awill...@redhat.com
 To: For testing and quality assurance of Fedora releases 
 test@lists.fedoraproject.org
 Sent: Tuesday, January 31, 2012 1:51:16 AM
 Subject: Re: New criterion for Checksum
 
 On Mon, 2012-01-30 at 18:02 +, Andre Robatino wrote:
  Petr Schindler pschindl at redhat.com writes:
  
   I propose new final criterion:
   
   There must be published correct checksum for each ISO media.
   Also if there is
  embedded checksum on ISO
   media, it must be correct.
   
   I think we should check this. We have already test case [1]. I
   propose to
  change release level for this test
   case to final.
   
   [1]
   https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Checksums
  
  I think that having a published correct checksum for each ISO
  should be Alpha
  level. If the ISO can't be verified, then the results of any other
  testing on it
  are suspect. Also, publishing the correct checksums can be done
  without altering
  the ISOs themselves, so it's easy to ensure that this test passes.
  Getting the
  embedded checksum correct is less important since an independent
  check is
  possible.
 
 Yeah, I did think that too. It seems like the kind of thing that
 should
 always be correct.

OK, so test case should stay in alpha and new criterion should be in alpha too. 
I propose to drop the part about embedded checksum (that would be only 
additional check) and new criterion should be:

A correct checksum must be published for each official release image.

The second possibility is to have two criteria, first in alpha and second in 
beta. In beta, there would be included embedded checksum.

I think that first option is better.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New criterion for updates.img using

[Petr Schindler]

 From: Adam Williamson awill...@redhat.com
 To: For testing and quality assurance of Fedora releases 
 test@lists.fedoraproject.org
 Sent: Tuesday, January 31, 2012 1:42:30 AM
 Subject: Re: New criterion for updates.img using
 
 On Mon, 2012-01-30 at 11:28 -0500, Petr Schindler wrote:
  I propose new beta criterion:
  
  The installer must be able to use updates.img obtained by any
  supported way
  
  I think, that this should be at criteria too. There are test cases
  which uses this feature - [1], [2]
  
  [1]
  https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_installation_source
  [2]
  https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_local_media
 
 Similar to previous:
 
 The installer must be able to retrieve and use an
 [[Anaconda/Updates|
 installer update image]] by any supported method
 
 Though this may be too broad, and we may have the problem we had with
 kickstarts in F16, where some really obscure retrieval method doesn't
 work and we don't really want to block the release for that. We might
 want to be more specific and only support more common updates.img
 deployment channels.

Thank you for suggestions on this. I would require only methods for which we 
have test case [1] [2] and from alpha [3]. So I propose beta criterion:

The installer must be able to use an [[Anaconda/Updates|installer update 
image]] retrieved from removable media, remote installation source and HTTP url

[1] 
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_installation_source
[2] 
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_local_media
[3] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_URL
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New criterion for installation with minimal set of packages

[Petr Schindler]

 From: Adam Williamson awill...@redhat.com
 To: For testing and quality assurance of Fedora releases 
 test@lists.fedoraproject.org
 Sent: Tuesday, January 31, 2012 4:51:56 AM
 Subject: Re: New criterion for installation with minimal set of packages
 
 On Mon, 2012-01-30 at 21:56 -0500, Jon Stanley wrote:
  On Mon, Jan 30, 2012 at 8:49 PM, Adam Williamson
  awill...@redhat.com wrote:
  
   Yeah, this is kind of problematic, because I don't really want
   the
   release criteria to prescribe exactly what the 'minimal' package
   set
   should include. Perhaps we should just explicitly refer to 'the
   installer's minimal package set' or something like that
  
  True - come to think of it, I really don't believe that it is QA's
  domain to define the task list - but it should be somebody's. What
  I
  don't want is the feature creep of the minimal package set - next
  thing you know, GNOME will be part of that package set. But I don't
  think that QA is the appropriate place to address those concerns :)
 
 Yeah. As far as QA is concerned, the key questions are 'is there a
 minimal package set present, does an install with that package set
 complete properly, does it boot'. What's *in* it is not really our
 concern.

So new beta criteria should be:

The installer must be able to complete package installation with a minimal 
usable set of packages

And what minimal set means should be defined somewhere else? And as soon as 
it will be somewhere, we should give the link.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Change of release level of Mediakit ISO Size test case

[Petr Schindler]

 From: Adam Williamson awill...@redhat.com
 To: For testing and quality assurance of Fedora releases 
 test@lists.fedoraproject.org
 Sent: Tuesday, January 31, 2012 1:52:49 AM
 Subject: Re: Change of release level of Mediakit ISO Size test case
 
 On Mon, 2012-01-30 at 20:40 +, Andre Robatino wrote:
  Petr Schindler pschindl at redhat.com writes:
  
   
   Test case [1] is marked as alpha release level in [2]. I propose
   to change it
  to beta. We have beta criterion
   The network installation image, DVD image, and live images for
  release-blocking desktops must meet
   current size requirements for this.
   
   [1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size
   [2]
   https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
  
  I'd prefer that this test be left at alpha level, since if it
  fails, then anyone
  who needs to use the corresponding media is blocked from any other
  testing as
  well. There's also the issue that having to reduce the size of the
  image at a
  later point runs the risk of causing further problems in deciding
  what to cut.
  If some media are considered less important than others, maybe
  there could be
  separate size tests for the different media.
 
 We made this Beta not Alpha in the criteria on purpose, specifically
 because we don't think it's a significant enough problem if the lives
 are over-size at Alpha stage. It *may* be worth requiring at least
 the
 DVD to meet size requirements at Alpha size, although even if it's
 over,
 you can still test it in a VM or with a USB stick. I definitely think
 we
 shouldn't make the live sizes mandatory at Alpha.

Here I don't know. I test in pre-alpha phase only on my VMs. When I want to 
boot on bare metal, I use USB stick. But it's truth that nothing new should be 
added after alpha. So the size of images should be quite the same then or not? 
Still I think it could be in beta.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

New testcases, criteria and modifications of present ones proposal

[Petr Schindler]

Hi,

as an output of my work on [1] I'd like to propose some new testcases, criteria 
and some modifications of present ones. It would be great if you look at them 
and whether you will have some suggestions, please let me know (on mailing 
list).

Regards
Petr Schindler

[1] https://fedorahosted.org/fedora-qa/ticket/151
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Change of release level of Mediakit ISO Size test case

[Petr Schindler]

Test case [1] is marked as alpha release level in [2]. I propose to change it 
to beta. We have beta criterion The network installation image, DVD image, and 
live images for release-blocking desktops must meet current size requirements 
for this.

[1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size
[2] https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Change of release level of Kickstart Http Server test case

[Petr Schindler]

Test case [1] is associated with alpha release level in [2]. I propose to 
change it to beta level, where is criterion: The installer must be able to use 
all kickstart delivery methods.

[1] https://fedoraproject.org/wiki/QA:Testcase_Kickstart_Http_Server_Ks_Cfg
[2] https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

New criterion for Checksum

[Petr Schindler]

I propose new final criterion: 

There must be published correct checksum for each ISO media. Also if there is 
embedded checksum on ISO media, it must be correct.  

I think we should check this. We have already test case [1]. I propose to 
change release level for this test case to final.

[1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Checksums
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

New criterion for Memory test

[Petr Schindler]

I propose new final criterion: 

The installer must be able to run memory test. 

This feature is very useful and should work. We have test case for this yet 
[1]. I'd move it to final release level.

[1] https://fedoraproject.org/wiki/QA:Testcase_Memtest86
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

New criterion for Memory test

[Petr Schindler]

I propose new final criterion: 

The installer must be able to run memory test. 

This feature is very useful and should work. We have test case for this yet 
[1]. I'd move it to final release level.

[1] https://fedoraproject.org/wiki/QA:Testcase_Memtest86
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test