Re: F28 System Wide Change: AArch64 Server Promotion

[John Dulaney]

On Mon, Jan 08, 2018 at 08:31:05PM -0500, Matthew Miller wrote:
> On Mon, Jan 08, 2018 at 04:37:34PM -0800, Adam Williamson wrote:
> > > Are there hardware needs here? (Like, not in the server room but in QA
> > > team member's hands?)
> > pwhalen has hardware. Not sure who else does. I'm not going to ask for
> > any, because it'd just join all my ARM hardware in the Pile Of Boxes I
> > Never Get Time To Open.
>
> If anyone else on the QA team (or Server SIG) has time but *not* the
> pile of boxes, this is a good time to say something. :)
>

/me raises his hand.

--
John.


signature.asc
Description: PGP signature
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Re: F28 System Wide Change: AArch64 Server Promotion

[John Dulaney]

On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote:
>
> Another consideration would be whether we ought to also have aarch64
> support in Taskotron, if it's going to become a primary arch. I'm not
> actually sure if Taskotron currently covers 32-bit ARM, though, even.

Taskotron does not quite support 32 bit arm.  All the bits are there, but
there are a few bugs that need addressing.

--
John.


signature.asc
Description: PGP signature
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Re: Self-introduction: Brian Gribble

[John Dulaney]

On Fri, May 12, 2017 at 10:14:23PM -0400, Brian Gribble wrote:
> Good evening,
> 
> My name is Brian and I am a Platform Consultant at Red Hat.  My current
> role is supporting a project using PKI along with other Red Hat products.
> Prior to joining Red Hat I worked as a Linux Systems Administrator using
> RHEL, and some CentOS, at different companies.  I have been working with
> Linux professionally for 10+ years and still enjoy it.
> 
> I am interested in helping with QA.  I enjoy testing so I am willing to
> help with any of the three listed on the wiki (upcoming stable, new
> package, rawhide).  Wherever you need help that is beginner-friendly.
> 
> IRC: brian83
> 
> Thanks,
> 
> Brian
> 

Hi, Brian!

I've sponsored you into the QA FAS group.  Have fun!

John.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Re: Criteria proposal: move "No broken packages" requirement to Final

[John Dulaney]

On Wed, Apr 05, 2017 at 11:17:27AM -0700, Adam Williamson wrote:
> So, at the Alpha go/no-go we discussed this bug:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1437299
> 
> and agreed that with current behaviour of anaconda and dnf, blocking
> Alpha release on it didn't make sense.
> 
> The relevant criterion here is 
> https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria#No_broken_packages
>  :
> 
> "There must be no errors in any package on the release-blocking images
> which cause the package to fail to install."
> 
> In practice, this criterion is only relevant to DVD images. AFAIK, it's
> not possible for the other image types to contain packages they can't
> install, because they all wind up deploying the bits they're actually
> built *from* - they don't act as 'package repositories'.
> 
> At the time we wrote the criterion, we had a generic DVD image with
> many different packages and package groups on it. The installer GUI
> allowed you to select 'optional' packages from the groups included on
> the image for installation. And if any package selected had dependency
> issues, the install would fail with an error.
> 
> Quite a lot has changed since. We no longer have a generic DVD image,
> only the Server DVD image, which contains only a handful of Server-
> related package groups. The installer GUI no longer lets you select
> optional packages; you can only select the 'environments' and 'option
> groups' that are present on the DVD, and only 'mandatory' and 'default'
> packages from those groups will be selected for install. And if a
> selected package has dependency issues, the install will simply proceed
> with that package (and anything else that requires it) omitted.
> 
> Given all of these considerations, I propose we move the criterion to
> Final.
> 
> For the record, I'm also looking at the dnf/anaconda behaviour. It
> turns out there's a few wrinkles, but I do think we should switch it
> back to 'strict' mode (where any listed package not being found or
> being non-installable for some reason causes an error) by default. But
> it's not entirely straightforward.
> https://bugzilla.redhat.com/show_bug.cgi?id=1427365 is the place to
> follow that. I do still think that moving the criterion to Final would
> be OK even if we changed dnf behaviour; I think for Alpha and Beta it's
> enough if the default Server DVD package set installs OK, we should
> make sure that the other package sets available from the Server DVD
> install OK for Final.
> 
> Thoughts? Notes? Concerns? Thanks!

I am +1.

John.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Re: Criteria proposal: virt guest at Alpha

[John Dulaney]

On Thu, Mar 23, 2017 at 05:39:20PM -0700, Adam Williamson wrote:
> Hi folks!
> 
> At the Go/No-Go meeting today, we agreed in principle that major bugs
> in virt guest functionality should come under the Alpha criteria, not
> the Beta criteria as before. When we established the virt criteria, use
> of virtual machines for pre-release testing wasn't as widespread as it
> is now.
> 
> Having looked at the criteria, I think a simple change can achieve
> this. We simply move this single criterion from Beta to Alpha:
> 
> "The release must install and boot successfully as a virtual guest in a
> situation where the virtual host is running the current stable Fedora
> release."
> 
> The other criterion would remain at Beta:
> 
> "The release must be able host virtual guest instances of the same
> release."
> 
> I believe just this change should suffice to implement the intent: that
> virt guest functionality block Alpha, but virt host functionality block
> Beta.
> 
> Does this sound good to everyone? Thanks!

I'm +1

John.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Re: Self-introduction: Stanislav Židek

[John Dulaney]

On Thu, Mar 23, 2017 at 06:33:01PM +0100, Stanislav Zidek wrote:
> Hi,
> 
> I am Standa, a quality engineer from Red Hat, more specifically from BaseOS
> Security team where I mostly focus on testing crypto-related libraries and
> software (GnuTLS, NSS, OpenSSH and OpenSSL to name "our big four").
> 
> I have a couple of years of Linux background already, started as sysadmin
> of dozens of Gentoo servers (don't laugh!) with Python servers and MySQL
> databases in my previous job, which we successfully migrated to CentOS
> (really big step forward). As time went forward, I started to be more and
> more interested in security topics, which brought me to Red Hat and my
> current team.
> 
> Since we (QEs in Red Hat) are encouraged to devote part of our time to
> testing Fedora software, I wanted to officially join your ranks to be able
> to carry out the first public step on my Fedora-testing journey, which is
> organising test day for crypto-policies.
> 
> I don't like long write-ups, so I'll wrap it up here,
> S.
> 


Hello!

I have gone ahead and sponsored you.

John.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Re: Release validation testers: a question

[John Dulaney]

On Tue, Feb 14, 2017 at 12:02:14PM -0800, Adam Williamson wrote:
> Hi folks! I've got a question for everyone who helps out with release
> validation testing. It's related to the project to build a new system
> for submitting those results. We have a ticket for designing that
> system:
> 
> https://pagure.io/design/issue/483
> 
> and as part of the discussion there, we're wondering something. Given
> that it's part of the new design that there's some kind of step where
> you specify which particular image you're testing, does it make more
> sense to you if you choose things in this order:
> 
> 1. Pick a test to run
> 2. Pick an image to run the test on
> 
> Or this order:
> 
> 1. Pick an image to test
> 2. Pick a test to run on the image
>

I grab an image and then do multiple tests with it.

John.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Re: QA group joining process: new members cannot subscribe to list until approved

[John Dulaney]

On Sat, Aug 06, 2016 at 11:30:04AM -0700, Adam Williamson wrote:
> 
> What do you think of the idea of directly contacting people who apply
> without sending a self-intro mail?

The only issue I can think of with that is you are potentially giving
your email to a spammer.  Otherwise, I like it.

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

Re: QA group joining process: new members cannot subscribe to list until approved

[John Dulaney]

On Fri, Aug 05, 2016 at 05:28:33PM -0700, Adam Williamson wrote:
> Well we're definitely out of scope now...but for some key personnel
> (people with admin access to key servers and so on), we actually do
> need as many contact methods as possible. If there's a massive hack or
> a huge security issue, or something, we need to be able to get in touch
> with folks very quickly, an email or IRC ping may not cut it. I don't
> know if that's the reason, just thinking it through. It may also have
> had something to do with the really old CLA, I have vague memories that
> that involved faxes and stuff at some point, but it may just be the
> drugs talking...
> --

Wasn't that for the old soft phone thingy that used to be in place?


Personally, I'm a bit hesitant to sponsor someone that has not sent an
introduction email.  I also check to see if they're on IRC, and if I
see neither, I'm a bit hesitant to sponsor them.  If I see them on IRC
but don't see an email, obviously I'll sponsor them.

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

Re: Self-Introduction

[John Dulaney]

On Sat, Apr 23, 2016 at 08:59:02PM -0400, Rich Talmadge wrote:
> Hello All,
> 
> I'm interested and learning the process and ins and outs on the QA side of
> life.  I have been using all kinds of Linux off and on.
> 
> Lets see now a little quick blurb about me names Rich living on the east
> coast of the USA.  My mane background comes from computer repair shop days
> fixing & removing Viruses form computers repairing Windows OS laptops /
> desktops along with servers .  Now a days though been working manly on the
> back-end of Linux systems and repairing and troubleshooting errors that
> occur along with backup systems and Windows servers and troubleshooting
> networking issues.
> 
> So i'm looking forward to learning the QA side of things and thinking of
> ways of trying to break things.
> 
> Thanks

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


Welcome!

I went ahead and sponsored you in FAS.

Our channel is #fedora-qa on irc.freenode.net.  You may want to go ahead
and join that channel.  We also have weekly IRC meetings at 11 AM Eastern
(both DST and not DST) in #fedora-meeting.

If you could, go ahead and take a quick glance through the QA pages on
the wiki (0) to get an idea as to our process.

We don't bite (much), and I think the Fedora QA folks are really fun
to hang out with.  So, time to have some fun.

John 

(0)  https://fedoraproject.org/wiki/QA
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

RE: Pungi 4 milestone builds: proposals

[John Dulaney]

.
>
> == 2. N indicates TC/RC, R indicates number ==
>
> In this scheme, we'd build e.g. 'Alpha 1.1' (Alpha TC1), 'Alpha 1.2'
> (Alpha TC2), 'Alpha 2.1' (Alpha RC1), 'Alpha 2.2' (Alpha RC2).
>
> This seems like the closest possible way to map to our current system.
> Again it's a bit weird at Final because there is no 'Final' milestone,
> only 'RC', so 'RC1.1' would be 'TC1' and 'RC2.1' would be 'RC1', which
> is kinda strange; again we could add a 'Final' milestone to Pungi, I
> guess.
>
> I'm just not sure, as per 1), if we really *need* to maintain the TC/RC
> distinction at least in terms of how the composes are labelled and
> distributed.
>

I'm a fan of this approach, personally.

John.
  
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

RE: Newbie in FedoraProject team

[John Dulaney]

> Date: Wed, 28 Oct 2015 12:11:04 +0300 
> Subject: Newbie in FedoraProject team 
> From: fp.kar...@gmail.com 
> To: test@lists.fedoraproject.org 
>  
> Hi all! 
>  
> My name is Alexander Kolesnikov, I am from St. Petersburg, Russia. I  
> use Linux about 6 years: 4 years as system administrator of RedHat and  
> CentOS and last two years Fedora is primary home OS. I have backgroud  
> in system administration and QA. I would like to help Fedora QA team. 
> And I hope, that someone help me to join in QA group in FAS, I am  
> already sent request. 
> My account in FAS (https://admin.fedoraproject.org/accounts/user/view/karter) 
> My irc nickname is krter. 
> I hope I can be useful for FedoraProject. 
>  
> P.S.: Sorry for my not good English. :) 
>  
>  
> Best regards, 
> Alexander Kolesnikov 


Ahoy me hearty!

John (aka pirate)
  
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

RE: Introduction

[John Dulaney]

> Date: Tue, 27 Oct 2015 21:16:40 -0400 
> Subject: Fwd: Introduction 
> From: kahlil.wallac...@gmail.com 
> To: test@lists.fedoraproject.org 
>  
>  
> -- Forwarded message -- 
> From: Kahlil Wallace  
> > 
> Date: Mon, Oct 26, 2015 at 8:33 PM 
> Subject: Introduction 
> To: fedora-test-l...@redhat.com 
>  
>  
> Hello everyone, 
>  
> My name is Kahlil Wallace and I live in the Washington D.C. area. I  
> first started using Linux in 2008 and I switched to Fedora as my  
> primary OS in 2012. I have a background in Information and Cyber  
> Security and I would eventually like to help out with that as well as  
> QA. I am really excited about Fedora and I want to help in any way  
> possible. Hopefully we all can do some great work together. My irc name  
> is khaumax and I look forward to interacting with everyone. 
>  
> Bye! 

Ahoy, and welcome to the party!

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

RE: ?howto?: find needed package in not configured repository - intel video driver

[John Dulaney]

 Date: Thu, 16 Oct 2014 04:27:58 -0400
 From: mrma...@earthlink.net
 To: test@lists.fedoraproject.org
 Subject: ?howto?: find needed package in not configured repository - intel 
 video driver

 My Google foo is getting me nowhere fast. I want to follow-up on
 https://bugs.freedesktop.org/show_bug.cgi?id=85016#c4 but need an
 xorg-x11-drv-intel git 3.0.0 version to do it. How can I find out if and
 where such an rpm package exists for F21 and/or F22?

 There's a link on
 https://fedoraproject.org/wiki/Archive:Infrastructure/PackageDatabase?rd=Infrastructure/PackageDatabase
 that seems might be the answer, but it gets a 404.

 Any chance installing
 http://download.opensuse.org/repositories/home:/sumski:/test/openSUSE_Factory/i586/xf86-video-intel-3.0.0git-216.1.i586.rpm
 would work?
 --
 The wise are known for their understanding, and pleasant
 words are persuasive. Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

 Felix Miata *** http://fm.no-ip.com/
 --

You could grab the srpm and build it yourself.

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

RE: ERROR: could not insert 'kvm_amd': Operation not supported

[John Dulaney]

 On this machine no. The kernel is 3.17.0-301.fc21.x86_64. This is the
 first time I install Fedora on it.

 I have another machine with AMD Athlon(tm) 64 X2 Dual Core Processor
 4800+ and have running QEMU-KVM virtualization on it since 2007 without
 this problem.

 --
 Regards

 Jon Ingason




Okay, maybe install an older kernel, see if that works?


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

RE: Sound problems with skype in F21

[John Dulaney]

 To: test@lists.fedoraproject.org
 From: rdie...@math.unl.edu
 Subject: Re: Sound problems with skype in F21
 Date: Thu, 18 Sep 2014 06:46:53 -0500
 
 Temlakos wrote:
 
  That suggests when I do the upgrade from F20-F21, I should use
  pulseaudio with no latency. True?
 
 Do you even need it on F20 anymore?
 
 (perhaps skype has been fixed to not require that workaround)
 
 -- Rex
 

Skype for Linux hasn't been updated in a long time.
John. -- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

RE: problems with QA:Testcase_base_startup

[John Dulaney]

 Date: Thu, 18 Sep 2014 06:42:07 -0400
 From: kpa...@redhat.com
 To: test@lists.fedoraproject.org
 Subject: problems with QA:Testcase_base_startup
 
 In the base installation matrix
 https://fedoraproject.org/wiki/Test_Results:Fedora_21_Alpha_RC1_Base#Test_Matrix
 
 we have this test case:
 https://fedoraproject.org/wiki/QA:Testcase_base_startup
 
 It it is marked as Alpha in the matrix. However, it depends on disk 
 encryption, which is a Beta requirement. That is a problem, if disk 
 encryption doesn't work, you can't test the rest of the test case. That means 
 you can test Alpha criteria because you are stuck on a broken Beta feature.
 
 Furthermore, the test case basically duplicates 
 https://fedoraproject.org/wiki/QA:Testcase_partitioning_guided_encrypted , 
 from my POV.
 
 So I suggest to amend Testcase_base_startup and change this sentence:
 Follow all defaults, with the exception that you should encrypt a system 
 partition (e.g. the root partition).
 to this:
 Follow all defaults, with the exception that you may encrypt a system 
 partition (e.g. the root partition).
 
 And of course the expected results would be a slightly differently formulated 
 as well.
 
 This will fix the discrepancy (Alpha test case depending on Beta features), 
 and remove the duplication.
 Thoughts?
 -- 
Just axe the encryption bit all together?   That would be cleaner, I think.
John. -- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

RE: Test case discovery / extraction (MozTrap)

[John Dulaney]

 Subject: Re: Test case discovery / extraction (MozTrap)
 From: adamw...@fedoraproject.org
 To: test@lists.fedoraproject.org
 Date: Thu, 21 Aug 2014 19:43:58 -0700

 On Thu, 2014-08-21 at 19:15 -0700, Adam Williamson wrote:
 Hey, folks. So as part of the possible move to MozTrap (or, really, it'd
 be useful for any other TCMS), I've come up with a truly hideous bash
 script to discover and extract test cases from the wiki.

 I have it running ATM and
 dumping all ~900 test cases in the wiki out to my system, once it's done
 I'll tar them and stick them up somewhere for others to access. Next
 step would be to write something to convert them to MozTrap's mass
 import format.

 I've put the full set of test cases (with obsolete ones and templates
 moved into subdirectories) up as
 https://fedorapeople.org/groups/qa/test_cases/fedora_test_cases_20140821.tar.xz
  . A somewhat-annotated version of the script is also available as 
 https://fedorapeople.org/groups/qa/test_cases/extract_test_cases.sh .
 --
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
 http://www.happyassassin.net

It appears that there is going to be quite a bit of cleanup needed.

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

RE: Leaving the project

[John Dulaney]

 Date: Tue, 20 May 2014 13:04:49 +
 From: johan...@gmail.com
 To: test@lists.fedoraproject.org
 Subject: Leaving the project

 Greetings yo all

 With regrets I must say I feel we have grown so fat we are about to
 collapse under our own weight but instead of properly start dealing with
 that within the project, people chose to ignore that fact but instead
 chose to force some future vision of RHEL 8 upon the project under the
 names of .next, products and wg's and constantly attack the solid ground
 what our foundations have stood for and their meaning all those years
 and embark on multiproduct releases based on wrong fundamental
 assumption, without statistical backing up of what they considered being
 the underlying cause for some of their assumptions and without
 thoroughly thinking things through what needs to be done before being
 able to do that as well as the fact we lack the necessary community
 infrastructure and workflows being in place to remotely being able to
 achieve delivering multiple products in a useful and efficient manner
 based on the resources we have in the project.

 And as WG's slowy turn into tiny little empires fighting amongst
 themselves for components directions and maintenance while the owners of
 those components are scratching their head still trying to figure how
 the .next,product and wg proposal affects them, their maintenance and
 where they general fit into that future vision or simply are ignoring it
 which inevitably will result in them suddenly finding themselves being
 slapped by reality and waking up from their slumber when it finally does
 hit them.

 Unfortunately I'm not seeing much future or vision in Fedora and it's
 direction anymore and the fact is that I'm failing to convey what needs
 to be fixed in any useful and meaningful way and manner, with the end
 result being that I'm not being heard and at the same time being
 powerless in fixing things that need fixing within the community. makes
 me part of the problem not the solution for the project and those that
 still believe in it and the direction it is taking as well as to who's
 being lined up to become the project's next leader.

 Will, Jon, James,Adam, Kamil, Tim, Peter, John Dulany, Bruno,Chris the
 entire Fedora unity team and bunch of other people that I have probably
 forgotten to mention thank you for for your hard work those 8+ years and
 the pleasure I had working with you.

 JBG


Dude,
Sorry to see you go.  I remember our discussions and a few 'philosophical'
ramblings over the years, and will miss them.

Just don't get yourself cleaved in two by a passing Irishman!

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

RE: Self Introduction

[John Dulaney]

 Date: Wed, 19 Feb 2014 14:25:15 -0500 
 Subject: Self Introduction 
 From: elsamm...@gmail.com 
 To: test@lists.fedoraproject.org 
  
  
 Hi, 
  
 Wanted to quickly introduce myself.  My name is Eric Sammons, I currently 
 work at Red Hat and have since 2007.  My career at Red Hat began as a 
 Technical Account Manager.  A Little over two years ago I joined the Quality 
 Engineering team, first focusing on test automation for Web UIs and more 
 recently on Messaging, Realtime, Grid, and BigData. 
  
 In addition to my Red Hat experience I have at some point or another, during 
 my 20 year career, supported most popular flavors of *nix (including AIX) and 
 even some middleware solutions; WebSphere, MQSeries, etc... 
  
 I am a self proclaimed expert in nothing, but like to tell folks I know 
 enough about a lot of things to be dangerous.  In my spare time I enjoy 
 photography and learning new things, most recently Android Application 
 Development. 
  
 Cheers! 
  
 --  
 Eric L. Sammons
   emailto:esamm...@redhat.comlsammons at gmail dot com 
 Manager Quality Engineeringirc: eanxgeek 
 rhce  # 805007668329332rhcva # 805007668329332 
  

Ahoy, and welcome to the club!

I kind of went the other way; recently I was hired by Red Hat GSS because I had 
experience
with Fedora QA.

Thanks much,
John Dulaney, RHCE
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

RE: Hello Everyone,

[John Dulaney]

 Date: Mon, 6 Jan 2014 11:20:48 -0800 
 From: crobe...@cintrixhosting.com 
 To: test@lists.fedoraproject.org 
 Subject: Hello Everyone, 
  
 Hi Everyone, 
  
 I am looking to help out the QA team with testing. Handsome Pirate has  
 helped me learn the testing process with easy karma and has sponsored  
 me in the group. I am looking forward to helping out and getting to  
 know everyone. my irc nick is croberts. As far as programming I have  
 Java experience 
  
 Chris Roberts 
 Fedora Marketing/Websites/Videos/Infrastructure Team 
 https://fedoraproject.org/wiki/User:Chrisroberts 


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

RE: Updated QA Join page

[John Dulaney]

I'm plus one for the rewrite as a whole, but also for leaving out
mention of proventestors and bugzappers, while keeping in the
information in those sections.

As for the tools section, while Tim is the obvious name to put in,
what about, say, Josef or Kamil?

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

RE: Proposal: let's just use the FAS group already

[John Dulaney]

 Date: Tue, 17 Dec 2013 12:52:16 + 
 From: johan...@gmail.com 
 To: test@lists.fedoraproject.org 
 Subject: Re: Proposal: let's just use the FAS group already 
  
 Purpose and a fact of being elitist group which caused more harm then  
 good in the QA community and what I'm worried about is that Adam is  
 resurrecting it for other then purpose after he joined the WG's. 
  
 If we agree it serves only the purpose to allow QA members to overcome  
 other limitation in the project and we ensure that it will *only* serve  
 and being used for that purpose I'm fine with resurrecting it but as  
 soon as Adam or any other RH employee starts to mutilate it to serve  
 it's corporate purpose we put it down. 
  
 JBG 


What do you mean, mutilate it to serv it's corporate purpose?  Are you 
stating that since I now work for Red Hat, I'm evil?

Since I've started working for Red Hat, I've not seen any wanting to 
contort Fedora to RH's nefarious ends.  In fact, I've seen a lot of effort to
get work done internally into Fedora as quickly as possible so that Fedora
may benefit.  I seriously don't understand where you get these ideas from.

Along those lines, now that I work for Red Hat, does that make me evil?
Am I now a corporate minion?  You do realize that my job at RH has
nothing to do with Fedora; I continue to be involved with Fedora purely
because I want to.  You don't see me slapping my @redhat.com email
around.  In fact, the only account I've switched over is my bugzilla account,
and that was purely for convenience.

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

RE: Proposal: let's just use the FAS group already

[John Dulaney]

Ahoy,

So, I am with Adam on this one (I'm not a mod?).  I've been +1 for this
idea for quite some time now.

Johann, I've been around for a long time, even longer than Adam, and I don't
remember the original purpose for the QA group; I do vaguely recall James
Laska telling me it had some purpose or other when I asked him about it (oddly
enough so I could be in more than the CLA group).  

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

RE: Who can close BZs?

[John Dulaney]

 Date: Fri, 6 Dec 2013 15:58:41 +
 From: johan...@gmail.com
 To: test@lists.fedoraproject.org
 Subject: Re: Who can close BZs?
 
 
 On 12/06/2013 03:56 PM, Karel Volný wrote:
 
  Hi,
 
  Dne pátek, 6. prosince 2013 16:19:35 CEST, Clyde E. Kunkel napsal(a):
  Is there a policy or other guidance on who is allowed to close 
  another persons bz?  For example, can a person who is not a member of 
  the action developer or bugzappers group close a bz, especially a 
  non-trivial bz?
 
  well, anyone with the appropriate permissions (even some robots)?
 
  while a formal policy could be nice, I guess it is better not to 
  complicate the rules ... anyone helping to clean the mess in bugzilla 
  is welcome; if someone has a few spare cycles and notices something 
  could be closed, why not to do it instead of the overloaded developer?
 
  - if you think that some bug has been closed improperly, let's talk 
  about that concrete case and not about policies
 
 
 FYI I'm pretty sure RH bugzilla admin frown upon giving Fedora QA 
 community members those privileges...
 
 JBG

As an aside, I had those priveleges for years before I started working
at Red Hat.

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

RE: Introduction

[John Dulaney]

 Date: Fri, 20 Sep 2013 13:28:46 +0200
 From: denni...@conversis.de
 To: test@lists.fedoraproject.org
 Subject: Re: Introduction
 
 On 05.09.2013 18:15, John Dulaney wrote:
 
  RE the Raspberry Pi, alas, Fedroa does not support it; for one it's ARMv6
  and is an old architecture, and the kernel to run it is not fully open 
  source.
 
 How can the kernel not be fully open source and not violate the gpl license?
 
 Regards,
Dennis
 

That's the million dollar question.  According to some people, it can't.  
However
binary-only drivers are included with the kernel all the time.

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

RE: [Test-Announce] 2013-09-09 @ 15:00 UTC - Fedora QA Meeting

[John Dulaney]

Alas, I rather doubt I'll be able to make it.

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

RE: Introduction

[John Dulaney]

 Date: Thu, 5 Sep 2013 17:06:38 +0300 
 Subject: Introduction 
 From: shar.lilts...@gmail.com 
 To: test@lists.fedoraproject.org 
  
 Hi guys, 
  
 I'm following the Intruduction email example writing this, hope you are  
 having a good time reading it :) 
 I've been using Fedora since Fedora Core 2 and I feel like it's the  
 right time for me to contribute somehow. 
 I've got a few years of background with RHEL too. 
 I like coding in scripting languages, mostly love writing in BASH, some  
 Python and rest you can guess. 
  
  
 My name is Mike Timland, I'm 28 years old and live in NY. My first  
 contact with Linux was about 10 years ago or more. Appears that also I  
 am using Linux for desktop stations and servers since then. 
 I just feel obligated to contribute to this community that had made my  
 life easier all those years. 
 I have a professional QA background so anything I could help with will  
 be great. 
 Sadly I'm occupied mostly of the time with work but I have spare time  
 running performance tests like now and I would like to do something  
 meaningful in those moments. My irc handle is ringstrasel 
  
 I'll be glad to write automation tests if possible in future. arm tests  
 on my raspberry pi are another thing that i can think of. Or I could  
 help with other stuff too. 
  
 Please let me know how should I proceed, where should I start from, is  
 there a scrum system where I can pick up from a list of tasks or so. 
  
 Thank you in advance and last but not least Love Fedora 
  
 Best Regards, 
 MikeT 
  


Welcome!
Firstly, we have some materials on the wiki (1) to help you get started.
Come hang out in #fedora-qa on Freenode.  We don't bite, but adamw
may fire you from time to time!

Probably the best way you can help out is grab the latest test image and
help with testing that.

RE the Raspberry Pi, alas, Fedroa does not support it; for one it's ARMv6
and is an old architecture, and the kernel to run it is not fully open source.

Welcome to the club!
John. 
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

RE: Self-introduction: Olga Johnson

[John Dulaney]

 Date: Mon, 2 Sep 2013 21:08:21 -0400 
 Subject: Self-introduction: Olga Johnson 
 From: olgajohnso...@gmail.com 
 To: test@lists.fedoraproject.org 
  
 Hi everyone, 
  
 I would like to join Fedora QA Team. 
 I'm Olga from Laurel, MD. I'm fairly new to QA field. I'm freelancing  
 in Web applications testing and studying testing methodology and tools. 
 I would like to contribute to Fedora project and get some hands-on  
 experience as a tester. 
  
 Thank you for accepting me in your community. 
 Please feel free to contact me at  
 olgajohnso...@gmail.commailto:olgajohnso...@gmail.com. 
  
 Regards, 
 Olga 
  
 -- test mailing list test@lists.fedoraproject.org To unsubscribe:  
 https://admin.fedoraproject.org/mailman/listinfo/test

Welcome to the anti-raptor club!

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

QA Meeting Recap - 26 August 2013

[John Dulaney]

Wiki page at https://fedoraproject.org/wiki/QA/Meetings/20130826


Fedora 20 Planning 
 TC1 done
 http://dl.fedoraproject.org/pub/alt/stage/20-Alpha-TC1/
 TC1 has landed (handsome_pirate,
15:07:15)non working ARM platforms as of today:
pandaboard, beaglebone black, trimslice (tflink,

15:15:12)http://dl.fedoraproject.org/pub/alt/stage/20-Alpha-TC1/Images/armhfp/
(kparal,
15:15:44)work on omap issue has been progressing, new
issues in uboot are causing problems on panda (tflink,
15:16:06)for more on booting ARM images with
qemu: (tflink,

15:22:28)https://fedoraproject.org/wiki/Architectures/ARM/F19/Installation#For_Versatile_Express_Emulation_with_QEMU
(tflink,
15:22:35)ACTION: handsome_pirate to coordinate with cloud folks for
cloud testing and where images are to be located (handsome_pirate,
15:33:27)

Open floor 
 Roshi to get out test day schedule soon

Action items 
 handsome_pirate to coordinate with cloud folks for cloud testing and where 
images are to be located

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

RE: F19 Final criteria revamp

[John Dulaney]

 Date: Mon, 10 Jun 2013 19:10:19 +
 From: johan...@gmail.com
 To: test@lists.fedoraproject.org
 Subject: Re: F19 Final criteria revamp

 On 06/10/2013 07:09 PM, Adam Williamson wrote:
 Well, let me put it more baldly: up till now I can't recall a single
 person agreeing with you that we should stop blocking on basic
 multiboot-alongside-a-simple-Windows-install. Not a single person. I
 agree we have a very small sample size on this list, but still, that
 seems pretty indicative. I can run a forum poll if you like, though...

 More appropriate place then a forum poll or this mailing list would be
 in the survey the boards working on.

 JBG
 --


Dude, 
I think it is pretty well known that I think Microsoft could take a flying 
at a donut.  However, I know that there are plenty of people that aren't quite
willing to totally commit to Linux.  Therefore, this is a totally valid, and 
even
needed criteria.

As far as RHEL, I rather doubt that RHEL's target audiance would be
dual-booting servers ...

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

RE: Question regarding bug filing on gnome components

[John Dulaney]

 Date: Mon, 29 Apr 2013 17:31:21 +
 From: johan...@gmail.com
 To: test@lists.fedoraproject.org
 Subject: Re: Question regarding bug filing on gnome components

 On 04/29/2013 05:27 PM, Michael Knepher wrote:
  I'm running Fedora 19 alpha, and have a question on the most appropriate
  place to file bugs on gnome components like epiphany and gedit. Should I
  file in the Fedora bugzilla or directly to the Gnome bugzilla?
 
  Michael Knepher
 

 In Red Hat bugzilla against Fedora.

 It's the packager/maintainers responsability to act as a liaison between
 downstream and upstream thus forward it upstream if it's relevant

 JBG
 --


Of course, the maintainer sometimes ignores Bugzilla entirely (Rhythmbox, for 
instance).

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

Testers needed for RHBZ #949912

[John Dulaney]

Testers are needed for (1), included in RC2.
If y'all could get in this and post in the bug report
your findings, I'd appreciate it.

John.

(1) https://bugzilla.redhat.com/show_bug.cgi?id=949912  
  
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

RE: F19 Alpha Blocker Bug Review #5 Minutes

[John Dulaney]

 Date: Mon, 8 Apr 2013 12:39:40 -0700
 From: c...@omen.com
 To: test@lists.fedoraproject.org
 Subject: Re: F19 Alpha Blocker Bug Review #5 Minutes

 I don't see any mention of Wine. It should be a blocker.

 KDE and Xfce can be used instead of Gnome, but there is no substitute
 for Wine.

 --
 Chuck Forsberg WA7KGX 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


Wine is not a release blocker, period.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

RE: Major criteria re-write / re-design proposal: Beta draft

[John Dulaney]

One question:  For the virt criterion, would it not be better to s/recommended
Fedora virtualization tools/supported Fedora virtualization tools?  It seems to
me that by stating that only the recommended virt tools are supported, you
might as well be saying supported.

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

RE: Major criteria re-write / re-design proposal: Beta draft

[John Dulaney]

 Date: Fri, 15 Mar 2013 13:14:15 -0700
 From: awill...@redhat.com
 To: test@lists.fedoraproject.org
 Subject: Re: Major criteria re-write / re-design proposal: Beta draft

 On 15/03/13 12:54 PM, John Dulaney wrote:
 
  One question: For the virt criterion, would it not be better to 
  s/recommended
  Fedora virtualization tools/supported Fedora virtualization tools? It seems 
  to
  me that by stating that only the recommended virt tools are supported, you
  might as well be saying supported.

 I generally prefer to avoid the word 'supported' as we don't really,
 strictly speaking, support anything much. 'Recommended' gets the meaning
 across without making it sound like we do tech support calls or send
 refunds ;)

 It's also less ambiguous, I mean, we 'support' Xen to the extent it's in
 the kernel and we have packages for it. 'Recommended' is clearer, to me.
 --
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
 http://www.happyassassin.net
 --

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

RE: Problems with VirtualBox-4.2.6-5.fc18.x86_64 from rpmfusion and kernel-3.8.1-201.fc18.x86_64 resp. kernel-devel-3.8.1-201.fc18.x86_64

[John Dulaney]

The test list is not the place to post problems with proprietary software that 
is not in the Fedora repos.
 
Further, it is well known that virtualbox eats kernels like candy.  If you 
trouble with that particular piece
of software, you brought it upon yourself for using crap and you deserve to 
reap the consequences.
 
John. 
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

RE: Proposal: automatic blockers

[John Dulaney]

 Date: Fri, 15 Feb 2013 18:34:33 -0800
 From: awill...@redhat.com
 To: test@lists.fedoraproject.org
 Subject: Proposal: automatic blockers

 Hey, folks. So here's another proposal from an idea that was mentioned
 during the F18 cycle.

 There's a few types of blocker bug that are basically no-brainers; it
 doesn't make a lot of sense to waste time in blocker meetings discussing
 them, and more importantly, sometimes they show up and we want to
 quickly accept them as blockers and get the fixes in, but we have to try
 and track down three people to vote +1 before they can be accepted.

 So I'm proposing we invent something called 'automatic blockers': a list
 

I'm Plus 1 here.

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

RE: Release criteria proposal: USB-written images

[John Dulaney]

 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.
 --
 Adam Williamson


I'll vote Ack for this.
John.
  
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

RE: yum -- Protected multilib versions?

[John Dulaney]

 Subject: yum -- Protected multilib versions?
 From: foxec...@wowway.com
 To: test@lists.fedoraproject.org
 Date: Thu, 17 May 2012 11:05:45 -0400
 
 Can't seem to install .i686 and x86_64 versions of the same package.
 
 sudo yum install libxcb-1.8-2.fc17.i686 krb5-libs-1.10-5.fc17.i686
 Loaded plugins: langpacks, presto, refresh-packagekit
 Resolving Dependencies
 -- Running transaction check
 --- Package krb5-libs.i686 0:1.10-5.fc17 will be installed
 -- Processing Dependency: libselinux.so.1 for package:
 krb5-libs-1.10-5.fc17.i686
 -- Processing Dependency: libkeyutils.so.1(KEYUTILS_0.3) for package:
 krb5-libs-1.10-5.fc17.i686
 -- Processing Dependency: libkeyutils.so.1 for package:
 krb5-libs-1.10-5.fc17.i686
 -- Processing Dependency: libgcc_s.so.1(GCC_3.3.1) for package:
 krb5-libs-1.10-5.fc17.i686
 -- Processing Dependency: libgcc_s.so.1(GCC_3.0) for package:
 krb5-libs-1.10-5.fc17.i686
 -- Processing Dependency: libgcc_s.so.1 for package:
 krb5-libs-1.10-5.fc17.i686
 -- Processing Dependency: libcom_err.so.2 for package:
 krb5-libs-1.10-5.fc17.i686
 --- Package libxcb.i686 0:1.8-2.fc17 will be installed
 -- Processing Dependency: libXau.so.6 for package:
 libxcb-1.8-2.fc17.i686
 -- Running transaction check
 --- Package keyutils-libs.i686 0:1.5.5-2.fc17 will be installed
 --- Package libXau.i686 0:1.0.6-3.fc17 will be installed
 --- Package libcom_err.i686 0:1.42-4.fc17 will be installed
 --- Package libgcc.i686 0:4.7.0-5.fc17 will be installed
 --- Package libselinux.i686 0:2.1.10-3.fc17 will be installed
 -- Finished Dependency Resolution
 Error: Protected multilib versions: krb5-libs-1.10-5.fc17.i686 !=
 krb5-libs-1.10-6.fc17.x86_64
 Error: Protected multilib versions: libxcb-1.8-2.fc17.i686 !=
 libxcb-1.8.1-1.fc17.x86_64

https://bugzilla.redhat.com/show_bug.cgi?id=809585
Yes, I know the bug looks like it is largely dealing with libguestfs, but it is 
the
same root problem.  Add your info if you don't mind.
  -- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

RE: is the name ok

[John Dulaney]

This has nothing to do with QA.

John.

From: geor...@spanmail.net
To: fedora-test-l...@redhat.com
Subject: is the name ok
Date: Fri, 6 Apr 2012 13:24:24 -0400








There is no release criterion in the Testing/QA group for the release name.
Before millions see the latest great work from a multitude of contributors, 
should this group pause to reflect if the release name is appropriate for world 
wide release.  I ask your attention that the name/ logo/ and parody may offend 
many and may refuse to use it.  Do you have concerns after looking at 
http://git.fedorahosted.org/git/?p=beefymiracle.git;a=shortlog;h=HEAD and  
beefymiracle . org.  The image of a hot dog in a bun (and in some logo 
pictures, the use of the tag line mustard indicates progress) is too laden with 
symbolism. Is there concern in this, the last group in the process to concur 
with a release GO decision, that what has been published in support of the 
release name will not offend women, parents, and many who are spiritual or 
profess a religion? 

No mater how liberal a guy I might be, this expresses a concern for how open 
source might be perceived by the general public.
Even if these pictures and words were done in fun, isn't the association now 
caustic.
 


-- 
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: Weird rawhide desktop behavior

[John Dulaney]

 Date: Sat, 24 Mar 2012 19:37:38 -0300
 Subject: Re: Weird rawhide desktop behavior
 From: look...@gmail.com
 To: test@lists.fedoraproject.org
 
 On Sat, Mar 24, 2012 at 2:58 PM, Jonathan Corbet corbet...@lwn.net wrote:
  Here's a strange pathology that just bit me for the first time in a while,
  though I've seen it before.  I'm not sure where to file a bug on this
  one...
 
  In short: I'll be working away, minding my own business, when the desktop
  goes completely dead - no response to any key or mouse events.  That said,
  the X server is still running; the pointer still moves with the mouse.  I
  can also switch to another virtual console with alt-ctrl-Fn.  Sometimes
  things start working again after some time (measured in minutes);
  sometimes I lose patience and start over.  Today I went and made lunch and
  it never came back.
 
 I've noticed the same behavior on my box, that was freshly installed
 with Fedora 17 last Friday. I'll see what I can do to gather
 information about the problem as well.
 
 -- 
 Lucas

I've been seeing similar behaviour in F16 for quite some time.  Usually, it 
happens
when I am in the middle of something else and don't have time to try to track 
it down,
and when I do have time for trying to figure it out, it doesn't happen.  It 
does seem to
occur more frequently when my box is a little warm, so I assumed that it was 
hardware
related.

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

Test Day: USB 3.0

[John Dulaney]

Shiver me timbers!
It's time for another Beefy Test Day, Argh!  Tomorrow, 13 March, is the USB 3.0 
Test Day!

https://fedoraproject.org/wiki/Test_Day:2012-03-13_USB_3.0

Testing is easy; just use your favourite up-to-date Fedora 17 image (Live or 
Install); everything
is included!  The testing will require that you have some sort of USB 3.0 
hardware to plug into
your box.  The Wiki page delves deeper into how and what to test.  The 
maintainers and some
of the usual crew will be hanging out in #fedora-test-day and #fedora-qa.  Ping 
anyone in either
of those channels if you require assistance.

To recap for those of you too busy trying to deliver the pizza before the 
Ninjas:

What:  USB 3.0 https://fedoraproject.org/wiki/Test_Day:2012-03-13_USB_3.0
When:  All day 03/13
Where:  #fedora-test-day

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

[Test-Announce] Test Day: USB 3.0

[John Dulaney]

Shiver me timbers!
It's time for another Beefy Test Day, Argh!  Tomorrow, 13 March, is the USB 3.0 
Test Day!

https://fedoraproject.org/wiki/Test_Day:2012-03-13_USB_3.0

Testing is easy; just use your favourite up-to-date Fedora 17 image (Live or 
Install); everything
is included!  The testing will require that you have some sort of USB 3.0 
hardware to plug into
your box.  The Wiki page delves deeper into how and what to test.  The 
maintainers and some
of the usual crew will be hanging out in #fedora-test-day and #fedora-qa.  Ping 
anyone in either
of those channels if you require assistance.

To recap for those of you too busy trying to deliver the pizza before the 
Ninjas:

What:  USB 3.0 https://fedoraproject.org/wiki/Test_Day:2012-03-13_USB_3.0
When:  All day 03/13
Where:  #fedora-test-day

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

RE: Anaconda should be rewritten in a compiled language!

[John Dulaney]

 Date: Fri, 17 Feb 2012 09:29:01 -0500
 From: clum...@redhat.com
 To: test@lists.fedoraproject.org
 Subject: Re: Anaconda should be rewritten in a compiled language!
 
  Just kidding ... sort of.
  
  I'm willing to bet that I wouldn't be getting a NameError: global name
  'BRFSError' is not defined traceback if it were.  (BTRFSError anyone?)
  
  Bugzilla at https://bugzilla.redhat.com/show_bug.cgi?id=794504.
 
 You know, redoing it in Haskell really would solve a lot of my problems.
 
 - Chris
 -- 

I say, write it in Fortran!
  -- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

RE: test signed checksum files and torrents the same way ISOs are tested now?

[John Dulaney]

 To: test@lists.fedoraproject.org
 From: robat...@fedoraproject.org
 Subject: test signed checksum files and torrents the same way ISOs are tested 
 now?
 Date: Wed, 21 Dec 2011 18:46:14 +
 
 Currently, ISOs are posted in a temporary location, go through a
 test-fix-test-fix... cycle, then when ready (as decided at the Go/No-Go 
 meeting)
 are posted in permanent locations. This does not happen with signed checksum
 files and .torrent files, even though they are part of the published content. 
 I
 propose that
 
 1) ASAP after ISOs are Gold (but never before), the checksum files should be
 signed and be placed in the stage/ directory replacing the unsigned checksum
 files.
 
 2) The .torrent files should then be created, using the ISOs and signed 
 checksum
 files in stage/, and placed in some temporary location (NOT where they 
 currently
 go).
 
 3) QA tests should be done to verify that the checksum files in stage/ are
 properly signed and have checksums matching those for the previous unsigned
 files, and that the .torrent files match the content in stage/ (both ISOs and
 signed checksum files). These tests are objective and trivial, so obviously
 don't need another Go/No-Go meeting.
 
 4) When the signed checksum tests pass, the ISOs and signed checksum files get
 sent to the mirrors.
 
 5) When the .torrent tests pass, the .torrent files go to their permanent
 locations. (Of course this doesn't have to be done immediately, the important
 thing is that it doesn't happen until the tests pass.)
 
 6) When all tests pass, the corresponding files in stage/ can optionally be
 deleted. If any tests fail, fix and test again.
 
 Does this sound reasonable?
 

It sounds sane to me.  The only question is, can we do a test download of the 
.torrent somehow.

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

Re: [Test-Announce] Fedora 17 Test Days

[John Dulaney]

Greetings, y’all!

This release cycle I am the Test Day Coordinator.  That means it is 
my job to help you, my fellow Fedorians, to set up test days for your 
packages/projects.  We have about two and a half months until Alpha 
release (1).  The sooner I receive test day proposals, the easier my 
life will be, and we all know that making my life easier is a Good 
Thing.  The test day schedule can be found at 
https://fedoraproject.org/wiki/QA/Fedora_17_test_days.

Proposing a test day is very easy.  There is a guide at 
https://fedoraproject.org/wiki/QA/Test_Days/Create for proposing test days, as 
well as https://fedoraproject.org/wiki/QA/SOP_Test_Day_management for helping 
with creating the associated Wiki page and actually running the test day.



If you need any help, feel free to email me at jdula...@fedoraproject.org.



Thanks much

John Dulaney


(1) https://fedoraproject.org/wiki/Releases/17/Schedule


  ___
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: [Test-Announce] Fedora 17 Test Days

[John Dulaney]

Greetings, y’all!

This release cycle I am the Test Day Coordinator.  That means it is 
my job to help you, my fellow Fedorians, to set up test days for your 
packages/projects.  We have about two and a half months until Alpha 
release (1).  The sooner I receive test day proposals, the easier my 
life will be, and we all know that making my life easier is a Good 
Thing.  The test day schedule can be found at 
https://fedoraproject.org/wiki/QA/Fedora_17_test_days.

Proposing a test day is very easy.  There is a guide at 
https://fedoraproject.org/wiki/QA/Test_Days/Create for proposing test days, as 
well as https://fedoraproject.org/wiki/QA/SOP_Test_Day_management for helping 
with creating the associated Wiki page and actually running the test day.



If you need any help, feel free to email me at jdula...@fedoraproject.org.



Thanks much

John Dulaney


(1) https://fedoraproject.org/wiki/Releases/17/Schedule


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

RE: Release criteria proposal: downgrade some kickstart delivery methods from Beta to Final

[John Dulaney]

 Date: Wed, 16 Nov 2011 08:44:52 -0500
 From: kpa...@redhat.com
 To: test@lists.fedoraproject.org
 Subject: Re: Release criteria proposal: downgrade some kickstart delivery 
 methods from Beta to Final

  On Tue, 2011-10-11 at 18:44 -0700, Adam Williamson wrote:
   Hey, folks. So, currently the Beta criteria state:
  
   The installer must be able to use all kickstart delivery methods
  
   This is probably over-ambitious for Beta. We have some pretty odd
   kickstart delivery methods:
  
   https://fedoraproject.org/wiki/QA:Testcase_Kickstart_File_Path_Ks_Cfg
   https://fedoraproject.org/wiki/QA:Testcase_Kickstart_Hd_Device_Path_Ks_Cfg
  
   that are only really useful in pretty unusual scenarios. In fact
   the
   first of these is broken in F16 Beta and we decided to go ahead and
   release it anyway (on the basis that we agreed this criterion
   should be
   changed, which is why I'm proposing a change now), and the world
   has not
   ended.
  
   I'd propose at least this much change:
  
   for Beta, the criterion should read
  
   The installer must be able to use the HTTP and NFS kickstart
   delivery
   methods
  
   as those are the two that are really useful in most situations, and
   we
   move
  
   The installer must be able to use all kickstart delivery methods
  
   to be a Final criterion. Thoughts? The Beta criterion is a bit more
   'technology-specific' than I usually like to make the criteria, but
   I
   don't think we're that likely to discover any exciting new
   protocols in
   the foreseeable future, so specifying HTTP and NFS is probably
   reasonably future-proof.
 
  Ping on this one: any further thoughts? Didn't get much response the
  first time out.

 I agree.

I'm also +1 on this.
  
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

RE: Does RC5 - Fedora 16 gold?

[John Dulaney]

 Date: Sat, 5 Nov 2011 10:40:19 -0400
 From: dgbo...@gmail.com
 To: test@lists.fedoraproject.org
 Subject: Does RC5 - Fedora 16 gold?
 
 My question is. Since Fedora 16 RC5 was declared good does that mean
 that the ISO that will be released Nov 8 be a renamed RC5? Are they/will
 they be the same ISO?
 -- 
 
   David

Basically, yes.  There will be some renaming and suchlike, but yes.  It will be 
the same
binarys.

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

RE: F16 RC5 impending, please help test!

[John Dulaney]

 From: awill...@redhat.com
 To: test@lists.fedoraproject.org
 Date: Wed, 2 Nov 2011 18:57:52 -0700
 
 So, that thing yesterday about RC4 being one last big push? I lied!
 
 We found two more blockers this morning, fixed 'em, and had our arms
 twisted at the go/no-go meeting to try and make it to go before the
 release readiness meeting tomorrow. So the go/no-go decision is delayed,
 and an RC5 is just about to be built. Should land within a couple hours.
 
 There's only one changed package in RC5, but it's anaconda. (Well,
 fedora-release-notes too, but that's not important). So, we should try
 to get the installation matrix re-done, but we don't really need to
 re-do base and desktop; we can trust the RC4 results for those two.
 
 The bugs fixed are:
 
 https://bugzilla.redhat.com/show_bug.cgi?id=750469
 https://bugzilla.redhat.com/show_bug.cgi?id=750896
 
 I don't want anyone to feel like they need to pull crazy stunts to get
 the validation done in time - if we can't make it, we can't make it, and
 we slip a week, it's not a disaster. But if we can make it that'd be
 great.
 
 Thanks all!
 -- 
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
 http://www.happyassassin.net
 

I must apologize for not being available for testing; school has priority.

The good news, however, is that I think I did well on my calculus exam.

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

RE: New proventester metrics

[John Dulaney]

 Date: Fri, 28 Oct 2011 13:06:10 -0400
 From: lmac...@redhat.com
 To: test@lists.fedoraproject.org
 Subject: Re: New proventester metrics

 On Fri, Oct 28, 2011 at 09:45:58AM -0700, Adam Williamson wrote:
  On Fri, 2011-10-28 at 10:52 -0400, Luke Macken wrote:
 
   Out of 23255 total updates, 6375 received feedback (27.41%)
   Out of 1259 total unique karma submitters, the top 50 are:
   * autoqa (28787)
 
  This implies that this is really 'top 50 commenters' not 'top 50 karma
  submitters', because autoqa does not currently submit any karma.

 Yup, you're right. I just fixed the name of the stat in git, and also
 made it ignore autoqa comments as well.

 Thanks,
 luke

Gloat onI'm still in the top 20, and considering that all of mine save a
very few are F15.../Gloat off

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

RE: Final TC/RC schedule: move it up like Beta?

[John Dulaney]

I'm for bumping up TC1



John.


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

RE: [Test-Announce] Fedora 16 Beta Release Candidate 4 (RC4) Available Now!

[John Dulaney]

 From: awill...@redhat.com
 To: test@lists.fedoraproject.org
 Date: Thu, 29 Sep 2011 04:30:51 -0700

 On Wed, 2011-09-28 at 23:44 -0400, Andre Robatino wrote:
  As per the Fedora 16 schedule [1], Fedora 16 Beta Release Candidate 4
  (RC4) is now available for testing. Please see the following pages for
  download links (including delta ISOs) and testing instructions.
 
  The priority in RC4 testing is to complete the installation tests. We
  must complete these by 14:00 EDT on Thursday 2011-09-29 in order to
  avoid slipping the Beta release again. The Base and Desktop results
  can be inherited from RC3, so they are not as important as the
  Installation tests.

 Thanks to everyone who's helped so far for the amazing work, we have
 actually nearly completed the matrix in less than 8 hours - awesome
 work, everyone.

 The outstanding tests now are just two silly kickstart delivery methods,
 which I'll do tomorrow if no-one else does, and some hardware specific
 tests:

 https://fedoraproject.org/wiki/QA:Testcase_install_to_SCSI_device
 https://fedoraproject.org/wiki/QA:Testcase_Install_to_BIOS_RAID
 https://fedoraproject.org/wiki/QA:Testcase_Install_to_Hardware_RAID

 it would be incredibly helpful if anyone who has the hardware concerned
 could test an install to it and file their results in the matrix, or
 just respond to this mail. thanks!
 --
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
 http://www.happyassassin.net


I just dropped my test results in the matrix.

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

RE: Release criteria: virtualization tweak

[John Dulaney]

 Subject: Release criteria: virtualization tweak
 From: awill...@redhat.com
 To: test@lists.fedoraproject.org
 Date: Wed, 7 Sep 2011 18:20:20 -0700
 CC: pjo...@redhat.com

 Hey, all. pjones pointed out at a recent blocker review meeting that the
 Beta virt criterion:

 The release must boot successfully as a virtual guest in a situation
 where the virtual host is running the same release (using Fedora's
 current preferred virtualization technology)

 doesn't really imply that virtual host functionality must work; only
 that _if_ virtual host functionality is working, then virtual guest
 functionality must work. This was not really our intent with the
 criterion, we intended to require both to work at Beta stage. So here's
 a proposed improvement:

 The release must be able to self-host using Fedora's current preferred
 virtualization technology: that is, the release must be able to act as a
 virtual host, and must also successfully install and boot as a virtual
 guest when running on a host which is also running the release

 I'm still not super happy with the wording, but I guess it's clearer.
 Any better ideas?

Are we assuming that this is on CPUs that support Fedora's preferred
virt technology?  I do believe that KVM doesn't do so well on older
CPUs.

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

RE: Should I make a tracking bug in fedora for problem reported upstream?

[John Dulaney]

 From: br...@wolff.to
 To: test@lists.fedoraproject.org
 Subject: Should I make a tracking bug in fedora for problem reported upstream?

 I have reported https://bugzilla.kernel.org/show_bug.cgi?id=41862 for an
 issue with 3.1 kernels crashing, typically on the order of hours after
 booting. Based on some names in the traceback, I suspect this is MD raid
 or luks related.

 I reported this upstream, since that seems to be a better place to get
 attention for development kernel bugs, than Fedora's tracker. However,
 if this should be considered a beta blocker, then I should probably also
 make a Fedora bug entry so that it can be tracked as a blocker.

 However it doesn't seem to meet the explicit requirements for a beta blocker.
 The only category it might fit in is a high severity bug. But if it really
 limited to systems using MD raid or luks encryption, I am not sure if
 it would meet that standard.

 If it isn't a blocker, I'd rather not enter a duplicate bug in Fedora since
 that would just seem to be a waste of resources. (But maybe QA would rather
 see the bug entry anyway.)


I would stick in on b.rh.com and mark it as a blocker, since it does sort of
block Beta criteria 5.

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

RE: Proposed Alpha criteria adjustments

[John Dulaney]

Subject: Re: Proposed Alpha criteria adjustments
From: jla...@redhat.com
To: test@lists.fedoraproject.org
Date: Tue, 26 Jul 2011 07:56:38 -0400


On Mon, 2011-07-25 at 21:12 -0700, Adam Williamson wrote:
 On Fri, 2011-07-22 at 16:08 -0400, James Laska wrote:

  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 enabled
 
  I propose the following minor adjustment to the above criteria:
 
  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.

 ack!

Thanks, I've added the above criteria to the wiki

https://fedoraproject.org/w/index.php?title=Fedora_16_Alpha_Release_Criteriaaction=historysubmitdiff=247142oldid=246263

  Any objections/corrections to the following Alpha criteria addition to
  cover the reboot/shutdown use case?
 
  The systems' mechanisms for shutting down, logging out and
  rebooting from a virtual console must work

 s,systems',system's,g

Doh, thanks :)

 I think we don't really need reboot to work; shut down and then turn
 back on is a fine workaround at Alpha phase. If there was a bug in
 rebooting, but shutting down worked, I'd probably not want that to be an
 Alpha blocker. And since we're interested in the mechanics of shutting
 down here, I'd like to be a bit more specific about what we mean by
 'work' (it's a less problematic concept when we're just talking about
 *triggering* a shutdown). So, how about:

 It must be possible to trigger a system shutdown using standard console
 commands, and the system must shut down in such a way that storage
 volumes (e.g. simple partitions, LVs and PVs, RAID arrays) are taken
 offline safely and the system's BIOS or EFI is correctly requested to
 power down the system

 This covers the most important thing about shutdown (clean unmount) but
 lets us not consider, say, one service not correctly going down to be a
 blocker. It also gets around any case where we send a proper shutdown
 trigger but there's a BIOS/EFI bug that causes the system not to
 actually power off. (It's kind of debatable whether we actually care
 about the system powering off, or if we just want to make sure storage
 off line).

I like it.  The only adjustment I might suggest would be to clarify the
scope of services and storage considered.  You've already done so in
your draft, but I wonder if we might still be exposed to unusual storage
configurations.  Meaning, we have a still open issue regarding a system
shutdown taking ages with LVM snapshots enabled.  We didn't consider
that a blocker in F15 since snapshots were not enabled by default and
considered atypical (local site configuration).  It still seems like a
stretch to consider that an Alpha blocker.  Howabout refining it to
limit the scope to Alpha criteria storage scenarios?  (meaning, not RAID
or iSCSI or LVM snapshots etc...)...

On system's where storage and disk partitioning is consistent
with the Alpha release criteria, it must be possible to trigger
a system shutdown using standard console commands, and the
system must shut down in such a way that storage volumes are
taken offline safely and the system's BIOS or EFI is correctly
requested to power down the system

A bit wordy ... but I think we're converging on similar scope.

 There's a possibility we might want a more stringent requirement at
 Final - say, standard services should power down properly - but I'm not
 sure about that; we have a criterion for bugs that may cause data loss
 or corruption, and I think that's the only really bad possible
 consequence of improper service shutdown. But it's worth considering.

Yeah, I could see a parallel criteria for shutdown that ensures all
services installed+enabled by a default install exit cleanly.  For now
though, I'm fine leaving that out until problems in that area surface.

 We also need a test case for this, of course.

Good point.  Unless anyone else wants a shot at it, I'll draft something
up shortly and send to the list for review.

Thanks for the feedback!
James


I think that full system poweroff should be a criteria, because there are boxes
out there that cannot be completely powered off if the OS hangs on poweroff
without disconnecting power cable, removing battery, etc. (such as the laptop
I am typing this on).  I think that in a virtual machine this also could also
conceivably cause some issues.

Maybe I'm just rambling here?

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

Fedora QA Meeting RECAP 2011-07-25

[John Dulaney]

 
Minutes:http://meetbot.fedoraproject.org/fedora-meeting/2011-07-25/fedora-qa.2011-07-25-14.59.html
Minutes (text): 
http://meetbot.fedoraproject.org/fedora-meeting/2011-07-25/fedora-qa.2011-07-25-14.59.txt
 
Log:http://meetbot.fedoraproject.org/fedora-meeting/2011-07-25/fedora-qa.2011-07-25-14.59.log.html

==
#fedora-meeting: Fedora QA meeting
==


Meeting started by j_dulaney at 14:59:45 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting/2011-07-25/fedora-qa.2011-07-25-14.59.log.html
.



Meeting summary
---
* Roll Call  (j_dulaney, 15:00:04)

* Previous meeting follow-up  (j_dulaney, 15:03:31)
  * ACTION: j_dulaney will get this done this week and not slack off
again  (j_dulaney, 15:05:56)

* Cloud SIG - Fedora 15 on Amazon EC2  (j_dulaney, 15:07:29)
  * Awaiting rel-eng for this  (j_dulaney, 15:09:04)
  * ACTION: tflink will follow up today  (j_dulaney, 15:15:29)
  * ACTION: tflink to confirm with rel-eng to see if 8/1 is a reasonable
deadline  (j_dulaney, 15:21:41)
  * AGREED: - F15 EC2 test day must be done by 8/4 at the latest, AMI
IDs must be received by 8/1  (j_dulaney, 15:23:03)

* oVirt Node Fedora 16 Spin  (j_dulaney, 15:23:24)
  * LINK:

https://fedoraproject.org/wiki/User:Athmane/Draft_Ovirt_Node_validation_matrix
(athmane_work, 15:23:37)
  * LINK:

https://fedoraproject.org/wiki/User:Athmane/Draft_Ovirt_Node_validation_matrix
(j_dulaney, 15:24:13)
  * ACTION: athmane_work to continue work on Ovirt Node validation
testing and matrix; next meeting review if the spin makes the freeze
deadline  (j_dulaney, 15:29:37)
  * AGREED: ovirt spin gets the QA Okay.  (j_dulaney, 15:34:27)

* Upcoming QA Events  (j_dulaney, 15:34:50)
  * 2011-07-21 - Pre-Alpha Rawhide Acceptance Test Plan #3 - images
available, testing in progress by twu  (j_dulaney, 15:35:04)
  * 2011-07-26 - Test Alpha 'Test Compose'  (j_dulaney, 15:35:12)
  * 2011-07-29 - Alpha Blocker Meeting (f16alpha) #3 - volunteers to
announce blocker meeting?  (j_dulaney, 15:35:19)
  * ACTION: tflink to announce blocker meeting #3  (j_dulaney, 15:36:03)
  * LINK:
http://rbergero.fedorapeople.org/schedules/f-16/f-16-releng-tasks.html
(jsmith, 15:38:30)

* Open Discussion - your topic here  (j_dulaney, 15:41:27)

* FUDCon Blacksburg QA Hackfests  (j_dulaney, 15:43:44)
  * FUDCon Blacksburg hackfests need to go on the wiki:
https://fedoraproject.org/wiki/FUDCon:Blacksburg_2012#Hackfest-_Workshops
(j_dulaney, 15:47:25)

* Open Discussion - your topic here (#endmeeting in two)  (j_dulaney,
  15:50:54)

Meeting ended at 15:52:45 UTC.




Action Items

* j_dulaney will get this done this week and not slack off again
* tflink will follow up today
* tflink to confirm with rel-eng to see if 8/1 is a reasonable deadline
* athmane_work to continue work on Ovirt Node validation testing and
  matrix; next meeting review if the spin makes the freeze deadline
* tflink to announce blocker meeting #3




Action Items, by person
---
* athmane_work
  * athmane_work to continue work on Ovirt Node validation testing and
matrix; next meeting review if the spin makes the freeze deadline
* j_dulaney
  * j_dulaney will get this done this week and not slack off again
* tflink
  * tflink will follow up today
  * tflink to confirm with rel-eng to see if 8/1 is a reasonable
deadline
  * tflink to announce blocker meeting #3
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* j_dulaney (94)
* tflink (41)
* athmane_work (17)
* jsmith (8)
* Southern_Gentlem (7)
* kparal (6)
* jboggs (6)
* zodbot (4)
* brunowolff (2)
* thedonvaughn (2)
* jskladan (2)
* nido (1)
* mkrizek (1)
* pschindl (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
  
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

RE: Draft meeting SOP

[John Dulaney]

 
  I have to admit that I find the idea of a meeting sop between perplexing
  and amusing... if you want to meet, you meet. Are we really so
  process-orientated that we can't perform the most basic things without a
  'sop' ?

 I think it is a handy checklist for someone running a meeting who hasn't
 done that before, or that doesn't do it very often.

Indeed.  Having wound up running one of the meetings when James was
unavailable, something like this would have been handy.

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

RE: Draft btrfs testcase

[John Dulaney]

 We will to have add tests cases for checking whether the filesystem
 degrades gracefully when it is being filled up but design is not the
 scope of the test cases.  We would trust the experts, in this case, the
 filesystem developers to take care of that. 

To take care of the design, yes, but test case, no.  I reckon this is
something I can go ahead and hash out without waiting for feature freeze.


I'm thinking something along the lines of (very rough, but illustrates the 
point):

Install
Run benchmark speed test
put  in a bunch of data
Run benchmark speed test (read/write, etc.) when half full
Repeat at 3/4
Repeat at nearly full.
Maybe compare against the same partition/drive with ext4
running the same test with (preferably) the same data?

The question is, how much degradation is acceptable?  I'm thinking the
standard to measure against is ext4 since that is current.  The issue is,
btrfs doesn't even meet ext4 standards now.  It's getting better, but isn't
there, yet.  This is especially so with large files such as those used with
virtual machines.

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

RE: Proposal: Too similar application names

[John Dulaney]

Vita, I'll see if there is anyone at Southeast Linux Fest associated with xcfe 
and lxde.
If so, I'll talk to them directly and report back here.

John

 Date: Wed, 8 Jun 2011 05:37:13 -0400
 From: vhu...@redhat.com
 To: test@lists.fedoraproject.org
 Subject: Re: Proposal: Too similar application names
 CC: l...@lists.fedoraproject.org; desk...@lists.fedoraproject.org; 
 x...@lists.fedoraproject.org; k...@lists.fedoraproject.org
 
  Let's bring this up on today's QA meeting, I am sure we'll get a good
  input on which way to go there.
  
 On the QA meeting on Monday, we've decided to reach out to GNOME for ideas on 
 presenting duplicate application names in the overview. We'll see if they are 
 willing to help us. Based on that we should go either the upstream way - or 
 address the issue merely in downstream.
 
 We should also reach folks at XFCE and LXDE to have this complete, as 
 upstream solution by GNOME would not help tackle this issue in those. KDE has 
 this figured already for some time.
 
 I'll reach out to GNOME, if you guys also have some good contacts (xfce, 
 lxde...) please feel free to share them or please help bringing this up to 
 them as well.
 
 Thanks!
 --
 Vita Humpa
 Fedora 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

RE: Draft btrfs testcase

[John Dulaney]

 A nice start!

Thanks kindly

 If, later on, you also manage to include in subcases that would test the 
 various new features of btrfs (as much as utilities present allow, that 
 is...), I think the test case would be amazing - and essential, should we 
 have btrfs in Fedora 16/17.

Indeed, I think I shall do this.  I was thinking about including all that,
but I hadn't given much thought into how cluttered that would make
things.  Probably would be better to do the sub cases.  I've started
putting together a list of features that are currently usable, and will
starting working on test cases for each of them.

All this is subject to change as things get finalized closer to Alpha.

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

Draft btrfs testcase

[John Dulaney]

I am working on a draft btrfs test case (1) under the assumption
that it will be default for F16.  I'd appreciate any additions or
suggestions for addition.  Note that it isn't finished yet, I'm just
done for the day.

John.


(1) https://fedoraproject.org/wiki/QA:Testcase_btrfs
  -- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

RE: Proposal: Too similar application names

[John Dulaney]

 That all said, question remains on what to actually do on this. In a
 long term I'd suggest trying advocate that there is a appropriate
 solution based in the upstream, might it be pop-ups (sounds reasonable
 to do for all the desktop environments) or something based on how KDE
 does it. Although having upstream to do something is, like I said -
 long term. Thus let's decide on what to do about this now.
 
 I'd say that a number of cases this relates to is limited to a fairly
 small number. I am counting:
 - Software Update/Software Updates
 - System Monitor
 - Terminal
 - system-config-(e.g. date) vs. gnome control panel applets
  (and likely a few more).
 
 As a compromise between getting rid of the problem (user annoyance...)
 completely and the amount of work that would have to be done, I suggest
 that we simply target these applications and modify the desktop files
 so that they become distinguishable. That means in the menus and on the
 first sight, whatever *.desktop field is responsible for that in particular
 environments. Should we manage to push having a popup in Upstream, that
 would be great later on.

I agree, this is a good starting point.  I don't really see the point of the 
popups,
but if other folks think they're necessary, I won't argue.



 Now, should we agree on this quickfix now, how to do that? Am I right
 that this would mean asking the maintainers of these cca 10 packages to
 change the *.desktop files in the packaging process? Do the *.desktop
 files come from upstream or are they made or at least modified already
 by Fedora? I suppose it would be better if they already get modified,
 as then the single extra edit would be less painful for maintainers.
 Still - sounds relatively painless.

In theory, the technical side should be a thirty second fix.  The issue would
be deciding new names.  Some things shouldn't be too difficult, such as
renaming Software Updates to Software Sources.

 We can also consider making a simple (e.g. targeting just default live
 installs) release criterion that would force such, though I'd think
 having it done on voluntary basis is more appropriate.

I wonder if this should be a QA test?  It would help with improving the
end product for us to check things like this, but it is also fairly subjective
as to what constitutes as 'too similar.'  I'm for it, but the aforementioned 
subjective nature makes coming up with a clear release criteria difficult.

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

RE: My Fedora 15 beta experiences so far

[John Dulaney]

Yes, we use the exact same applet in GNOME 3 Fallback Mode
so we have an interest in its continued maintenance for the foreseesble future.


Indeed.  Maybe that's how I got it, from testing fallback?  Anyway, it
still has all the functionality that it had before, or at least everything
I use.  I wonder who maintains it (I'll look it up)?  This is an app
that, because of Fluxbox and several other 'minority' desktops
that would be good to have for some time.  I'm thinking that it should
be quite some time before we have to worry about NM API changes
again (at least I hope so).

John Dulaney

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

RE: hello

[John Dulaney]

This thread should be preserved for all time, now.

 Date: Tue, 24 May 2011 16:35:46 -0500
 From: subscribed-li...@sterndata.com
 To: test@lists.fedoraproject.org
 Subject: Re: hello
 
 On 05/24/2011 04:27 PM, test-annou...@lists.fedoraproject.org wrote:
  hello!
  
  My name is Kate, im hot russian girl, from St. Peterburg.
  I like to internet meeting. (now i find you e-mail in google)
  
  If you are interesting to chat, meet, change photos, hot webcam talk, 
  wright me now to my e mail: k...@rusgirls-list.ru
  
  kisses
  
  p.s. I wait you
  
 
 Another benefit of Fedora 15.  Hot Russian girls want to talk to me.
 Never happened with Windows, that's for sure.
 
 -- 
 -- Steve
 -- 
 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: Release criteria updates: desktop question

[John Dulaney]

 spin-kickstarts-0.15.6-1.fc15 has been built with the state used for RC3.
 It does not include the LXDE commit from after RC3. If a new LXDE is
 built before release then we should probably do another build before
 release. Same if SOAS has and ks changes before it is built. Otherwise
 I'll do another one a bit after the release to pick up the LXDE change.

I know that SoaS will be changed here shortly.  It will happen sooner if I can
get off my butt and get some work done.

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

RE: QA 'vote' at the go/no-go meetings

[John Dulaney]

It has been my understanding that anyone from QA that's present (it happened
I was the only one present for F14 final) can cast the vote (which I did, +1).
If I was wrong in this, then maybe F14 shouldn't have shipped?

I do think that having the meeting as a failsafe is a good idea.

 Hey, all. So, a concern was raised in passing at today's go/no-go
 meeting that we don't have a process to elect or otherwise select
 someone to represent QA at go/no-go meetings; usually myself or jlaska
 will cast QA's 'vote' at this meeting. I'm not sure it makes sense to
 set up a procedure just for this purpose, but what I thought would work
 is this: I've edited the go/no-go meeting wiki page:
 
 https://fedoraproject.org/wiki/Go_No_Go_Meeting
 
 to specify the basis on which QA's 'vote' at this meeting is cast. It's
 really entirely deterministic; there's no discretion involved. If there
 are open unaddressed blockers, we do not approve the candidate for
 release. If there are no open unaddressed blockers, we do approve the
 candidate for release. There's really no wiggle room in this: any reason
 we have to not approve the release should be phrased as a release
 blocking bug in any case. With this in place, it really doesn't matter
 who casts QA's vote, or even if anyone does; QA's position can be
 inferred by anyone who knows how to work a web browser.
 
 I hope that's acceptable to all! If not, or anyone has ideas for
 improvement, do say so...

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

RE: Yum Problem

[John Dulaney]

 Check if you actually have the repo enabled, then.


Not enabled.  Don't know what's going on here.
  -- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

RE: Yum Problem

[John Dulaney]

Obviously, that package is not the issue on my system.  rpm -e says it is
not installed.



yum.log shows nothing.  I'm going to experiment some, but I'm not hopeful.
  -- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Gnome 3

[John Dulaney]

First, I'm going to try to get back into testing.  Life has been overwhelming 
over the past few months
(deaths in the family, stolen vehicle with my new laptop inside, two moves, and 
getting hit by tornadoes).


Anyhow, after mucking about with Gnome 3, I do rather like it.  I won't use it 
as my primary desktop, that
being Fluxbox, but I can see it as being the future interface for Linux.  The 
fact that it is so similar to the
Android interface is a huge plus, and may help push Linux further than anything 
else.  Now we just need
some serious marketing to get the word out there.

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

RE: Fedora 14 Beta Readiness

[John Dulaney]

I had tried to attend, but internets went down just before the meeting started.
 
J. H. Dulaney
 
 Subject: Re: Fedora 14 Beta Readiness
 From: awill...@redhat.com
 To: test@lists.fedoraproject.org
 Date: Fri, 24 Sep 2010 12:00:43 -0700
 
 On Fri, 2010-09-24 at 12:45 -0400, James Laska wrote:
  On Thu, 2010-09-23 at 12:49 -0700, John Poelstra wrote:
   Hi,
   
   We did not have representatives from Documentation, QA, or Translation 
   at the Fedora 14 Beta Release Readiness meeting today.
  
  Apologies, I was unable to attend.
 
 Me too - was on a plane at the time.
 -- 
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
 http://www.happyassassin.net
 
 -- 
 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: F14B RC3 Boot Failure

[John Dulaney]

32 bit version, downloaded yesterday.

J. H. Dulaney

 Subject: Re: F14B RC3 Boot Failure
 From: awill...@redhat.com
 To: test@lists.fedoraproject.org
 Date: Wed, 22 Sep 2010 09:00:07 +0100
 
 On Tue, 2010-09-21 at 23:24 -0400, John Dulaney wrote:
  List:
  I attempted to boot from the LiveCD, and on every box I've tried, I've
  received the same error, RHB #636380.  I've burned the ISO twice, and
  have checked the checksum, so I do not believe that the problem is a
  download/burn error.
 
 Can't reproduce this. Is this the 32-bit or 64-bit image?
 -- 
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
 http://www.happyassassin.net
 
 -- 
 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: Release criteria proposal: fedora release artwork

[John Dulaney]

James, I'll go with that.  I find it confusing if I have F13 and F14 on the 
same box, and if the wrong artwork is used, it may get confusing.
 
Subject: Release criteria proposal: fedora release artwork
From: jla...@redhat.com
To: test@lists.fedoraproject.org
Date: Fri, 10 Sep 2010 09:49:55 -0400
CC: design-t...@lists.fedoraproject.org

Greetings gang,
 
From the last 2 F14 blocker bug meetings [1], it became apparent that we
need release criteria to describe how best to prioritize issues related
to Fedora release artwork.  I took an action item to draft up 2 criteria
to describe the expectations around release artwork before Final, and
for the Final release.  
 
I'd like to propose the following criteria.  As always, comments welcome
and encouraged.
 
= Fedora 14 Alpha =
 * The default Fedora artwork used must either refer to the current
Fedora release under development (Fedora 14), or reference an interim
release milestone (e.g. Alpha or Beta).  If a release version number is
used, it must match the current Fedora release under development.  This
includes artwork used in the installer, firstboot, graphical boot,
graphical login and desktop background.
 
= Fedora 14 Final =
 * The proposed final Fedora artwork is included and enabled by default
for the installer, graphical boot, firstboot, graphical login and
desktop background.  All Fedora artwork must be consistent with the
proposed final theme, and if any artwork contains a graphical version
number, the version number used must match the Fedora release number.
Generic release artwork (e.g. Alpha, Beta, Development) must not be used
for the installer, graphical boot, firstboot, graphical login or the
desktop background.
 
Thanks,
James
 
[1]
http://meetbot.fedoraproject.org/fedora-bugzappers/2010-09-03/fedora-bugzappers.2010-09-03-16.00.html
 

-- 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: [Test-Announce] Fedora 14 Alpha Go/No-Go Meeting August 19, 2010 @ 12:00 AM UTC

[John Dulaney]

Adam,
I will be available.

 Subject: Re: [Test-Announce] Fedora 14 Alpha Go/No-Go Meeting August 19,  
 2010 @ 12:00 AM UTC
 From: awill...@redhat.com
 To: test@lists.fedoraproject.org
 Date: Wed, 18 Aug 2010 10:36:46 -0700
 
 On Tue, 2010-08-17 at 16:59 -0700, John Poelstra wrote:
  Join us on irc.freenode.net #fedora-meeting for this important meeting.
  
  Thursday, August 19, 2010, @ 12:00 AM UTC ( *20:00 EDT/17:00 PDT-- 
  Wednesday, August 18, 2010* )
  
  Before each public release Development, QA, and Release Engineering 
  meet to determine if the release criteria are met for a particular 
  release. This meeting is called the: Go/No-Go Meeting.
  
  Verifying that the Release criteria are met is the responsibility of 
  the QA Team.
  
  For more details about this meeting see: 
  https://fedoraproject.org/wiki/Go_No_Go_Meeting
  
  In the meantime keep an eye on the Fedora 14 Alpha Blocker list (which 
  is currently EMPTY!)
  https://bugzilla.redhat.com/showdependencytree.cgi?id=611990hide_resolved=1
   
 
 James and I both send apologies for this meeting. If someone else wants
 to represent QA - Will? Kamil? Adam M? - that'd be great. James and I
 aren't aware right now of any reason from QA's perspective not to go
 ahead and ship RC4, now 596985 has been decided to be not a blocker. We
 have no open blockers and the test matrices show no blocking fails for
 Alpha tests.
 -- 
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
 http://www.happyassassin.net
 
 -- 
 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: Release criteria proposal: basic graphics mode boot

[John Dulaney]

I agree to both.  In some instances, if you boot the liveCD and you don't
have vesa available, then you won't be able to get to the install bit, as
I well know

John Dulaney

 Subject: Release criteria proposal: basic graphics mode boot
 From: awill...@redhat.com
 To: test@lists.fedoraproject.org
 Date: Wed, 11 Aug 2010 19:35:30 -0700
 
 Another proposed release criterion. This stems from
 https://bugzilla.redhat.com/show_bug.cgi?id=623129 ; we agreed that it
 really ought to always be possible to workaround a broken X driver for
 install.
 
 Alpha: The graphical boot menu for all installation images should
 include an entry which causes both installation and the installed system
 to use a generic, highly compatible video driver (such as 'vesa'). This
 mechanism should work as described.
 
 (I'd actually say live boot menu should have the same option, but
 currently it doesn't and we can't change the world with release
 criteria : I'll try and work up a patch for that to propose).
 -- 
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
 http://www.happyassassin.net
 
 -- 
 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: Release criteria proposal: boot to console

[John Dulaney]

I vote yes to both Beta and Alpha proposals.

 Subject: Release criteria proposal: boot to console
 From: awill...@redhat.com
 To: test@lists.fedoraproject.org
 Date: Wed, 11 Aug 2010 19:19:30 -0700
 
 Hi, folks. Quite a lot of release criteria proposals came out of today's
 go/no-go meeting. I'll propose them formally for discussion and addition
 to the official criteria here.
 
 First off, we are missing criteria for booting to *console* rather than
 graphical desktop. This is important for e.g. minimal installs.
 
 Proposal: two criteria. Alpha:
 
 When booting a system installed without a graphical environment, or
 when using a correct configuration setting to cause an installed system
 to boot in non-graphical mode, the system should boot to a state where
 it is possible to log in through at least one of the default virtual
 consoles.
 
 Beta:
 
 When booting a system installed without a graphical environment, or
 when using a correct configuration setting to cause an installed system
 to boot in non-graphical mode, the system should provide a working login
 prompt without any user intervention (aside from the firstboot utility)
 when boot is complete, and all virtual consoles intended to provide a
 working login prompt should do so.
 
 These read a bit icky to me, clarification / rephrasing would be
 welcome. The key point here is that it was quite widely agreed at the
 go/no-go meeting that we should *not* block an Alpha release if tty1
 doesn't work, as long as one of the other ttys works fine so you can log
 in properly just by doing ctrl-alt-f2 or whatever.
 -- 
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
 http://www.happyassassin.net
 
 -- 
 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: Proven tester special testing procedures: PackageKit and Kernel comment

[John Dulaney]

Either that, or include a recomended procedure with package discription?  
Easily automatable, me thinks.

John Dulaney, great grandson of Arthur Sr.

 Date: Fri, 30 Jul 2010 10:34:40 -0400
 From: boblf...@gmail.com
 To: test@lists.fedoraproject.org
 Subject: Re: Proven tester special testing procedures: PackageKit and Kernel  
 comment
 
   Dear Team:
   Just a suggestion from a busy proventester.  When using 
 fedora-easy-karma it nicely provides links to the bodhi package page and 
 most bug reports related to the update.  For packages which have special 
 testing requirements {kernels and PackageKit} can the link to the 
 testing wiki page an/or test matrix be included in what f-e-k presents 
 to the user.  This would improve my test efficiency anyway and I think 
 most peoples.
 
 Bob Lightfoot
 
 -- 
 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: Release criteria proposal: automated bug checking tools functionality

[John Dulaney]

Why would we have to make it submit reports now?  Unless the steps needed to
implement this are very few, there are plenty of other things that have a higher
priority right now, no?


John Dulaney

 Subject: Release criteria proposal: automated bug checking tools functionality
 From: awill...@redhat.com
 To: test@lists.fedoraproject.org
 Date: Fri, 30 Jul 2010 15:29:00 -0700
 

 I don't think we need Alpha to ship with reporting capabilities intact,
 it's something we can fix post-Alpha release and not lose much, since
 people will be able to submit stored reports once the bug is fixed. Or
 is this again too complex and we should just go with the more stringent
 requirement at Alpha stage?
 -- 
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
 http://www.happyassassin.net

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

RE: Desktop validation testing expansion

[John Dulaney]

At the appropriate points, will we be able to download complete ISOs for each 
desktop, ready to rock and roll?

j_dulaney

 Subject: Desktop validation testing expansion
 From: awill...@redhat.com
 To: x...@lists.fedoraproject.org; l...@lists.fedoraproject.org; 
 k...@lists.fedoraproject.org; test@lists.fedoraproject.org
 Date: Fri, 9 Jul 2010 21:36:06 -0700
 
 Hi, everyone.
 
 I'm sending this email to more widely announce something we've been
 working on for a while. I've spoken to leaders of the XFCE, KDE and LXDE
 teams about this. We'd like to propose expanding the desktop validation
 testing that was initiated in the Fedora 13 cycle.
 
 During F13, these tests were used to check for blocker bugs only for the
 GNOME desktop. We did run the tests against some of the other desktops
 at some checkpoints, but failures from those runs weren't considered as
 blocking the release.
 
 For the Fedora 14 cycle, I'd like to try to run the desktop validation
 test set - that's the testing documented at
 https://fedoraproject.org/wiki/QA:Desktop_validation_testing - on all
 four major desktops at each checkpoint, and consider failures at the
 relevant level to be release blocking bugs.
 
 We've made some adjustments to the test suite already to reflect the
 input from each SIG, and we may yet work on refining the procedure a
 little more, but the outline of the plan is simple enough.
 
 This would be technically on an experimental basis, as the GNOME testing
 was during the F13 cycle; if it seems to be causing too much trouble and
 making it impractical to work to our release plans, we might reconsider
 the idea during the cycle. But we didn't have to do that for F13, and
 I'd hope we won't have to for F14 either.
 
 The leaders of the various desktop SIGs are fairly confident that their
 SIGs will be able to contribute in running the tests and fixing blocker
 issues promptly as they're identified. I think the QA group will also be
 able to contribute to this process, particularly in carrying out the
 testing.
 
 If anyone from QA or any of the SIGs has comments or concerns on the
 proposal, please air them now! Thanks a lot :)
 
 If we do end up going ahead with the idea, I'll follow up with all of
 the SIGs when we hit the first round of validation testing to keep you
 all informed on how the process works and how to contribute to it.
 -- 
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
 http://www.happyassassin.net
 
 -- 
 test mailing list
 test@lists.fedoraproject.org
 To unsubscribe: 
 https://admin.fedoraproject.org/mailman/listinfo/test
  
_
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

RE: Proven tester wiki love

[John Dulaney]

I am wondering, how hard would it be to modify Bodhi to require extra Karma for 
kernels?  Who should I talk to about this possibility?
John, Son of Clay.

 Subject: Re: Proven tester wiki love
 From: awill...@redhat.com
 To: test@lists.fedoraproject.org
 Date: Wed, 7 Jul 2010 12:16:47 -0700
 
 
 Actually, re-reading them, both versions tend to emphasize the negative
 feedback scenarios more than the positive. We should fix that. Positive
 feedback is in a way more important than negative, because we *need*
 proven testers to leave at least +1 on each critpath update (that
 doesn't have a problem, obviously) or it will not get published. We
 should probably explicitly call out that, in general, if you don't hit
 any of the negative or neutral feedback scenarios discussed, you should
 leave positive feedback.
 
 Thinking about it, though, we could consider a slightly different
 process for the kernel, as it's a component that's *extremely* subject
 to different experiences for different users. I'm not sure the workflow
 we've designed will work terribly well for kernels. I suspect it'll be
 all too easy for a kernel which actually contains a major regression to
 be approved; all it needs is for a proventester who doesn't happen to
 own the hardware concerned to find it works fine on their system, and
 file a +1, and anyone else to file a +1 too, and it'd be approved, even
 though someone who does own the hardware might come by and test an hour
 later and find the problem...
 
 we might want to design a system for the kernel where all proventesters
 hold off posting positive feedback for a day or two, until several
 proventesters and regular testers have had the chance to check for
 regressions.
 -- 
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
 http://www.happyassassin.net
 
 -- 
 test mailing list
 test@lists.fedoraproject.org
 To unsubscribe: 
 https://admin.fedoraproject.org/mailman/listinfo/test
  
_
Hotmail is redefining busy with tools for the New Busy. Get more from your 
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

RE: ProvenTesters Sponsorship

[John Dulaney]

I'd say only those interested in being mentors.
Dulaney

 Subject: Re: ProvenTesters Sponsorship
 From: awill...@redhat.com
 To: test@lists.fedoraproject.org
 Date: Tue, 6 Jul 2010 15:16:56 -0700
 
 On Tue, 2010-07-06 at 16:47 -0500, Adam Miller wrote:
  Hello testers!
  
  I wanted to open a conversation on the list about how we want to as a
  group handle sponsorship. I wanted to propose two ideas I had and
  leave the floor open for other suggestions.
  
  1) Allow the sponsors/mentors to individually decide upon new
  proventesters FAS group menbers when they feel the person they are
  mentoring is ready
  2) Have a vote process such that when a proventester-to-be (i.e.-
  currently being mentored) is considered familiar enough with the
  processes by their mentor and has shown a track record of good testing
  practices that they are to present their formal request to the current
  proventesters at a QA meeting and then a vote is given?
  
  The way it is currently outlined in the wiki[0] leans more the
  direction of option 2 but I wanted to bring it up as I think each
  option has some benefits. I like option 1 because the mentor is going
  to be the one who ultimately has (or should have) the closest working
  relationship with the person they are mentoring and therefore would be
  the best judge upon when they are ready. I however also like option
  2 because it feels like a more formal process and allows for some more
  uniformity on how decisions are made, allows for the group as a
  community to constructively critique their peers as well as offers a
  little more oversight in the process.
  
  I also wanted to point out concerns I have with each. Option 1 I feel
  could spawn some feeling of chaos where people are getting added
  willy nilly (cheesy saying, I know ... ) and I worry that Option 2
  could run us into the situation where we could be preventing testers
  from joining in with their critpath contributions (example: request
  comes in on a Tuesday, we have to cancel the meeting the following
  Monday for some reason  2 weeks go by for sponsorship in FAS).
  
  Just my thoughts, please reply with questions, comments, and if need
  be ... snide remarks ;)
 
 Most definitely Option 1, Option 2 is way too much bureaucracy. This
 ain't the Order of the Bath.
 
 I am perfectly happy for people to be added willy-nilly, it's really not
 a problem in my opinion. The reason the group exists is simply to give
 us a control mechanism so that we can take people *out* of it if
 necessary. I don't view it as a terrible disaster if we let someone into
 the group who turns out to either a) suck or b) be be evil, because the
 whole point is that we can then quite easily take them out again. The
 application process and the FAS group are really just there to ensure
 that we have that escape valve, and to provide a little hoop for people
 to jump through so we know they care at least a little bit. That's all.
 
 For me, the only question to settle is if we make every proventester
 member able to sponsor new members, or just ones who express an interest
 in being mentors.
 -- 
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
 http://www.happyassassin.net
 
 -- 
 test mailing list
 test@lists.fedoraproject.org
 To unsubscribe: 
 https://admin.fedoraproject.org/mailman/listinfo/test
  
_
Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Proven Tester documentation

[John Dulaney]

It is done:https://fedoraproject.org/wiki/User:Jdulaney



From: awill...@redhat.com
To: test@lists.fedoraproject.org
Date: Mon, 28 Jun 2010 15:35:57 -0700
Subject: Re: Proven Tester documentation

On Mon, 2010-06-28 at 18:12 -0400, John Dulaney wrote:
 During the meeting today it was decided to combine the Proven Tester
 and Join Proven Tester documentation. I haven't changed much:

Well, more we asked you to provide a draft of a combined page, so we
could see whether it looks better than way :)

It's difficult to get a feel for the draft from a mailing list
transcription. Could you please instead create it as a new draft page in
your own personal space on the Wiki, so we can see it in the proper Wiki
layout?

Your personal space is under your FAS username - so mine's at
https://fedoraproject.org/wiki/User:Adamwill . You can create new pages
under this, like I put my first draft of the proven testers page at
https://fedoraproject.org/wiki/User:Adamwill/Draft_proventesters_instructions . 
You can create a similar page name under your space for your draft. Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net  
_
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test