Re: gnome-shell high cpu consumption during install?
On Thu, Oct 25, 2012 at 7:11 AM, Chris Murphy li...@colorremedies.com wrote: Is anyone else seeing 100% CPU consumption in top for gnome-shell for the entire installation process? This seems excessive for something that isn't doing anything, or being interacted with. https://dl.dropbox.com/u/3253801/Screen%20Shot%202012-10-24%20at%2010.48.58%20PM.png Are you running on llvmpipe? Does it make sense to use strace to find out what gnome-shell is doing and file a bug on this sort of behavior? And if so what strace options would I use? strace isn't helpful if anything attach gdb and get a backtrace. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F18 Criterions/Testcases interconnection
Hi, I started to connect criterions to testcases for the F18 testing. So far, the Alpha is done (the messy page with criterions links to testcases can be found here https://fedoraproject.org/wiki/User:Jskladan/Sandbox:F18_Criteria_Testcases_Alpha), and it looks all right. Some problems I've come around: -- 10. The installer must be able to install each of the release blocking desktops, as well as the minimal package set, with each supported installation method - We have testcase for the minimal install https://fedoraproject.org/wiki/QA:Testcase_Package_Sets_Minimal_Package_Install but IMHO no testcases for the desktops 13. The installer must allow the user to select which of the disks connected to the system will be affected by the installation process. Disks not selected as installation targets must not be affected by the installation process in any way - IMHO the same testcases as #12 (partitioning related), but none of them requires, that disks not selected must not be affected. 19. 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 - Maybe we'd like to add some specific testcase like https://fedoraproject.org/wiki/QA:Testcase_base_startup seems to be for graphical startup 22. The default desktop background must be different from that of the two previous stable releases - IMHO no testcase coveres this (we have testcases that require 'proper' artwork for beta/final though) 23. Any component which prominently identifies a Fedora release version number, code name or phase (Alpha, Beta, Final) must do so correctly - Same as #22 IMHO 25. 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 - IMHO there is no testcase covering this criterion -- Of couse, I could have missed something, so feel free to point me to the respective testcases. In the mean time, I'm going to get my hands dirty with Beta and Final criterion pairing. J. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Review of Fedora 18 Release Criteria (Second Attempt)
New/Changed Alpha Release Criteria
The installer must be able to install each of the release blocking
desktops, as well as the minimal package set, with each supported
installation method
The installer must be able to complete an installation using
automatic
partitioning to any sufficiently large target disk, whether
unformatted, empty, or containing any kind of existing data
The installer must allow the user to select which of the disks
connected to the system will be affected by the installation process.
Disks not selected as installation targets must not be affected by
the
installation process in any way
New/Changed Beta Release Criteria
The installer must be able to complete an installation using
automatic
partitioning to a validly-formatted disk with sufficient empty space,
using the empty space and installing a bootloader but leaving the
pre-existing partitions and data untouched
All seem reasonable.
=== This is still under review - waiting for input ===
The installer's custom partitioning mode must be capable of the
following:
* Creating, destroying and assigning mount points to partitions of
any specified size using most commonly-used filesystem types
* Creating encrypted partitions
* Rejecting obviously invalid operations without crashing
If you think about it, it's funny that we consider autopart to be easier, and
we require it earlier to be working than custom part, that we consider harder
(now we even think about moving most custom part criteria to Final). But
Alpha/Beta are for hardcore users (more manual part) and Final is for general
users (more autopart). Isn't that a bit... weird? I still wonder whether we
should dictate which parts of UI work and which parts do not, as long as no
user data are unintentionally destroyed.
Anyhow, this is just a food for thought, I'm OK with those criteria.
For each one of the release-blocking package sets ('minimal', and the
package sets for each one of the release-blocking desktops), it must
be
possible to successfully complete an upgrade from a fully updated
installation of the previous stable Fedora release with that package
set installed, using any officially recommended upgrade mechanisms.
The
upgraded system must meet all release criteria.
New/Changed Final Release Criteria
For each one of the release-blocking package sets ('minimal', and the
package sets for each one of the release-blocking desktops), it must
be
possible to successfully complete an upgrade from a fully updated
installation of the previous stable Fedora release with that package
set installed, using all officially recommended upgrade mechanisms.
The
upgraded system must meet all release criteria.
Hopefully with FedUp we will have just a single one officially recommended
upgrade mechanism and we will be able to leave out this criterion. But since we
are quite in the dark now, it makes sense to split it as we did.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion proposal: security
On 10/25/2012 12:06 AM, Adam Williamson wrote: What do folks think of this? Anyone want to tweak what severity issues we block for when, or think the approach is bad? Thanks! We might not want to start at Alpha, on the basis that Alpha is supposed to be for testing*only* and should never have sensitive data committed to it, for instance: we could combine the proposed Alpha criterion into the Beta one. I'm not so sure we want to add security related clause to the criteria since security flaws are just bugs but if people insist that we add one I think we should only apply that security criteria only to final so we wont release the distribution with *known* security fiaw. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Review of Fedora 18 Release Criteria (Second Attempt)
On 10/25/2012 10:04 AM, Kamil Paral wrote: If you think about it, it's funny that we consider autopart to be easier, and we require it earlier to be working than custom part, that we consider harder (now we even think about moving most custom part criteria to Final). But Alpha/Beta are for hardcore users (more manual part) and Final is for general users (more autopart). Isn't that a bit... weird? I still wonder whether we should dictate which parts of UI work and which parts do not, as long as no user data are unintentionally destroyed. We decide a long time ago as in the Alpha criteria was and arguably should be based on only default next next next install from the installer either text based or graphical ( Default partition layout, minimal package group selected, english as a language and keyboard layout on a single disk as in minimal install functionality ) with a clean functional boot up ( kernel/init system ) to terminal with a working login for root and a functional network connection for reporters to be able to update and or install or manually tweak the rest on top of that . Needless to say the Alpha criteria has grown a bit more complex since that time so there is no wonder that we have a bit of inconsistency in it... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 Criterions/Testcases interconnection
Hi, I started to connect criterions to testcases for the F18 testing. So far, the Alpha is done (the messy page with criterions links to testcases can be found here https://fedoraproject.org/wiki/User:Jskladan/Sandbox:F18_Criteria_Testcases_Alpha), and it looks all right. Some problems I've come around: I think we don't have to have a test case for every criterion (sometimes it might not even be possible to write a generic test case), but of course it's good to have most of them reasonably covered. -- 10. The installer must be able to install each of the release blocking desktops, as well as the minimal package set, with each supported installation method - We have testcase for the minimal install https://fedoraproject.org/wiki/QA:Testcase_Package_Sets_Minimal_Package_Install but IMHO no testcases for the desktops We have this: https://fedoraproject.org/wiki/QA:Testcase_Package_Sets_Default_Package_Install That covers GNOME. We could modify it and ask the tester to pick any one of the release blocking desktops to be installed. Do we want to make it fuzzy? (You won't know exactly what was tested). Or we can add a new KDE test case. Or we can leave it as it is. In this case, all variants seem OK to me. I would probably make it fuzzy or do nothing. 13. The installer must allow the user to select which of the disks connected to the system will be affected by the installation process. Disks not selected as installation targets must not be affected by the installation process in any way - IMHO the same testcases as #12 (partitioning related), but none of them requires, that disks not selected must not be affected. 19. 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 - Maybe we'd like to add some specific testcase like https://fedoraproject.org/wiki/QA:Testcase_base_startup seems to be for graphical startup That expected result can be added here: https://fedoraproject.org/wiki/QA:Testcase_Package_Sets_Minimal_Package_Install 22. The default desktop background must be different from that of the two previous stable releases - IMHO no testcase coveres this (we have testcases that require 'proper' artwork for beta/final though) This can be added as an expected result to some of existing test cases. I, personally, miss a generic test case system boots and user logs in, where this could be added. I wouldn't create a separate test case just for this criterion. 23. Any component which prominently identifies a Fedora release version number, code name or phase (Alpha, Beta, Final) must do so correctly - Same as #22 IMHO Same as above. I also think it is fine to have this without a test case. 25. 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 - IMHO there is no testcase covering this criterion It actually is here: https://fedoraproject.org/wiki/QA:Testcase_desktop_login But it is merged with testing keymaps, and I don't like it a bit. Those should be two different test cases. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 Criterions/Testcases interconnection
Beta is done https://fedoraproject.org/wiki/User:Jskladan/Sandbox:F18_Criteria_Testcases_Beta, some issues I've come around: -- 5. The installer must be able to use the HTTP, FTP and either NFS or NFSISO remote package source options - The testcase https://fedoraproject.org/wiki/QA:Testcase_install_repository_NFS_variation https://fedoraproject.org/wiki/QA:Testcase_install_repository_NFSISO_variation is marked as Final Since only one of them has to work for Beta, we could mark both of them as Beta/Final. 6. It must be possible to install by booting the installation kernel directly, including via PXE, and correctly specifying a remote source for the installer itself, using whichever protocols are required to work for package retrieval at the current phase (Alpha, Beta, Final). This must work if the remote source is not a complete repository but contains only the files necessary for the installer itself to run. - https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Pxeboot Marked as Alpha mark as Beta 9. The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched - Testcases as #12 Alpha criterion - Testcases do not mention that pre-existing partitions must be untouched 16. 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 unintended user intervention when boot is complete, and all virtual consoles intended to provide a working login prompt should do so - This is exactly the same as #19 Aplha criterion, maybe we'd like to leave it just Alpha or Beta No, this is a game of spot five differences :-) At least one versus all virtual consoles. This can be part of the same test case, marked as Alpha/Beta 23. All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work - IMHO no testcase covers this Same as in Alpha feedback: https://fedoraproject.org/wiki/QA:Testcase_desktop_login -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome-shell high cpu consumption during install?
On Thu, 2012-10-25 at 09:52 +0200, drago01 wrote: On Thu, Oct 25, 2012 at 7:11 AM, Chris Murphy li...@colorremedies.com wrote: Is anyone else seeing 100% CPU consumption in top for gnome-shell for the entire installation process? This seems excessive for something that isn't doing anything, or being interacted with. https://dl.dropbox.com/u/3253801/Screen%20Shot%202012-10-24%20at%2010.48.58%20PM.png Are you running on llvmpipe? Given that his screenshot appears to be of a virtualbox window, he probably is. - ajax signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Installation Matrix Template - new Anaconda related changes
= Obsoleted Testcases = * https://fedoraproject.org/wiki/QA:Testcase_Package_Sets_Package_Groups_Check = Questions/Discussion = == QA:Testcase Anaconda autopart (use all space) install == https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_%28use_all_space%29_install The current wording requires the user to select use all space. At the moment, Anaconda behaves differently for disk with/without partitions present Shall we 1) Describe both variants in one testcase - i.e. something like If the disk contained any partitions, Reclaim all space 2) Have separate testcases for each variant 3) Something completely different I'm leaning towards #1, but I guess we should discuss this. == QA:Testcase Anaconda autopart (shrink) install == https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_%28shrink%29_install IMHO this testcase will need quite a rewrite, I think something like this could do it: |actions= # Boot the installer using any available means # Proceed to the Installation Destination screen # Choose disk, and select ''Continue'' # At the Installation Options dialog, select ''Reclaim Space'' # Select a previous disk partition to ''Shrink'' # Continue installation, choosing all provided defaults |results= # Anaconda should prompt for an existing partition to resize # Anaconda should successfully resize the selected partition # The system should install successfully # After install, the system boots successfully == QA:Testcase anaconda ext4 rootfs on disk partition == https://fedoraproject.org/wiki/QA:Testcase_anaconda_ext4_rootfs_on_disk_partition As this is basically the new default, this testcase IMHO could be obsoleted (as there is not a 'LVM on rootfs' testcase for F17). Also, new testcase - anaconda_LVM_on_disk_partition (or something like that) should be created as a reasonable replacement -- More to come tomorrow :) J. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F18 at-spi* deps
Why does at-spi(-atk, -core) want to pull out 80+ pkgs from my F18. In F16\17 they only removed themselves. (at-spi, at-spi-core) -- Regards, Frank Jack of all, fubars -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 at-spi* deps
I guess that would be because of https://live.gnome.org/ThreePointFive/Features/AccessibilityOnByDefault On Thu, Oct 25, 2012 at 4:26 PM, Frank Murphy frankl...@gmail.com wrote: Why does at-spi(-atk, -core) want to pull out 80+ pkgs from my F18. In F16\17 they only removed themselves. (at-spi, at-spi-core) -- Regards, Frank Jack of all, fubars -- 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: F18 at-spi* deps
On 25/10/12 15:33, Sandro Mani wrote: I guess that would be because of https://live.gnome.org/ThreePointFive/Features/AccessibilityOnByDefault How do I get rid of it. or at least disable it, in a way that doesn't disable the box. Aside from rpm -e --nodeps, reluctance on my part. -- Regards, Frank Jack of all, fubars -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 at-spi* deps
On Thu, Oct 25, 2012 at 10:26 AM, Frank Murphy frankl...@gmail.com wrote: Why does at-spi(-atk, -core) want to pull out 80+ pkgs from my F18. In F16\17 they only removed themselves. (at-spi, at-spi-core) -- Regards, Frank Jack of all, fubars -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.**org/mailman/listinfo/testhttps://admin.fedoraproject.org/mailman/listinfo/test Looks like gtk3 depends on something provided by at-spi-* and a lot of stuff needs gtk3 :) Tim -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 at-spi* deps
Since the gtk3 configure.ac lists a hard dependency on atk, I guess you can't (unless you can rid the system of gtk3) On Thu, Oct 25, 2012 at 4:40 PM, Frank Murphy frankl...@gmail.com wrote: On 25/10/12 15:33, Sandro Mani wrote: I guess that would be because of https://live.gnome.org/ThreePointFive/Features/AccessibilityOnByDefault How do I get rid of it. or at least disable it, in a way that doesn't disable the box. Aside from rpm -e --nodeps, reluctance on my part. -- Regards, Frank Jack of all, fubars -- 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: F18 at-spi* deps
- Original Message - On 25/10/12 15:33, Sandro Mani wrote: I guess that would be because of https://live.gnome.org/ThreePointFive/Features/AccessibilityOnByDefault How do I get rid of it. or at least disable it, in a way that doesn't disable the box. Aside from rpm -e --nodeps, reluctance on my part. Its not optional anymore. Lets take a step back - why do you want to remove it ? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 at-spi* deps
On 25/10/12 16:24, Matthias Clasen wrote: Its not optional anymore. Lets take a step back - why do you want to remove it ? The same reason I remove all other apps, I don't use. Which is I don't use them. -- Regards, Frank Jack of all, fubars -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 at-spi* deps
- Original Message - On 25/10/12 16:24, Matthias Clasen wrote: Its not optional anymore. Lets take a step back - why do you want to remove it ? The same reason I remove all other apps, I don't use. Which is I don't use them. at-spi* is not an app though. It is a central piece of desktop infrastructure. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion proposal: security
On Thu, 2012-10-25 at 10:17 +, Jóhann B. Guðmundsson wrote: On 10/25/2012 12:06 AM, Adam Williamson wrote: What do folks think of this? Anyone want to tweak what severity issues we block for when, or think the approach is bad? Thanks! We might not want to start at Alpha, on the basis that Alpha is supposed to be for testing *only* and should never have sensitive data committed to it, for instance: we could combine the proposed Alpha criterion into the Beta one. I'm not so sure we want to add security related clause to the criteria since security flaws are just bugs I'm not quite sure what you mean...all blocker bugs are 'just bugs', some bugs are important enough that we shouldn't make releases with those bugs in them. We can't really claim that security bugs violate any of the existing criteria because the existing criteria are focused on functionality, not security. A flaw which would let anyone on the internet read all your data does not, so far as I can see, violate any of the existing criteria (unless you use the 'escape clause' of 'any high severity bug in a critpath package is a blocker, but in practice, we have never really applied that). I think it should constitute a blocker...if others agree, then we need a criterion to express that, since we don't currently have one. but if people insist that we add one I think we should only apply that security criteria only to final so we wont release the distribution with *known* security fiaw. Yeah, I did consider that; it's a viable line to say that Alpha and Beta are test releases so security flaws are not really that significant, you should be using them only for test purposes and trusting no valuable data / systems to them. I think that may well be plausible for Alpha. For Beta it's a bit more problematic, because in practice, 'testing a Beta' can involve giving it at least some exposure to sensitive data/processes. Say you run Fedora on 1,000 client boxes (I don't know if anyone does, but just supposing...) at your school/enterprise/whatever, with a central server containing important data. I think 'testing' Fedora XX Beta is probably going to involve deploying it on one 'test' client in your setup...which is probably going to interact with your actual 'production' network in some way. So I think it might be hard to maintain that we don't need to care about security at all for the Beta. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion proposal: security
On 10/25/2012 06:47 PM, Adam Williamson wrote: On Thu, 2012-10-25 at 10:17 +, Jóhann B. Guðmundsson wrote: On 10/25/2012 12:06 AM, Adam Williamson wrote: What do folks think of this? Anyone want to tweak what severity issues we block for when, or think the approach is bad? Thanks! We might not want to start at Alpha, on the basis that Alpha is supposed to be for testing *only* and should never have sensitive data committed to it, for instance: we could combine the proposed Alpha criterion into the Beta one. I'm not so sure we want to add security related clause to the criteria since security flaws are just bugs I'm not quite sure what you mean...all blocker bugs are 'just bugs', some bugs are important enough that we shouldn't make releases with those bugs in them. We can't really claim that security bugs violate any of the existing criteria because the existing criteria are focused on functionality, not security. A flaw which would let anyone on the internet read all your data does not, so far as I can see, violate any of the existing criteria (unless you use the 'escape clause' of 'any high severity bug in a critpath package is a blocker, but in practice, we have never really applied that). I think it should constitute a blocker...if others agree, then we need a criterion to express that, since we don't currently have one. but if people insist that we add one I think we should only apply that security criteria only to final so we wont release the distribution with *known* security fiaw. Yeah, I did consider that; it's a viable line to say that Alpha and Beta are test releases so security flaws are not really that significant, you should be using them only for test purposes and trusting no valuable data / systems to them. I think that may well be plausible for Alpha. For Beta it's a bit more problematic, because in practice, 'testing a Beta' can involve giving it at least some exposure to sensitive data/processes. Say you run Fedora on 1,000 client boxes (I don't know if anyone does, but just supposing...) at your school/enterprise/whatever, with a central server containing important data. I think 'testing' Fedora XX Beta is probably going to involve deploying it on one 'test' client in your setup...which is probably going to interact with your actual 'production' network in some way. So I think it might be hard to maintain that we don't need to care about security at all for the Beta. Beside the obvious point that a regular bug risk doing just that as well and we already have an policy that is in place to deal with security updates in general, what are we supposed to do if upstream does not provide security fixes for a particular release, and if backporting the fix would be impractical,delay the release indefinitely until they do? I've cc the Releng community to get their input on this + I think we discuss and decide to stay away from security related criteria in the past. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 at-spi* deps
On Thu, 2012-10-25 at 20:33 +0100, Frank Murphy wrote:
On 25/10/12 17:01, Matthias Clasen wrote:
at-spi* is not an app though. It is a central piece of desktop
infrastructure.
Why?
Because treating those who do need accessibility as second-class
citizens means they inevitably get a second-class experience. It's been
integrated so that accessibility enabled is the default state that
everyone tests and develops against.
$ rpm -q --qf=%{size}\\n at-spi2-core at-spi2-atk atk
478463
278812
1123953
1.8M is a pretty modest cost for making the OS accessible to people with
motor, visual, and auditory disabilities. Particularly when doing so
gives your desktop the hooks to make it scriptable. But hey, dislike it
if you want, it's a free internet.
- ajax
signature.asc
Description: This is a digitally signed message part
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Importance of LVM (was Re: Partitioning criteria revision proposal)
On Tue, 2012-10-16 at 17:55 -0700, Adam Williamson wrote: BTW, on the topic of LVM specifically (whose importance we still haven't really established): I did some archive-diving last week. We first went to LVM-by-default all the way back in Fedora Core 3. There were two reasons for doing this. The 'official' one was to make it easier to expand the capacity of a system simply by adding another hard disk. The less official reason was to get more testing of LVM, which was still in its infancy at the time. Ever since then, we've stuck with the default really just because it's always been there; until I started poking into it, no-one really had a story for why LVM was default any more. Neither reason really applies much any more. LVM is much more mature now, and in a way is yesterday's news, the Glorious Future maybe belongs to btrfs. And we've finally hit the point in history where most people don't run out of space on the hard disk that comes with their system, and even when they _do_ run out of space, it's usually not with OS data but with 'user data' that is much easier to spread across multiple disks without using LVM. So I'm not sure we really have a convincing reason any more to care especially about LVM. On this topic...Ric Wheeler came up with some fairly good arguments in favour of keeping the LVM default and proposed it on the anaconda list this morning (actually I think the post may not have been approved yet, but it'll show up soon). Since we're post-freeze now I summarized the debate into a bug report and nominated it for NTH: https://bugzilla.redhat.com/show_bug.cgi?id=870207 I think it's still true to say that our *original* reasons for defaulting to LVM don't really hold any more, but Ric made some pretty decent *current* arguments for keeping that default until we switch to btrfs-by-default. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On 10/25/2012 08:26 PM, Adam Williamson wrote: On this topic...Ric Wheeler came up with some fairly good arguments in favour of keeping the LVM default and proposed it on the anaconda list this morning (actually I think the post may not have been approved yet, but it'll show up soon). Since we're post-freeze now I summarized the debate into a bug report and nominated it for NTH: https://bugzilla.redhat.com/show_bug.cgi?id=870207 I think it's still true to say that our*original* reasons for defaulting to LVM don't really hold any more, but Ric made some pretty decent*current* arguments for keeping that default until we switch to btrfs-by-default. First of all this has been known this whole time Ric is not bringing anything new to the table and I nack to this proposal it's to dam late in the release cycle to change this now and if we change this it means we have to slip another week to properly test anaconda with lvm as default against the alpha and beta criteria Can we please stop messing around with the installer! JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Thu, 2012-10-25 at 20:41 +, Jóhann B. Guðmundsson wrote: On 10/25/2012 08:26 PM, Adam Williamson wrote: On this topic...Ric Wheeler came up with some fairly good arguments in favour of keeping the LVM default and proposed it on the anaconda list this morning (actually I think the post may not have been approved yet, but it'll show up soon). Since we're post-freeze now I summarized the debate into a bug report and nominated it for NTH: https://bugzilla.redhat.com/show_bug.cgi?id=870207 I think it's still true to say that our *original* reasons for defaulting to LVM don't really hold any more, but Ric made some pretty decent *current* arguments for keeping that default until we switch to btrfs-by-default. First of all this has been known this whole time Ric is not bringing anything new to the table and I nack to this proposal it's to dam late in the release cycle to change this now and if we change this it means we have to slip another week to properly test anaconda with lvm as default against the alpha and beta criteria Can we please stop messing around with the installer! Like I said in the bug I also think it's pretty late to change this, but the change is in fact small and simple: the autopart code hasn't actually changed in newUI and has always had the ability to do both LVM and non-LVM layouts (in oldUI, remember, we gave you a checkbox to pick). All the patch does is change the default for the autopart algorithm, it's a two-liner: diff --git a/pyanaconda/ui/gui/spokes/storage.py b/pyanaconda/ui/gui/spokes/storage.py index 14ea404..6d7d9b6 100644 --- a/pyanaconda/ui/gui/spokes/storage.py +++ b/pyanaconda/ui/gui/spokes/storage.py @@ -337,8 +337,7 @@ class StorageSpoke(NormalSpoke, StorageChecker): self.data.autopart.encrypted = self.encrypted self.data.autopart.passphrase = self.passphrase -# no thanks, lvm -self.data.autopart.type = AUTOPART_TYPE_PLAIN +self.data.autopart.type = AUTOPART_TYPE_LVM self.clearPartType = CLEARPART_TYPE_NONE diff --git a/pyanaconda/ui/tui/spokes/storage.py b/pyanaconda/ui/tui/spokes/storage.py index c0a7cdd..b486657 100644 --- a/pyanaconda/ui/tui/spokes/storage.py +++ b/pyanaconda/ui/tui/spokes/storage.py @@ -229,8 +229,7 @@ class StorageSpoke(NormalTUISpoke): self.data.ignoredisk.onlyuse = self.selected_disks[:] self.data.clearpart.drives = self.selected_disks[:] -# no thanks, lvm -self.data.autopart.type = AUTOPART_TYPE_PLAIN +self.data.autopart.type = AUTOPART_TYPE_LVM if self.autopart: self.clearPartType = CLEARPART_TYPE_ALL and the code we're using is the same code we used and tested in all previous releases. So it's not actually a terribly scary change. On that basis I'm not horribly worried about doing it in practical terms, though I agree it would have been better to do it earlier. I'm about to post an updates.img to the bug you can use to test the change with TC6. I'm doing a first test of it right now and it seems to be working fine. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Thu, Oct 25, 2012 at 10:26 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-10-16 at 17:55 -0700, Adam Williamson wrote: BTW, on the topic of LVM specifically (whose importance we still haven't really established): I did some archive-diving last week. We first went to LVM-by-default all the way back in Fedora Core 3. There were two reasons for doing this. The 'official' one was to make it easier to expand the capacity of a system simply by adding another hard disk. The less official reason was to get more testing of LVM, which was still in its infancy at the time. Ever since then, we've stuck with the default really just because it's always been there; until I started poking into it, no-one really had a story for why LVM was default any more. Neither reason really applies much any more. LVM is much more mature now, and in a way is yesterday's news, the Glorious Future maybe belongs to btrfs. And we've finally hit the point in history where most people don't run out of space on the hard disk that comes with their system, and even when they _do_ run out of space, it's usually not with OS data but with 'user data' that is much easier to spread across multiple disks without using LVM. So I'm not sure we really have a convincing reason any more to care especially about LVM. On this topic...Ric Wheeler came up with some fairly good arguments in favour of keeping the LVM default and proposed it on the anaconda list this morning (actually I think the post may not have been approved yet, but it'll show up soon). Since we're post-freeze now I summarized the debate into a bug report and nominated it for NTH: https://bugzilla.redhat.com/show_bug.cgi?id=870207 I think it's still true to say that our *original* reasons for defaulting to LVM don't really hold any more, but Ric made some pretty decent *current* arguments for keeping that default until we switch to btrfs-by-default. What exactly does not hold anymore? Resizing partitions isn't that common and not the primary use of LVM (you can do it without it and most users won't). It is still pretty much useless (as in the extra features won't be used) for the average desktop / laptop installs. For most users all it does is slowing down the boot process (we should stop adding crap to the default boot process because someone might need it on some obscure case). Those who know about the extra features and want to use them will enable it anyway regardless on what we set as defaults. So no -1 on that. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to reopen a bug?
once it is changed to assigned (and save changes), all the options show up (in the top) where it can be reopened. That's what I did once and it worked. I do not know if this is the right way to reopen though. On 10/25/2012 03:41 PM, Chris Murphy wrote: https://bugzilla.redhat.com/show_bug.cgi?id=868468 I only have the option to change this bug to assigned. Is that what I'm supposed to do, or other? Chris Murphy -- -- nonamedotc -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Thu, 2012-10-25 at 22:51 +0200, drago01 wrote: On Thu, Oct 25, 2012 at 10:26 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-10-16 at 17:55 -0700, Adam Williamson wrote: BTW, on the topic of LVM specifically (whose importance we still haven't really established): I did some archive-diving last week. We first went to LVM-by-default all the way back in Fedora Core 3. There were two reasons for doing this. The 'official' one was to make it easier to expand the capacity of a system simply by adding another hard disk. The less official reason was to get more testing of LVM, which was still in its infancy at the time. Ever since then, we've stuck with the default really just because it's always been there; until I started poking into it, no-one really had a story for why LVM was default any more. Neither reason really applies much any more. LVM is much more mature now, and in a way is yesterday's news, the Glorious Future maybe belongs to btrfs. And we've finally hit the point in history where most people don't run out of space on the hard disk that comes with their system, and even when they _do_ run out of space, it's usually not with OS data but with 'user data' that is much easier to spread across multiple disks without using LVM. So I'm not sure we really have a convincing reason any more to care especially about LVM. On this topic...Ric Wheeler came up with some fairly good arguments in favour of keeping the LVM default and proposed it on the anaconda list this morning (actually I think the post may not have been approved yet, but it'll show up soon). Since we're post-freeze now I summarized the debate into a bug report and nominated it for NTH: https://bugzilla.redhat.com/show_bug.cgi?id=870207 I think it's still true to say that our *original* reasons for defaulting to LVM don't really hold any more, but Ric made some pretty decent *current* arguments for keeping that default until we switch to btrfs-by-default. What exactly does not hold anymore? Resizing partitions isn't that common and not the primary use of LVM (you can do it without it and most users won't). You can do it without LVM, but not as reliably (you're *more* likely to get into trouble resizing a raw ext4 partition than an LV) and with more limitations (the big one being you can't resize an ext4 partition from the front: so if you have a disk with 10GB / then 100GB /home, and you fill up /, you can't make /home smaller and use the additional space for /, because it can't be contiguous. All you can do is create a new partition after /home and bodge it up somehow, by mounting it as /var or something; much messier). 'most users won't' is hard to prove but likely true, but then, *some* users will, and isn't it nice that they have the ability to do it? It is still pretty much useless (as in the extra features won't be used) for the average desktop / laptop installs. They're neat features, though, and they're available, and _some_ people can use them, and people who don't use them aren't hurt (except see below). For most users all it does is slowing down the boot process (we should stop adding crap to the default boot process because someone might need it on some obscure case). Does LVM slow down boot significantly? Do you have numbers for that? I hadn't heard that factor cited in the debate so far. Could you add it to the bug if you have solid data? It'd be useful input. Those who know about the extra features and want to use them will enable it anyway regardless on what we set as defaults. It's somewhat harder to change in newUI than oldUI because there isn't just a checkbox for it, and I don't think the designers want there to be one. To change from the default (whatever the default is) you have to go through custom partitioning. Also, this doesn't catch the case of someone who's never used LVM, does an install of Fedora, notices that it uses LVM, and gets interested about it and finds out the neat stuff it can do. That's not a terribly unusual use case for Linux distros in general, is it? We all start out as newbies after all...I often find out about cool stuff 'by accident' in this way, just by stumbling across it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to reopen a bug?
On Thu, 2012-10-25 at 15:52 -0500, Nonamedotc wrote: once it is changed to assigned (and save changes), all the options show up (in the top) where it can be reopened. That's what I did once and it worked. I do not know if this is the right way to reopen though. It is. Or at least, the only one I've ever found. I don't believe there's a way to go straight from CLOSED to (any open status you like), only CLOSED - ASSIGNED. That's re-opening the bug. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion proposal: security
On Thu, 2012-10-25 at 19:11 +, Jóhann B. Guðmundsson wrote: but if people insist that we add one I think we should only apply that security criteria only to final so we wont release the distribution with *known* security fiaw. Yeah, I did consider that; it's a viable line to say that Alpha and Beta are test releases so security flaws are not really that significant, you should be using them only for test purposes and trusting no valuable data / systems to them. I think that may well be plausible for Alpha. For Beta it's a bit more problematic, because in practice, 'testing a Beta' can involve giving it at least some exposure to sensitive data/processes. Say you run Fedora on 1,000 client boxes (I don't know if anyone does, but just supposing...) at your school/enterprise/whatever, with a central server containing important data. I think 'testing' Fedora XX Beta is probably going to involve deploying it on one 'test' client in your setup...which is probably going to interact with your actual 'production' network in some way. So I think it might be hard to maintain that we don't need to care about security at all for the Beta. Beside the obvious point that a regular bug risk doing just that as well and we already have an policy that is in place to deal with security updates in general, Sure, that's the reason for the potential distinction between bugs that _can_ be fixed with updates and those that _can't_. This discussion was prompted by a specific bug - https://bugzilla.redhat.com/show_bug.cgi?id=868519 - which can't be fixed with an update, because it's an issue in anaconda. Just like any bug in anaconda, we can't fix it with a post-release update. what are we supposed to do if upstream does not provide security fixes for a particular release, and if backporting the fix would be impractical,delay the release indefinitely until they do? That is a valid concern, indeed. We could add wording to exclude bugs for which a fix is not viable? Also if we restrict the criteria to only security bugs that are not fixable with an update, that might go quite some way to addressing this in practice, because I think it's fair to say we ought to have the development resources within Fedora to come up for a fix to any 'non-update-fixable' security issues ourselves. I've cc the Releng community to get their input on this + I think we discuss and decide to stay away from security related criteria in the past. Thanks, if anyone has useful data from past discussions it'd help indeed. In my archives I can find *part* of a thread from May 2011 but I can't find the start of it...I'll have a closer look later. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 at-spi* deps
On 25/10/12 15:45, tim.laurid...@gmail.com wrote: Looks like gtk3 depends on something provided by at-spi-* and a lot of stuff needs gtk3 :) Tim Yeah, I'll work through those and see what I can dump. Might be a good learning experience. -- Regards, Frank Jack of all, fubars -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 at-spi* deps
On 25/10/12 21:23, Adam Jackson wrote: On Thu, 2012-10-25 at 20:33 +0100, Frank Murphy wrote: On 25/10/12 17:01, Matthias Clasen wrote: at-spi* is not an app though. It is a central piece of desktop infrastructure. Why? Because treating those who do need accessibility as second-class citizens means they inevitably get a second-class experience. I agree, but I don't need it, Wheres the script to turn if off? Everone else has to figure that out themselves. accessibilty.conf has no on=0\false switch. -- Regards, Frank Jack of all, fubars -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 at-spi* deps
On Thu, 2012-10-25 at 22:21 +0100, Frank Murphy wrote: I agree, but I don't need it, Wheres the script to turn if off? Everone else has to figure that out themselves. accessibilty.conf has no on=0\false switch. If the F18 install I just did is any indication, the state it ships in is as off as it gets. - ajax signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Review of Fedora 18 Release Criteria (Second Attempt)
On Thu, 2012-10-25 at 10:39 +, Jóhann B. Guðmundsson wrote: On 10/25/2012 10:04 AM, Kamil Paral wrote: If you think about it, it's funny that we consider autopart to be easier, and we require it earlier to be working than custom part, that we consider harder (now we even think about moving most custom part criteria to Final). But Alpha/Beta are for hardcore users (more manual part) and Final is for general users (more autopart). Isn't that a bit... weird? I still wonder whether we should dictate which parts of UI work and which parts do not, as long as no user data are unintentionally destroyed. We decide a long time ago as in the Alpha criteria was and arguably should be based on only default next next next install from the installer either text based or graphical ( Default partition layout, minimal package group selected, english as a language and keyboard layout on a single disk as in minimal install functionality ) with a clean functional boot up ( kernel/init system ) to terminal with a working login for root and a functional network connection for reporters to be able to update and or install or manually tweak the rest on top of that . Needless to say the Alpha criteria has grown a bit more complex since that time so there is no wonder that we have a bit of inconsistency in it... As far as partitioning goes, that's what Alpha criteria cover right now, the Alpha criterion for partitioning is very minimalistic. One thing I've been vaguely wondering about, down these same lines, is whether we focus too much in the criteria on whether things *work*, and not enough on whether they're *testable*. But like Kamil's thoughts this isn't really fully formed yet, just a question I've been probing... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 Criterions/Testcases interconnection
On Thu, 2012-10-25 at 06:51 -0400, Kamil Paral wrote: 10. The installer must be able to install each of the release blocking desktops, as well as the minimal package set, with each supported installation method - We have testcase for the minimal install https://fedoraproject.org/wiki/QA:Testcase_Package_Sets_Minimal_Package_Install but IMHO no testcases for the desktops We have this: https://fedoraproject.org/wiki/QA:Testcase_Package_Sets_Default_Package_Install That covers GNOME. We could modify it and ask the tester to pick any one of the release blocking desktops to be installed. Do we want to make it fuzzy? (You won't know exactly what was tested). Or we can add a new KDE test case. Or we can leave it as it is. In this case, all variants seem OK to me. I would probably make it fuzzy or do nothing. I think Josef's probably right here, the most straightforward thing to do would seem to be to just test it explicitly. It's in the criteria, writing the test case(s) should be simple, and they're not onerous tests to do, so I don't really see a problem. I think 'the default package set install works' is a Thing in itself, so I'd probably be more in favour of adding a separate test case which covers installing each of the release-blocking desktops and can be marked as 'pass' only if they all work. In practice, whoever's doing the test obviously can 'count' the default_package_install result towards the release_blocking_package_sets_install (or whatever we call it) test case if the default package set at the time happens to correspond to one of the release-blocking desktops, as it does now. So I'd imagine this would happen: 1. Tester checks that a default install works, marks default_package_install test as pass 2. Tester checks that a KDE install works, and then marks release_blocking_package_sets_install as pass in the future if our default package set is somehow not a release blocking desktop any more, or we get more release blocking desktops, everything continues to work out, testers just have a bit more testing to do before marking release_blocking_package_sets_install as pass. 19. 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 - Maybe we'd like to add some specific testcase like https://fedoraproject.org/wiki/QA:Testcase_base_startup seems to be for graphical startup That expected result can be added here: https://fedoraproject.org/wiki/QA:Testcase_Package_Sets_Minimal_Package_Install I believe this is in fact covered in https://fedoraproject.org/wiki/QA:Testcase_base_startup . 22. The default desktop background must be different from that of the two previous stable releases - IMHO no testcase coveres this (we have testcases that require 'proper' artwork for beta/final though) This can be added as an expected result to some of existing test cases. I, personally, miss a generic test case system boots and user logs in, where this could be added. I wouldn't create a separate test case just for this criterion. This is again covered by https://fedoraproject.org/wiki/QA:Testcase_base_startup (it's easy to forget about the Base tests, but don't!) I think the 'expected results' need a bit of tweaking for the revisions we made to the artwork criterion, though. 25. 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 - IMHO there is no testcase covering this criterion It actually is here: https://fedoraproject.org/wiki/QA:Testcase_desktop_login But it is merged with testing keymaps, and I don't like it a bit. Those should be two different test cases. For the record this happened the other way around - we had the 'login' test case and sort of stretched it to cover keymap issues, instead of creating a new test case. For me this works in practical terms, it kind of works out efficiently to test those things together. But it's not the most elegant organization ever, no. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Thu, Oct 25, 2012 at 11:09 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2012-10-25 at 22:51 +0200, drago01 wrote: On Thu, Oct 25, 2012 at 10:26 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-10-16 at 17:55 -0700, Adam Williamson wrote: BTW, on the topic of LVM specifically (whose importance we still haven't really established): I did some archive-diving last week. We first went to LVM-by-default all the way back in Fedora Core 3. There were two reasons for doing this. The 'official' one was to make it easier to expand the capacity of a system simply by adding another hard disk. The less official reason was to get more testing of LVM, which was still in its infancy at the time. Ever since then, we've stuck with the default really just because it's always been there; until I started poking into it, no-one really had a story for why LVM was default any more. Neither reason really applies much any more. LVM is much more mature now, and in a way is yesterday's news, the Glorious Future maybe belongs to btrfs. And we've finally hit the point in history where most people don't run out of space on the hard disk that comes with their system, and even when they _do_ run out of space, it's usually not with OS data but with 'user data' that is much easier to spread across multiple disks without using LVM. So I'm not sure we really have a convincing reason any more to care especially about LVM. On this topic...Ric Wheeler came up with some fairly good arguments in favour of keeping the LVM default and proposed it on the anaconda list this morning (actually I think the post may not have been approved yet, but it'll show up soon). Since we're post-freeze now I summarized the debate into a bug report and nominated it for NTH: https://bugzilla.redhat.com/show_bug.cgi?id=870207 I think it's still true to say that our *original* reasons for defaulting to LVM don't really hold any more, but Ric made some pretty decent *current* arguments for keeping that default until we switch to btrfs-by-default. What exactly does not hold anymore? Resizing partitions isn't that common and not the primary use of LVM (you can do it without it and most users won't). You can do it without LVM, but not as reliably (you're *more* likely to get into trouble resizing a raw ext4 partition than an LV) and with more limitations (the big one being you can't resize an ext4 partition from the front: so if you have a disk with 10GB / then 100GB /home, and you fill up /, you can't make /home smaller and use the additional space for /, because it can't be contiguous. All you can do is create a new partition after /home and bodge it up somehow, by mounting it as /var or something; much messier). 'most users won't' is hard to prove but likely true, but then, *some* users will, and isn't it nice that they have the ability to do it? Yes but that can be said about pretty much anything. It is still pretty much useless (as in the extra features won't be used) for the average desktop / laptop installs. They're neat features, though, and they're available, and _some_ people can use them, and people who don't use them aren't hurt (except see below). For most users all it does is slowing down the boot process (we should stop adding crap to the default boot process because someone might need it on some obscure case). Does LVM slow down boot significantly? Do you have numbers for that? I hadn't heard that factor cited in the debate so far. Could you add it to the bug if you have solid data? It'd be useful input. I don't have current numbers but it adds a synchronisation point (i.e breaks a fully parallel bootup) let me just quote this (http://0pointer.de/blog/projects/blame-game.html): Let's have a closer look at the worst offender on this boot: a service by the name of udev-settle.service. So why does it take that much time to initialize, and what can we do about it? This service actually does very little: it just waits for the device probing being done by udev to finish and then exits. Device probing can be slow. [..] So, why is udev-settle.service part of our boot process? Well, it actually doesn't need to be. It is pulled in by the storage setup logic of Fedora: to be precise, by the *LVM*, RAID and Multipath setup script. These storage services have not been implemented in the way hardware detection and probing work today: they expect to be initialized at a point in time where all devices have been probed, so that they can simply iterate through the list of available disks and do their work on it. However, on modern machinery this is not how things actually work: hardware can come and hardware can go all the time, during boot and during runtime. For some technologies it is not even possible to know when the device enumeration is complete (example: USB, or iSCSI), thus waiting for all storage devices to show up and be probed must
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
I think it's way quite late in the cycle to talk about merits and drawbacks of LVM by default. It's quite late for discussing what is a better default. And that's why we should stick to the long term default, that means LVM. Personally I didn't like (maybe even hated) LVM when I started to work on Fedora. Now I like it. But that doesn't matter. The problem is that this issue was not properly discussed. There should have been a long thread on the lists. Different people should have posted their opinions. Measurements should have been made with regard to the boot time. FESCo should have posted their stance. Et cetera et cetera. The default was flipped to raw partitions in early builds of F18 Anaconda, and that was unfortunate, because it lacked a proper discussion and announcement (it was quite a surprise for QA). It is still (barely) time to flip the default back, to what it always was. But there's no way enough time to _start_ the discussion now. It would consume weeks and by that time Beta should be out. I think there are some LVM haters in the community who finally saw a chance to cleanse Fedora of this evil, and now will be very angry if someone wants to revert it. They might be wrong, they might be right. But I don't think this is the discussion we want to have now. That discussion should target Fedora 19. Now we should keep the defaults from previous Fedora versions. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Fri, 2012-10-26 at 00:12 +0200, drago01 wrote: Also, this doesn't catch the case of someone who's never used LVM, does an install of Fedora, notices that it uses LVM, and gets interested about it and finds out the neat stuff it can do. That's not a terribly unusual use case for Linux distros in general, is it? We all start out as newbies after all...I often find out about cool stuff 'by accident' in this way, just by stumbling across it. He might also find find out that it is useless for him and that he cannot (easily) remove it without reinstalling. I am not saying LVM does not have use cases where it makes sense. I just don't think it makes sense as a default. I guess I just don't really get this. Maybe it comes from the fact that I know my computer is doing all sorts of stuff all the time that I don't 'need' it to do. But I don't really feel compelled to go and build a kernel with all the drivers I don't use taken out, and hack up udev not to probe things I don't care about, and and and... if something's happening that isn't benefiting me right at this second I don't feel some kind of compulsion to RIP IT OUT RIP OUT THE EVIL NOW. So someone finds their system is using LVM and they don't feel like taking advantage of any of LVM's specific benefits right now. Fine. What have they lost? Why would you be so terribly angry that you can't 'remove it'? I mean, ext4 probably has benefits I'm not using right now, but I'm not feeling compelled to switch my disks to something less capable... The performance point is likely worth bringing up in the bug, though. (Of course, invoking Lennart in any debate can have its own pitfalls :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 Criterions/Testcases interconnection
We have this: https://fedoraproject.org/wiki/QA:Testcase_Package_Sets_Default_Package_Install That covers GNOME. We could modify it and ask the tester to pick any one of the release blocking desktops to be installed. Do we want to make it fuzzy? (You won't know exactly what was tested). Or we can add a new KDE test case. Or we can leave it as it is. In this case, all variants seem OK to me. I would probably make it fuzzy or do nothing. I think Josef's probably right here, the most straightforward thing to do would seem to be to just test it explicitly. It's in the criteria, writing the test case(s) should be simple, and they're not onerous tests to do, so I don't really see a problem. I think 'the default package set install works' is a Thing in itself, so I'd probably be more in favour of adding a separate test case which covers installing each of the release-blocking desktops and can be marked as 'pass' only if they all work. In practice, whoever's doing the test obviously can 'count' the default_package_install result towards the release_blocking_package_sets_install (or whatever we call it) test case if the default package set at the time happens to correspond to one of the release-blocking desktops, as it does now. So I'd imagine this would happen: 1. Tester checks that a default install works, marks default_package_install test as pass 2. Tester checks that a KDE install works, and then marks release_blocking_package_sets_install as pass in the future if our default package set is somehow not a release blocking desktop any more, or we get more release blocking desktops, everything continues to work out, testers just have a bit more testing to do before marking release_blocking_package_sets_install as pass. That is algorithmically perfect, but over-engineered [1]. I think it's much easier to have a default_package_install and a KDE_package_install and adjust it if the defaults changes, than to think about the correct workflow every time we execute the tests (I understand I'll be fired for saying this, but I tend to forget these things. I also want to make release validation more accessible for newcomers). [1] $ python -c 'import this' -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Fri, Oct 26, 2012 at 12:35 AM, Adam Williamson awill...@redhat.com wrote: On Fri, 2012-10-26 at 00:12 +0200, drago01 wrote: Also, this doesn't catch the case of someone who's never used LVM, does an install of Fedora, notices that it uses LVM, and gets interested about it and finds out the neat stuff it can do. That's not a terribly unusual use case for Linux distros in general, is it? We all start out as newbies after all...I often find out about cool stuff 'by accident' in this way, just by stumbling across it. He might also find find out that it is useless for him and that he cannot (easily) remove it without reinstalling. I am not saying LVM does not have use cases where it makes sense. I just don't think it makes sense as a default. I guess I just don't really get this. Maybe it comes from the fact that I know my computer is doing all sorts of stuff all the time that I don't 'need' it to do. But I don't really feel compelled to go and build a kernel with all the drivers I don't use taken out, and hack up udev not to probe things I don't care about, and and and... My point is that there is a cost of adding it. While the benefit for the majority of users is almost zero (messing with the system partitions is not a thing lots of people do after installation). We are pretty much the only distro that used it by default. if something's happening that isn't benefiting me right at this second I don't feel some kind of compulsion to RIP IT OUT RIP OUT THE EVIL NOW. That wasn't my point ... So someone finds their system is using LVM and they don't feel like taking advantage of any of LVM's specific benefits right now. Fine. What have they lost? See above (and the other post). Why would you be so terribly angry that you can't 'remove it'? I mean, ext4 probably has benefits I'm not using right now, but I'm not feeling compelled to switch my disks to something less capable... Because you don't gain much by using something less capable. The performance point is likely worth bringing up in the bug, though. (Of course, invoking Lennart in any debate can have its own pitfalls :) Done. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 Criterions/Testcases interconnection
On Thu, 2012-10-25 at 18:47 -0400, Kamil Paral wrote: I think 'the default package set install works' is a Thing in itself, so I'd probably be more in favour of adding a separate test case which covers installing each of the release-blocking desktops and can be marked as 'pass' only if they all work. In practice, whoever's doing the test obviously can 'count' the default_package_install result towards the release_blocking_package_sets_install (or whatever we call it) test case if the default package set at the time happens to correspond to one of the release-blocking desktops, as it does now. So I'd imagine this would happen: 1. Tester checks that a default install works, marks default_package_install test as pass 2. Tester checks that a KDE install works, and then marks release_blocking_package_sets_install as pass in the future if our default package set is somehow not a release blocking desktop any more, or we get more release blocking desktops, everything continues to work out, testers just have a bit more testing to do before marking release_blocking_package_sets_install as pass. That is algorithmically perfect, but over-engineered [1]. I think it's much easier to have a default_package_install and a KDE_package_install and adjust it if the defaults changes, than to think about the correct workflow every time we execute the tests (I understand I'll be fired for saying this, but I tend to forget these things. I also want to make release validation more accessible for newcomers). [1] $ python -c 'import this' Well I see your point, but it kind of cuts both ways - Josef clearly got confused by a few cases where we overload test cases to test several different things, so you can argue that it's actually more 'accessible' when we try to stick to 'one test case tests one thing'. But your approach would achieve what we need to achieve indeed. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Partitioning criteria revision proposal
On Tue, 2012-10-16 at 17:55 -0700, Adam Williamson wrote: On Wed, 2012-10-10 at 22:31 -0700, Adam Williamson wrote: Hey, folks. So it became clear over the course of the last few blocker reviews that the new partitioning criteria need a bit of refinement. Here is my proposal for altering them. So...aside from the specific discussion of my proposals, I was thinking some more in general about the design of the partitioning criteria, and I'm starting to wonder if we're maybe getting too ambitious in terms of what we require at Beta, especially compared to previous releases. So if we go back again and look at how things were before, here is what we required: At Alpha, the offered autopart mechanisms except for 'shrink' had to work: this covered wiping entire disks and autoparting into the empty space, wiping only Linux partitions (preserving Windows ones) and autoparting into the empty space, and autoparting into existing empty space. It also covered LVM and non-LVM, and encrypted and non-encrypted, variations on autopart, as these were offered on the autopart screen. We did not require anything from custom partitioning. At Beta, we added a requirement that the installer be able to install to hardware and BIOS RAID arrays, and create and install to software RAID arrays (softRAID is a function of custom partitioning; this is the only thing we required to work in custom partitioning at Beta). At Final, we basically required any viable partitioning scheme to work (by implication and policy, custom partitioning issues were all considered Final blockers, aside from softRAID). So, we only required softRAID functionality from the custom partitioning bit at Beta; all other requirements for custom partitioning were Final. I am struggling to imagine the reasoning for requiring only md raid here. Now with F18 Alpha 'autopart' was very very basic so we kind of got the idea that we'd have to require more custom part functionality to work at Alpha and Beta, and we've been working on that basis so far. But taking a step back and looking at it, the 'guided partitioning' flow in F18 Beta is much more capable and nearly matches what autopart in F17 offered. Without going into custom partitioning, you can autopart into empty space, or wipe any combination of existing partitions if you do not have sufficient free space. You can also encrypt the installation, now. There's only really two things missing: a) you can't wipe or shrink partitions if you have sufficient free space, even if you want to (to provide *more* space for the install) - you have to use custom partitioning if you want to do this This is unfortunate. b) you can't do LVM without going into custom partitioning but that's *all*. Everything else you could do with autopart in F17, you can do with 'guided partitioning' in F18. So I'm not sure the approach we're currently working on, of requiring extensive functionality from the custom partitioning tool at Beta time, is necessarily warranted. We could still decide we want certain things to work in custom partitioning at Beta time, but we don't really have to just in order to maintain the standards from previous releases, it would really constitute *raising* our standards. So I'd be interested in general opinions about whether we should go down the path of requiring quite a bit of reliability from custom partitioning at Beta stage, or whether we should perhaps dial that down a bit, and only really require extensive functionality from custom partitioning at Final stage, as we did for F17 and earlier. I'd especially be interested in what the anaconda team thinks, so could you folks chip in? I'm inclined to say we should have some requirements for custom partitioning functionality in the beta. It just so happens that there isn't much custom storage functionality in the current anaconda that isn't expected to work at least reasonably well, so that makes it a bit easier this time around. Here's what I think makes some sense as beta criteria for custom storage: - create new devices - remove devices - assign mountpoints to existing filesystems on existing devices as appropriate (ie: not for the root filesystem) - reformat existing devices and assign mountpoints as appropriate - run autopart from within custom, results subject to disk layout This may be too broad. Perhaps we should define a set of common setups for mdraid, btrfs, and lvm to avoid committing to support for every imaginable permutation of each. This would apply to both handling of pre-existing setups and what the installer can create. Examples: mdraid: un-partitioned raid0, raid1, raid10 with partition members across two or more disks with encryption on top of the md layer lvm: un-partitioned non-mirrored, non-striped lvm with partition pvs and encryption on top of the lv layer btrfs: single, raid0, raid1 on across one or more partitions (two or
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On 10/25/2012 01:41 PM, Jóhann B. Guðmundsson wrote: On 10/25/2012 08:26 PM, Adam Williamson wrote: On this topic...Ric Wheeler came up with some fairly good arguments in favour of keeping the LVM default and proposed it on the anaconda list this morning (actually I think the post may not have been approved yet, but it'll show up soon). Since we're post-freeze now I summarized the debate into a bug report and nominated it for NTH: https://bugzilla.redhat.com/show_bug.cgi?id=870207 I think it's still true to say that our*original* reasons for defaulting to LVM don't really hold any more, but Ric made some pretty decent*current* arguments for keeping that default until we switch to btrfs-by-default. First of all this has been known this whole time Ric is not bringing anything new to the table and I nack to this proposal it's to dam late in the release cycle to change this now and if we change this it means we have to slip another week to properly test anaconda with lvm as default against the alpha and beta criteria I am under the impression that we've been testing with/without LVM anyway, both scenarios? In any case, it doesn't seem as earthshaking as other developments - it's just making the default be what it's been for some time, and given that there exists documentation for the lvm enabled case and not much otherwise it seems like a reasonable thing to do. I would almost make the case that disabling LVM by default - were it a feature - would require a lot of that backup documentation and info that isn't really there Can we please stop messing around with the installer! JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Partitioning criteria revision proposal
On Thu, 2012-10-25 at 18:22 -0500, David Lehman wrote: On Tue, 2012-10-16 at 17:55 -0700, Adam Williamson wrote: On Wed, 2012-10-10 at 22:31 -0700, Adam Williamson wrote: Hey, folks. So it became clear over the course of the last few blocker reviews that the new partitioning criteria need a bit of refinement. Here is my proposal for altering them. So...aside from the specific discussion of my proposals, I was thinking some more in general about the design of the partitioning criteria, and I'm starting to wonder if we're maybe getting too ambitious in terms of what we require at Beta, especially compared to previous releases. So if we go back again and look at how things were before, here is what we required: At Alpha, the offered autopart mechanisms except for 'shrink' had to work: this covered wiping entire disks and autoparting into the empty space, wiping only Linux partitions (preserving Windows ones) and autoparting into the empty space, and autoparting into existing empty space. It also covered LVM and non-LVM, and encrypted and non-encrypted, variations on autopart, as these were offered on the autopart screen. We did not require anything from custom partitioning. At Beta, we added a requirement that the installer be able to install to hardware and BIOS RAID arrays, and create and install to software RAID arrays (softRAID is a function of custom partitioning; this is the only thing we required to work in custom partitioning at Beta). At Final, we basically required any viable partitioning scheme to work (by implication and policy, custom partitioning issues were all considered Final blockers, aside from softRAID). So, we only required softRAID functionality from the custom partitioning bit at Beta; all other requirements for custom partitioning were Final. I am struggling to imagine the reasoning for requiring only md raid here. Well it wasn't quite drawn up that way. It was more 'oh, hey, RAID has to work at Beta'. So fwraid, HW raid and sw raid are all supposed to work at Beta...but the only one of those that actually relies on custom partitioning is sw raid. You can only create an sw raid layout through custom partitioning. But you configure fw raid and hw raid through your BIOS or RAID controller BIOS or whatever. You can install to fw raid or hw raid without entering custom partitioning, both in oldUI and newUI. So _in practice_, we wound up in this odd situation where we required precisely one thing from custom partitioning at Beta - SW raid. So I'd be interested in general opinions about whether we should go down the path of requiring quite a bit of reliability from custom partitioning at Beta stage, or whether we should perhaps dial that down a bit, and only really require extensive functionality from custom partitioning at Final stage, as we did for F17 and earlier. I'd especially be interested in what the anaconda team thinks, so could you folks chip in? I'm inclined to say we should have some requirements for custom partitioning functionality in the beta. It just so happens that there isn't much custom storage functionality in the current anaconda that isn't expected to work at least reasonably well, so that makes it a bit easier this time around. Thanks for this feedback. We can certainly go down the road of requiring functionality from custom part at Beta. The other point to ponder might be that we could require things to be _present and testable_ in custom partitioning, without necessarily requiring them to work 100%. Do you think that might be a useful way to look at things? Here's what I think makes some sense as beta criteria for custom storage: - create new devices - remove devices - assign mountpoints to existing filesystems on existing devices as appropriate (ie: not for the root filesystem) - reformat existing devices and assign mountpoints as appropriate - run autopart from within custom, results subject to disk layout This may be too broad. Perhaps we should define a set of common setups for mdraid, btrfs, and lvm to avoid committing to support for every imaginable permutation of each. This would apply to both handling of pre-existing setups and what the installer can create. Examples: mdraid: un-partitioned raid0, raid1, raid10 with partition members across two or more disks with encryption on top of the md layer lvm: un-partitioned non-mirrored, non-striped lvm with partition pvs and encryption on top of the lv layer btrfs: single, raid0, raid1 on across one or more partitions (two or more for raid0, raid1) with encryption underneath the btrfs layer Some things I think should not be required for beta: - broken/incomplete anything: lvm, md, fwraid, whatever I'll stop there for the time being. Thanks. This looks broadly like the direction we were moving in with this thread _before_ I decided to
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Thu, 2012-10-25 at 16:24 -0700, Robyn Bergeron wrote: First of all this has been known this whole time Ric is not bringing anything new to the table and I nack to this proposal it's to dam late in the release cycle to change this now and if we change this it means we have to slip another week to properly test anaconda with lvm as default against the alpha and beta criteria I am under the impression that we've been testing with/without LVM anyway, both scenarios? Sort of yes and sort of no. People have been testing LVM installs for sure; we've had bugs filed and fixed on it. But we haven't been testing LVM autopart in F18 because newUI doesn't actually let you; it doesn't let you pick 'LVM autopart' or 'non-LVM autopart' as oldUI did. If you do autopart you're stuck with raw ext4. As I said, though, it's the same code we used for F17 and before that all the way back to the storage rewrite, it was never taken out, so it seems unlikely it'd suddenly be badly broken. And indeed I did a couple of tests with the updates.img I put in the bug report and it seems to work fine. In any case, it doesn't seem as earthshaking as other developments - it's just making the default be what it's been for some time, and given that there exists documentation for the lvm enabled case and not much otherwise it seems like a reasonable thing to do. I would almost make the case that disabling LVM by default - were it a feature - would require a lot of that backup documentation and info that isn't really there Yeah, it's kind of a messy situation and you can argue it both ways :( On the one hand it's absolutely true we shouldn't be screwing about with the code at this point for Beta unless we really need to. On the other hand, all you say about the 'change to raw ext4 by default' really being the big change and it not having been properly proposed, discussed and documented is true; and we can't really 'just push this out to the next release' because once we do a stable release with raw ext4 by default, the whole situation has been changed, and now going back to LVM by default is the 'big change'. So it's really a bit of a mess. :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On 10/25/2012 11:24 PM, Robyn Bergeron wrote: I am under the impression that we've been testing with/without LVM anyway, both scenarios? The installer has been defaulting to EXT4 up to this point there is no option to hash or unhash lvm as you could do in the oldUI in the newUI and custom partitioning has been more or less broken this whole time. The oldUI rendered ext4 vs lvm argument moot because it was equally easy/hard to disable/enable it for both parties. In any case, it doesn't seem as earthshaking as other developments - it's just making the default be what it's been for some time, and given that there exists documentation for the lvm enabled case and not much otherwise it seems like a reasonable thing to do. I would almost make the case that disabling LVM by default - were it a feature - would require a lot of that backup documentation and info that isn't really there I think you should focus on getting the feature process to actually define what it considers as an actual feature before you propose removing lvm as feature . From that same argumental stand point removing the functionality of disabling lvm as easily as it was in F17 should have been mentioned on the newUI feature page. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Partitioning criteria revision proposal
On Thu, 2012-10-25 at 16:47 -0700, Adam Williamson wrote: On Thu, 2012-10-25 at 18:22 -0500, David Lehman wrote: On Tue, 2012-10-16 at 17:55 -0700, Adam Williamson wrote: On Wed, 2012-10-10 at 22:31 -0700, Adam Williamson wrote: Hey, folks. So it became clear over the course of the last few blocker reviews that the new partitioning criteria need a bit of refinement. Here is my proposal for altering them. So...aside from the specific discussion of my proposals, I was thinking some more in general about the design of the partitioning criteria, and I'm starting to wonder if we're maybe getting too ambitious in terms of what we require at Beta, especially compared to previous releases. So if we go back again and look at how things were before, here is what we required: At Alpha, the offered autopart mechanisms except for 'shrink' had to work: this covered wiping entire disks and autoparting into the empty space, wiping only Linux partitions (preserving Windows ones) and autoparting into the empty space, and autoparting into existing empty space. It also covered LVM and non-LVM, and encrypted and non-encrypted, variations on autopart, as these were offered on the autopart screen. We did not require anything from custom partitioning. At Beta, we added a requirement that the installer be able to install to hardware and BIOS RAID arrays, and create and install to software RAID arrays (softRAID is a function of custom partitioning; this is the only thing we required to work in custom partitioning at Beta). At Final, we basically required any viable partitioning scheme to work (by implication and policy, custom partitioning issues were all considered Final blockers, aside from softRAID). So, we only required softRAID functionality from the custom partitioning bit at Beta; all other requirements for custom partitioning were Final. I am struggling to imagine the reasoning for requiring only md raid here. Well it wasn't quite drawn up that way. It was more 'oh, hey, RAID has to work at Beta'. So fwraid, HW raid and sw raid are all supposed to work at Beta...but the only one of those that actually relies on custom partitioning is sw raid. You can only create an sw raid layout through custom partitioning. But you configure fw raid and hw raid through your BIOS or RAID controller BIOS or whatever. You can install to fw raid or hw raid without entering custom partitioning, both in oldUI and newUI. So _in practice_, we wound up in this odd situation where we required precisely one thing from custom partitioning at Beta - SW raid. HW and FW RAID make fine sense to me. SW RAID shouldn't be lumped with them for this purpose. So I'd be interested in general opinions about whether we should go down the path of requiring quite a bit of reliability from custom partitioning at Beta stage, or whether we should perhaps dial that down a bit, and only really require extensive functionality from custom partitioning at Final stage, as we did for F17 and earlier. I'd especially be interested in what the anaconda team thinks, so could you folks chip in? I'm inclined to say we should have some requirements for custom partitioning functionality in the beta. It just so happens that there isn't much custom storage functionality in the current anaconda that isn't expected to work at least reasonably well, so that makes it a bit easier this time around. Thanks for this feedback. We can certainly go down the road of requiring functionality from custom part at Beta. The other point to ponder might be that we could require things to be _present and testable_ in custom partitioning, without necessarily requiring them to work 100%. Do you think that might be a useful way to look at things? That sounds appropriate for beta. Here's what I think makes some sense as beta criteria for custom storage: - create new devices - remove devices - assign mountpoints to existing filesystems on existing devices as appropriate (ie: not for the root filesystem) - reformat existing devices and assign mountpoints as appropriate - run autopart from within custom, results subject to disk layout This may be too broad. Perhaps we should define a set of common setups for mdraid, btrfs, and lvm to avoid committing to support for every imaginable permutation of each. This would apply to both handling of pre-existing setups and what the installer can create. Examples: mdraid: un-partitioned raid0, raid1, raid10 with partition members across two or more disks with encryption on top of the md layer lvm: un-partitioned non-mirrored, non-striped lvm with partition pvs and encryption on top of the lv layer btrfs: single, raid0, raid1 on across one or more partitions (two or more for raid0, raid1) with encryption underneath
Re: Partitioning criteria revision proposal
On Thu, 2012-10-25 at 19:14 -0500, David Lehman wrote: Well it wasn't quite drawn up that way. It was more 'oh, hey, RAID has to work at Beta'. So fwraid, HW raid and sw raid are all supposed to work at Beta...but the only one of those that actually relies on custom partitioning is sw raid. You can only create an sw raid layout through custom partitioning. But you configure fw raid and hw raid through your BIOS or RAID controller BIOS or whatever. You can install to fw raid or hw raid without entering custom partitioning, both in oldUI and newUI. So _in practice_, we wound up in this odd situation where we required precisely one thing from custom partitioning at Beta - SW raid. HW and FW RAID make fine sense to me. SW RAID shouldn't be lumped with them for this purpose. That seems straightforward and sensible. Not sure why we didn't look at it that way before. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Oct 25, 2012, at 4:32 PM, Kamil Paral kpa...@redhat.com wrote: The default was flipped to raw partitions in early builds of F18 Anaconda, and that was unfortunate, because it lacked a proper discussion and announcement (it was quite a surprise for QA). It is still (barely) time to flip the default back, to what it always was. But there's no way enough time to _start_ the discussion now. It would consume weeks and by that time Beta should be out. I brought this up just over two months ago on both the anaconda and test lists and there was not all that much discussion then. So I don't see why it's such a big deal now. https://www.redhat.com/archives/anaconda-devel-list/2012-August/msg00116.html From an autopartition point of view, putting in code that's just going to be removed again come btrfs time doesn't make sense me. The autopartitioning for btrfs obviates lvm and md raid (except where md is needed to support a prior full disk IMSM RAID setup). I'm not convinced it makes sense to wedge LVM for autopartitioning when it's not needed in the next release. One release without it is not such a big deal, really. I think there are some LVM haters in the community who finally saw a chance to cleanse Fedora of this evil, and now will be very angry if someone wants to revert it. They might be wrong, they might be right. But I don't think this is the discussion we want to have now. That discussion should target Fedora 19. Now we should keep the defaults from previous Fedora versions. I like LVM. But I don't care about LVM as default for autopart one way or another. We're just post beta freeze, and this is coming up for serious conversation now? I think it needs to be let go. I think Jesse Keating's reply is a sufficiently good and timely explanation for having set expectations well prior to now. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Thu, 2012-10-25 at 19:23 -0600, Chris Murphy wrote: On Oct 25, 2012, at 4:32 PM, Kamil Paral kpa...@redhat.com wrote: The default was flipped to raw partitions in early builds of F18 Anaconda, and that was unfortunate, because it lacked a proper discussion and announcement (it was quite a surprise for QA). It is still (barely) time to flip the default back, to what it always was. But there's no way enough time to _start_ the discussion now. It would consume weeks and by that time Beta should be out. I brought this up just over two months ago on both the anaconda and test lists and there was not all that much discussion then. So I don't see why it's such a big deal now. https://www.redhat.com/archives/anaconda-devel-list/2012-August/msg00116.html From an autopartition point of view, putting in code that's just going to be removed again come btrfs time doesn't make sense me. The autopartitioning for btrfs obviates lvm and md raid (except where md is needed to support a prior full disk IMSM RAID setup). I'm not convinced it makes sense to wedge LVM for autopartitioning when it's not needed in the next release. One release without it is not such a big deal, really. Nothing gets 'wedged in' anywhere, there is no code to 'put in' (nor will any of the code that exists get 'removed' even when we default to btrfs, I don't think). I already posted the patch: it's two lines. All the code for LVM autopart already exists and is the same code that has existed for years. The patch simply changes the way the autopart code is called from 'please don't use LVM' to 'please use LVM'. It is two lines. http://fpaste.org/w1vE/ I like LVM. But I don't care about LVM as default for autopart one way or another. We're just post beta freeze, and this is coming up for serious conversation now? I think it needs to be let go. I think Jesse Keating's reply is a sufficiently good and timely explanation for having set expectations well prior to now. The tricky thing is that the argument kind of cuts both ways: the thing that's the big change here was changing from LVM-by-default to raw-ext4-by-default, and that should have been clearly publicised and discussed. The fact that there are people just now finding out that it happened and being unhappy about it rather indicates that the planned change _wasn't_ properly communicated. I don't really see any great options here, unfortunately. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Full, current F18 tree to rsync?
Hi all, I regularly pull down the F18 tree from the rsync equivalent of: http://download.fedoraproject.org/pub/fedora/linux/development/18/x86_64/os/ Up until recently this was a full install tree, including the images/ subdir. This makes it easy to use the tree for PXE (like using cobbler import) or URL installs in virt-manager. Now, though, current trees only have Packages/ repodata/ and drpms/ subdirs. (occasionally accessing that URL dumps me at a mirror with a full install tree, but it was last synced on October 16 so obviously not the current state of things) Is the change intentional? If so, why? And is there some place to still rsync a full install tree? Thanks, Cole -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Oct 25, 2012, at 7:38 PM, Adam Williamson awill...@redhat.com wrote: Nothing gets 'wedged in' anywhere, there is no code to 'put in' (nor will any of the code that exists get 'removed' even when we default to btrfs, I don't think). I already posted the patch: it's two lines. All the code for LVM autopart already exists and is the same code that has existed for years. The patch simply changes the way the autopart code is called from 'please don't use LVM' to 'please use LVM'. It is two lines. http://fpaste.org/w1vE/ So the loose proposal here is to add this patch just for F18, and then undo it for F19? I like LVM. But I don't care about LVM as default for autopart one way or another. We're just post beta freeze, and this is coming up for serious conversation now? I think it needs to be let go. I think Jesse Keating's reply is a sufficiently good and timely explanation for having set expectations well prior to now. The tricky thing is that the argument kind of cuts both ways: the thing that's the big change here was changing from LVM-by-default to raw-ext4-by-default, and that should have been clearly publicised and discussed. The fact that there are people just now finding out that it happened and being unhappy about it rather indicates that the planned change _wasn't_ properly communicated. There are other explanations than it being improperly communicated. We've had this same autopartitioning behavior for how many weeks? It is only affecting autopartitioning. I'm not realy clear what the downside even is, which is why I didn't have a fit over this two months ago. It's just a default for most people who either don't care, or don't understand the alternatives. Everyone else will use Manual Partitioning. I think the public beta will make this more clear, however, how many people really expect LVM autopartitioning. But I really don't think it's that big of a deal. It's a default. Don't like the default? Change it. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Importance of LVM (was Re: Partitioning criteria revision proposal)
On Thu, 2012-10-25 at 20:14 -0600, Chris Murphy wrote: On Oct 25, 2012, at 7:38 PM, Adam Williamson awill...@redhat.com wrote: Nothing gets 'wedged in' anywhere, there is no code to 'put in' (nor will any of the code that exists get 'removed' even when we default to btrfs, I don't think). I already posted the patch: it's two lines. All the code for LVM autopart already exists and is the same code that has existed for years. The patch simply changes the way the autopart code is called from 'please don't use LVM' to 'please use LVM'. It is two lines. http://fpaste.org/w1vE/ So the loose proposal here is to add this patch just for F18, and then undo it for F19? The general understanding among Storage People is that we're aiming to go to btrfs by default for F19. Finally. That's one of the arguments against changing the default _now_, for one release (or possibly two), only to change it again shortly. I like LVM. But I don't care about LVM as default for autopart one way or another. We're just post beta freeze, and this is coming up for serious conversation now? I think it needs to be let go. I think Jesse Keating's reply is a sufficiently good and timely explanation for having set expectations well prior to now. The tricky thing is that the argument kind of cuts both ways: the thing that's the big change here was changing from LVM-by-default to raw-ext4-by-default, and that should have been clearly publicised and discussed. The fact that there are people just now finding out that it happened and being unhappy about it rather indicates that the planned change _wasn't_ properly communicated. There are other explanations than it being improperly communicated. We've had this same autopartitioning behavior for how many weeks? It is only affecting autopartitioning. I'm not realy clear what the downside even is, which is why I didn't have a fit over this two months ago. It's just a default for most people who either don't care, or don't understand the alternatives. Everyone else will use Manual Partitioning. I think the public beta will make this more clear, however, how many people really expect LVM autopartitioning. But I really don't think it's that big of a deal. It's a default. Don't like the default? Change it. You're probably right if everyone takes a step back that it's not a _huge_ deal. It's slightly more difficult to change in newUI than it was in oldUI, as things stand: there's no drop-down/checkbox 'change the autopart algorithm' thing as there was in oldUI. You have to go into custom partitioning and either create an LVM-based layout from scratch, or hit 'create partitions automatically' and then change their type to LVM. But it's not a huge problem, no, and you'd think people who are LVM-savvy could handle it. If anything the debate is about the experience of those who don't really care at install time, but theoretically might later. Some worry about the 'difficulty' of understanding LVM for these non-caring users. Some suggest that maybe these non-caring users might hit a problem they can solve with the help of LVM, like filling up their / partitions. As always with Fedora debates it's a bit fuzzy because we don't have any good data. Plus ca change. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
More experiences with F18
While waiting for a more functional Anaconda I have been running 64 bit F18 with yum updates. The Noveau driver still crashes. Fortunately Nvidia still installs. I am able to run SCO Openserver 5.0.7 under the virtual machine. Select i686, pcnet, and 4.4bsd. Audacity puts its data in the root segment by default. This eventually overflows the small root FS generated by Anaconda. -- Chuck Forsberg WA7KGX N2469R c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc The High Reliability Software 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion proposal: security
On Thu, 2012-10-25 at 21:57 -0600, Vincent Danen wrote: So whether that's done earlier in the cycle or later, it doesn't matter. Earlier on gives it more time to get fixed. The end result is the same: it has to be fixed. I don't see why making it a blocker in the alpha stage vs making it a blocker in the pre-GA stage makes a difference other than you're giving a developer less time to fix something that absolutely needs to be fixed. Well...not really. If a bug is an Alpha blocker it has to be fixed by Alpha. If a bug is a Final blocker it has to be fixed by Final. So if you start at a theoretical point one week before the Alpha gets signed off, you have one week to fix the bug if it's an Alpha blocker. You have, oh, about three months and one week to fix the bug if it's a Final blocker. I still don't understand the RHEL process entirely but it seems to involve considering blocker status more or less independent of milestone, so you might put 'blocker+' on a bug and have the target release (or whatever it's called) as 'alpha', but that doesn't really mean it's an Alpha blocker - maybe one week before the Alpha goes out, half the bugs get the target release changed to 'beta' and the Alpha goes out anyway. Again, we don't do that for Fedora. We have three blocker lists per release; Alpha blockers, Beta blockers, Final blockers. We don't take a look at the Alpha blocker list one week before Alpha release and go 'well hmm, that looks a bit long, maybe we should bump some of them to Beta'. So we have weaker criteria for Alpha and Beta because, well, Alpha and Beta release don't have to be as stable as Final releases. Given the tight schedules of Fedora we can't just take the Final standards and apply them to Alpha. We just don't have time. The Alpha criteria are very minimal and define only what absolutely has to be done for an Alpha to go out. If you look at the criteria, we can release Alphas with gigantic flaws in them. If you think it wouldn't realistic to say 'we'll take any persistent moderate flaw as a blocker' that's valuable feedback...then the question becomes do we only bother about important+ bugs, do we try and come up with some kind of solid definition for what 'moderate' bugs we'll consider blockers and which ones we won't, or do we just say 'we'll evaluate 'moderate' bugs on a case-by-case basis'. As stated above, I think you can break down the moderate flaws into types. If you do that, you should rarely have to look at exceptions, I think. I mean, if there is a really bad local flaw that wouldn't fit into the category of a what is defined as a moderate release blocker, but it's really that bad, then chances are it's not classified correctly and may actually be an important flaw. CVSSv2 can help here. So can the SRT, or the Fedora Security Response Team (many of whom are SRT too). A simple what do you think sent to either team will get someone with experience to evaluate the flaw. That sounds like a good approach, thanks. Yup, that's useful feedback indeed, and thanks. I think a policy would be extremely helpful as it takes the guess-work out of things. Definitely, that's exactly the idea. I'm also appreciative that you reached out for feedback because there is a lot of assistance that we (SRT) would _like_ to give to Fedora, and we're doing as much as we can, but this kind of outreach is really quite nice and we're more than happy to lend any kind of assistance that we can. Conversations for another day. I would be happy with this as a first start, honestly. A cornerstone to start building a more comprehensive policy on is nothing to be taken lightly. =) Thanks for bringing this up, Adam. Thanks a lot for the input! You're very welcome. I hope it's helpful! Please do let me (or the SRT in general) know if you need any further help, even if helping to define what a moderate release blocker might look like. Again, we are more than happy to help. I'll look at the points you and other responders raised and try to come up with tweaked criteria tomorrow. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
