date:20131217

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

2013-12-17 Thread Adam Williamson

On Mon, 2013-12-16 at 23:26 -0500, John Dulaney wrote:
 Ahoy,
 
 So, I am with Adam on this one (I'm not a mod?).

You weren't actually in the group when I checked, IIRC, and I didn't
want to start adding many more people until I floated the idea on the
list first. Seems like most everyone is positive about it, so I guess we
(admins/mods) can add more people in the next few days.

   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).  

Thanks for the feedback. I think I checked with James last time this
idea came up, and he said it didn't have a specific purpose any more.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

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

2013-12-17 Thread Adam Williamson

On Tue, 2013-12-17 at 10:15 +0530, Akshay Vyas wrote:
  So I'm proposing we do something simple: let's just go ahead and stick
  everyone who can reasonably be considered a 'QA team member' in the   FAS
  'qa' group. This wouldn't be hard to do, I can make sure sufficient
  people within and outside RH have moderator status in the qa group, and
  then those of us who are mods can just add people appropriately. Anyone
  who files karma regularly, or validation test results, or posts to
  test@, or attends QA team meetings, anything like that - let's just
  stick 'em in QA group, and then for the future we can just say
  'moderators can give anyone who's obviously a QA person membership in
  the QA group at any time, and when someone sends a self-introduction
  mail and doesn't completely disappear, the QA group mods should stick
  that person in the group'.
 
 If we can do every QA stuff without being a part of QA group then
 what's the use of creating a QA group

As explained a few times: there are things within Fedora as a whole (not
the QA group) which you need to be a member of a FAS group other than
'cla_done' to get access to - the intent being that only people who are
'members' of Fedora in some way should get them. Space on
fedorapeople.org and voting rights are the two examples I've cited, I
think there may be more than that.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

Re: Proposed validation test case: root on LVM thinp

2013-12-17 Thread Adam Williamson

On Tue, 2013-12-17 at 00:57 -0700, Chris Murphy wrote:
On Dec 16, 2013, at 6:33 PM, Adam Williamson awill...@redhat.com wrote:

Actually - it'd basically just be the 'guided installation' table from
https://fedoraproject.org/wiki/User:Adamwill/Draft_storage_matrix#Guided_installationwithout
all the other bits, basically.

I basically get this. I expect there'll be separate matrices or pages for the
archs?

oh, god, handwave handwave.

That's the 'matrix needs to exist in three dimensions' problem: there's
just too many damn variables. What do we do if for a given test it
matters what storage format you use, *and* whether you're UEFI or BIOS,
*and* whether you, I dunno, pick encryption or not? The fundamental
problem that makes storage validation design such a hard problem to
solve is there's just too many inter-related factors. If you draw up the
table to test every operation under all the different possible
conditions in which you could test it, it's just unmanageable.

So...I'm not sure if there would be separate pages per arch, no. But
please, if you have a viable design which covers as many variables as
possible without producing just too many tests for us to have a hope of
covering, please suggest it! On a meta level, though, I think it's not
possible for us to come up with the perfect storage validation test
plan and have it be actually viable to accomplish: we're going to have
to cut out _some_ variables. It's just a question of which combinations
are the most important and practical to test, and which we have to pass
on.

Question for EFI as an arch, we haven't been testing every layout
presumably because of overlap with x86_64.

More or less. The current greying out of EFI tests was drawn up by me
running through the table very hurriedly one afternoon in the middle of
the F20 cycle, making a quick call as to what things it was most
important to test separately on EFI and BIOS. It's almost certainly not
perfect - please do contribute improvements / corrections to this
determination.

But I'd guess the QA:Testcase_dualboot_with_windows tests for
existing GPT, and EFI System partition, rather than actually creating
them (correctly). I'll bet the code that does that is called once for
all of the guided partition schemes. So it seems like if we check the
Windows case to make sure it doesn't break Windows, we also get a use
existing GPT and ESP test of code; but still need one that creates
new GPT and ESP layout test of the code. Yes? I did that on Mac EFI,
but it's got slightly different code.

Well, define 'need' :/ It's the same problem as above - too many damn
paths, too much stuff that we would _like_ to cover in an ideal world.
We have to somehow make a determination about what we don't cover,
because we can't cover everything.

Do we think it's worth taking that bit out of the larger storage rework
proposal and sticking it in the current matrix, replacing the
appropriate existing test cases? It would be an hour or two's work for
me, I guess. Eh, I guess I'll just draft it up and send it out and see
what you all think.

Why not just delete the appropriate existing test cases rather than merging
them?

That was what I meant by 'replacing the appropriate existing test cases'
- if we like this plan we put the new matrix in and take the old test
cases out.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

Re: Proposed validation test case: root on LVM thinp

2013-12-17 Thread Chris Murphy

On Dec 17, 2013, at 12:57 AM, Chris Murphy li...@colorremedies.com wrote:

On Dec 16, 2013, at 6:33 PM, Adam Williamson awill...@redhat.com wrote:

Actually - it'd basically just be the 'guided installation' table from
https://fedoraproject.org/wiki/User:Adamwill/Draft_storage_matrix#Guided_installationwithout
all the other bits, basically.

I basically get this. I expect there'll be separate matrices or pages for the
archs?

Question for EFI as an arch, we haven't been testing every layout presumably
because of overlap with x86_64. But I'd guess the
QA:Testcase_dualboot_with_windows tests for existing GPT, and EFI System
partition, rather than actually creating them (correctly). I'll bet the code
that does that is called once for all of the guided partition schemes. So it
seems like if we check the Windows case to make sure it doesn't break
Windows, we also get a use existing GPT and ESP test of code; but still
need one that creates new GPT and ESP layout test of the code. Yes? I did
that on Mac EFI, but it's got slightly different code.

Another one I'm thinking of is software RAID. On BIOS, it must be the case that
every member drive is getting a copy of grub2 core.img in the MBR gap, because
when I yank a virtio drive, the system still boots (slowly). I haven't tested
this for EFI or how that could even work because if a member drive goes away
and yet the NVRAM entry is pointing to that particular (bad luck) drive, now
what? I guess there's a fallback NVRAM entry that would be needed pointing to
one of the other drives's EFI System partitions. I don't know that this works.
I assume we want it to work one day.

Might also look at the prebaked grubx64.efi file for what modules are being put
into it. Unlike BIOS which can find all grub modules, it's not working that way
on x86 EFI due to Secure Boot, the grubx64.efi has to be signed. But that
package isn't baking all modules in it. Why I don't know. But the missing ones
might indicate things that work on BIOS that probably break on EFI. The only
one I ran into a while ago was LVM, but funny enough now that lvm.mod is baked
into the grub efi bootloader, we dropped /boot on LVs in anaconda for F20.

Chris Murphy
--
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

2013-12-17 Thread Akshay Vyas

 As explained a few times: there are things within Fedora as a whole (not
 the QA group) which you need to be a member of a FAS group other than
 'cla_done' to get access to - the intent being that only people who are
 'members' of Fedora in some way should get them. Space on
 fedorapeople.org and voting rights are the two examples I've cited, I
 think there may be more than that.

well i think there is some kind of role associated with every group
like ambassadors are suppose to do a promotion and organize events,
adding some one to QA group doesn't make any changes in user
privileges or any other things, well if we talk about fedorapeople.org
or voting then its for every one and there is no group for some
regular voters

On Tue, Dec 17, 2013 at 1:30 PM, Adam Williamson awill...@redhat.com wrote:
 On Tue, 2013-12-17 at 10:15 +0530, Akshay Vyas wrote:
  So I'm proposing we do something simple: let's just go ahead and stick
  everyone who can reasonably be considered a 'QA team member' in the   FAS
  'qa' group. This wouldn't be hard to do, I can make sure sufficient
  people within and outside RH have moderator status in the qa group, and
  then those of us who are mods can just add people appropriately. Anyone
  who files karma regularly, or validation test results, or posts to
  test@, or attends QA team meetings, anything like that - let's just
  stick 'em in QA group, and then for the future we can just say
  'moderators can give anyone who's obviously a QA person membership in
  the QA group at any time, and when someone sends a self-introduction
  mail and doesn't completely disappear, the QA group mods should stick
  that person in the group'.

 If we can do every QA stuff without being a part of QA group then
 what's the use of creating a QA group

 As explained a few times: there are things within Fedora as a whole (not
 the QA group) which you need to be a member of a FAS group other than
 'cla_done' to get access to - the intent being that only people who are
 'members' of Fedora in some way should get them. Space on
 fedorapeople.org and voting rights are the two examples I've cited, I
 think there may be more than that.
 --
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
 http://www.happyassassin.net

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



-- 

Akshay vyas
(http://www.gofedora.in)
-- 
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

2013-12-17 Thread Peter Robinson

On Mon, Dec 16, 2013 at 8:32 PM, Adam Williamson awill...@redhat.com wrote:
 On Mon, 2013-12-16 at 12:23 -0800, Adam Williamson wrote:

 Right now me, James Laska, Will Woods and Jesse Keating are the admins
 of the QA group. This is obviously a bit silly. I'll drop jlaska's,
 wwoods' and jesses' admin roles, and make some more appropriate people
 admins and moderators instead. I'll do that right now, since it's
 clearly the right thing to do...

 For now I've made me, tflink, kparal and viking-ice administrators and
 cmurf a moderator, just as raptor-proofing.

You could consider the same style sponsorship system that the main
packagers group uses so there's then no real need for raptor proofed
admins as it would sort of be self administoring.

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

Re: Proposed validation test case: root on LVM thinp

2013-12-17 Thread Chris Murphy

On Dec 17, 2013, at 1:07 AM, Adam Williamson awill...@redhat.com wrote:

On Tue, 2013-12-17 at 00:57 -0700, Chris Murphy wrote:
On Dec 16, 2013, at 6:33 PM, Adam Williamson awill...@redhat.com wrote:

Actually - it'd basically just be the 'guided installation' table from
https://fedoraproject.org/wiki/User:Adamwill/Draft_storage_matrix#Guided_installationwithout
all the other bits, basically.

I basically get this. I expect there'll be separate matrices or pages for
the archs?

oh, god, handwave handwave.

And we're just talking guided partitioning right now, and yet we need to put it
in a hecatonicosachoron to visualize the ensuing matrix.

But yeah other than ostrich maneuver what's the alternative? The storage
layouts are in fact different between x86_64 and EFI as are the bootloaders.
The least difference is i386 and x86_64, but then there could be a unique bug
(?) that only affects one arch? I dunno that's far fetched but I suppose it
could happen.

On a meta level, though, I think it's not
possible for us to come up with the perfect storage validation test
plan and have it be actually viable to accomplish: we're going to have
to cut out _some_ variables. It's just a question of which combinations
are the most important and practical to test, and which we have to pass
on.

I'm not looking for perfect. I'm just trying to get an idea of what there
really is to test. I haven't gotten to triaging it yet. I think we need to see
the liabilities, show which ones we'll test, and the rest of of that f'n
hecatonicosachoron's cells are holes for someone else to decide the
consequences. As in, get more QA people. Stop the feature creep. Placard Manual
Partitioning as best effort, or spun out into a separate project.

Manual Partitioning is highly vertical use case, OS install only, it doesn't
help people create storage for general purpose scenarios. Yet it could. And
further vertical use case, is that it's Fedora/RHEL specific. So I just don't
see how the wider community really contributes to that in terms of either code
or testing. Difficult to imagine.

Well, define 'need' :/

Need defined by an answer of no to the question, do we want to ship a release
where an install fails (including fails to boot) on EFI because an ESP wasn't
created for some reason?

Another way to do this is have the full matrix of possibilities but so long as
each arch has *one* guided partitioning method that's known to work, we are a
go even if the other possibilities aren't tested. If it turns out that one
option was LVM thinp and everything else was busted, well so be it. More than
likely we're going to have alarm bells going off in the community during beta
if the basic paths are busted, so I don't know that we need to exercise those
that much.

It's the same problem as above - too many damn
paths, too much stuff that we would _like_ to cover in an ideal world.
We have to somehow make a determination about what we don't cover,
because we can't cover everything.

One of the LVM options in guided needs to go. Once LVM thinp is mature enough,
it's better for all use cases. But until then there should be one LVM option in
guided partitioning.

Why not just delete the appropriate existing test cases rather than merging
them?

That was what I meant by 'replacing the appropriate existing test cases'
- if we like this plan we put the new matrix in and take the old test
cases out.

I read yours has moving bits from the new larger matrix to the existing matrix,
taking about 2 hours of work.

I'm suggesting just keep the

Re: xfce does not remember saved sessions on Fedora 20

2013-12-17 Thread Ralf Corsepius


On 12/16/2013 11:38 PM, Kevin Fenzi wrote:

I'm still scratching my head over the other applications not
saving/restoring correctly,


Next probably genuine xfce bug: thunar File Manager windows do not get 
restored to their position they had carried before.


Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1043806

Ralf

--
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

2013-12-17 Thread Jóhann B. Guðmundsson



On þri 17.des 2013 04:26, John Dulaney wrote:

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).


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
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[Test-Announce] Announcing the release of Fedora 20.

2013-12-17 Thread Robyn Bergeron

Greetings!

We can say with great certainty the Fedora Project is pleased to announce the 
release of Fedora 20 (Heisenbug), which coincides with the 10th anniversary 
of the creation of the Fedora Project.  

Download this leading-edge, free and open source operating system now:
http://fedoraproject.org/get-fedora

Detailed information about this release can be seen in the release notes:
http://docs.fedoraproject.org/en-US/Fedora/20/html/Release_Notes/index.html

*** Dedicated to Seth Vidal ***

On July 8, the Fedora Project lost Seth Vidal, a dedicated, tireless, and 
brilliant contributor. Seth was a lead developer of Yum and the Fedora update 
repository system. He worked to ensure that the technical and community 
infrastructure of Fedora worked well and consistently for users and 
contributors around the world. Seth touched the lives of hundreds of Fedora 
contributors directly and millions of others indirectly by improving the 
experience of using and updating Fedora. 

The Fedora Project dedicates the Fedora 20 release to Seth and asks that you 
join us in remembering his generous spirit and incredible work that helped make 
Fedora what it is today. We miss you, Seth. 

*** 10 Years of Fedora ***

The Fedora 20 release coincides with Fedora's tenth anniversary. The first 
Fedora release (then called Fedora Core 1) came out on November 6, 2003. The 
Fedora Project community has grown into an active and vibrant one that produces 
a new version of this leading-edge, free and open source operating system 
around every six months. 

*** Desktop Environments and Spins ***

The Fedora Project strives to provide the best desktop experiences possible for 
users, from desktop environment to application selection. We also produce  
nearly a dozen spins tailor-made for desktop users, hardware design, gaming, 
musicians, artists, and early classroom environments.

Spins are available for download here: 
https://fedoraproject.org/wiki/Releases/20/Spins

== GNOME 3.10 ==

Fedora 20 comes with GNOME 3.10, which has several new applications and 
features that will please GNOME-lovers. This release includes a new music 
application (gnome-music), a new maps application (gnome-maps), a revamp for 
the system status menu, and Zimbra support in Evolution. 

== KDE Plasma Workspaces 4.11 ==

The Fedora KDE SIG has rebased to KDE 4.11 for Fedora 20. This release includes 
faster Nepomuk indexing, improvements to Kontact, KScreen integration in KWin, 
Metalink/HTTP support for KGet, and much more. 

== Spins ==

Spins are alternate versions of Fedora.  In addition to various desktop 
environments for Fedora, spins are also available as tailored environments for 
various types of users via hand-picked application sets or customizations. 

See all of the Fedora 20 Release Spins here: 
https://fedoraproject.org/wiki/Releases/20/Spins

*** ARM as a Primary Architecture ***

While Fedora has supported a number of hardware architectures over the years, 
x86/x86_64 has been the default for the majority of Fedora users and for the 
Linux community in general. 

ARM, however, has been making massive strides. It already dominates the mobile 
market, is becoming a go-to platform for hobbyists and makers, and is showing 
enormous promise for the server market as well. 

In keeping with Fedora's commitment to innovation, the Fedora community has 
been pushing to make ARM a primary architecture to satisfy the needs of users 
and developers targeting the ARM platform.

*** Cloud and Virtualization Improvements ***

The Fedora 20 release continues the Fedora tradition of adopting and 
integrating leading edge technologies used in cloud computing. This release 
includes features that will make working with virtualization and cloud 
computing much easier.

== First-Class Cloud Images ==

The Fedora Cloud SIG has been working hard to provide images that are 
well-suited for running as guests in public and private clouds like Amazon Web 
Services (AWS) and OpenStack. 

If you're using public or private cloud, you should grab one of the 
downloadable Cloud Images or find a supported EC2 image, here:
http://fedoraproject.org/en/get-fedora-options#clouds

== VM Snapshot UI with virt-manager ==

Taking VM snapshots is now much easier. Though qemu and libvirt have all the 
major pieces in place for performing safe VM snapshots/checkpoints, there isn't 
any simple, discoverable UI. This feature will track adding that UI to 
virt-manager and any other virt stack bits that need to be fixed/improved, 
including adding functionality to libvirt to support deleting and rebasing to 
external snapshots.

== ARM on x86 with libvirt/virt-manager ==

You can now run ARM VMs on x86 hosts using standard libvirt tools: libvirt 
virsh, virt-manager and virt-install.

*** Big Data ***

The Fedora 20 release includes all the packages you need to run Apache Hadoop 
2.2.0. Hadoop is a widely used, increasingly complete big data platform with a 
strong, growing

any report of fedup f19-f20?

2013-12-17 Thread Neal Becker

success/failure?

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

52 matches

Mail list logo