Re: Criterion revision proposal: KDE default applications
Kamil Paral wrote on Fri, 20 Dec 2013 05:00:24 -0500 >The bandwidth problem should be solved by a simple program: >a. you run it on computer A (lacking bandwidth) - it gathers the list of >installed packages and exports a file >b. then you run it on computer B (good bandwidth) - feed it the file and tell >what programs you want to download, it fetches all the RPMs and makes a >repository >c. then you bring the files back to computer A, and either using that >file again or GNOME Software it mounts the repository and allows you to >install the programs available Simple program, yes, but operationally complicated. Hope you get all the programs you want the first time, else repeat until you get it right. Were I to perform Fedora installations without Internet connectivity, I should be tempted instead to copy the entire Fedora repositories to a portable disk. That way, anything I did not know I wanted would be right at hand. Job done in one visit. Other people could use my disk to install whatever package sets they wanted. With a world of use cases, no scheme will be best for everyone. I like your idea of a live system with optional repository, but where is Anaconda in this picture? Must everyone who wants a configuration not possible with live install use netinstall? Will F21 be the first Fedora release with three versions (workstation, server, cloud)? Will each project make independent decisions about distribution strategy? >Since there's nothing else than a yum repo, it's trivial to check for >correctness. I beg to differ. Instead of a "frozen" image, with direct management to limit changes, you suggest a plethora of collections that are likely to span a larger part of Fedora's total package set. If you mean to prepare specialized repositories only from packages in the DVD collection, there is no advantage: just keep the DVD. I feel there are many chapters yet to be written in the story of Fedora's distribution mechanism. Partition of the problem may be appropriate. Instead of a search for a globl distribution scheme, direct each project and spin to make choices appropriate for their target audience. The cloud project will see network installation the only thing they want, while SoaS delivers a complete system image with no need for a network. Interesting times ahead. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
> Given that, I propose re-wording as follows: > > "All applications that can be launched using the standard graphical > mechanism of a release-blocking live image after an installation of that > image must start successfully and withstand a basic functionality test." I have read the whole thread, multiple things are discussed here. My take on this: 1. I agree with the proposed criterion. Our team is inherently best-effort driven and we need to very carefully and cleverly prioritize. This helps us guide us in the right direction. 2. Some people claim that DVD and Live install result should be the same. Adam's proposal doesn't contradict that, just gives us a working solution before such state is reached. Once relevant people implement the changes in DVD or Lives, the "live image" part of the proposal becomes redundant and can be removed. 3. As long as DVD and Live install differ, I agree that the Live package set contains the most important packages from the Spin's view and those should get the most testing. Our website heavily promotes Live installs, and most of the general users do Live installs, because they use our website (if you read this, you're not a general user). The other packages, only available on DVD, are clearly not that important. That doesn't mean we can't accept a proposed blocker in such a package, if it is especially important (eat-your-computer type), just the "basic functionality" criterion won't apply automatically to them. 4. As for DVD existence - yes, I also consider it outdated. It tries to solve bandwidth problems in a wrong way. I imagine a world with Lives for general audience, netinst for expert audience, and multi-Lives for marketing purposes. The bandwidth problem should be solved by a simple program: a. you run it on computer A (lacking bandwidth) - it gathers the list of installed packages and exports a file b. then you run it on computer B (good bandwidth) - feed it the file and tell what programs you want to download, it fetches all the RPMs and makes a repository c. then you bring the files back to computer A, and either using that file again or GNOME Software it mounts the repository and allows you to install the programs available The whole program is trivial (even its GUI), and it solves everything DVD attempts to solve. You can use it any time, not just at the release date (it downloads fresh versions of programs, DVD only contains stale ones). With this approach, we can also make a special-purpose media for special occasions - want to ship apps for kids in Africa? Just download the RPMs based on the package set of a default installation, copy/burn the repo to the media and ship it together with Lives. Since there's nothing else than a yum repo, it's trivial to check for correctness. No QA needed. We can make a different set of this extra offline-access media for Africa kids, for Graphics Designers conference, for Gamers festival, for Scientific classes in universities etc. Do you see the large possibilities that generic DVD can never help with? And hey, we can even put the Live installer and this additional repo to the same medium as a second partition, no need to have two media. So you stick it in, boot Live and install, and then you reboot to a working system, stick it in and have additional software available. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
More on storage validation strategy (was: Re: Criterion revision proposal: KDE default applications)
On Tue, 2013-12-17 at 09:45 -0700, Chris Murphy wrote: > On Dec 14, 2013, at 12:25 PM, Adam Williamson wrote: > > > > I really would like to see other people's proposals in this area. I'm > > not at all convinced I'm going to be the person who comes up with the > > best idea. I'd love to know what cmurf would suggest as an overall > > approach to designing a set of Final release criteria or a storage > > validation test plan, for instance. > > What do you think of moving any blocking storage related criteria and > tests, from final to beta or even alpha? Why not move as much > potential for blockers to alpha and beta releases as possible? > > An example of this is moving resize test and criterion to beta (or > split between alpha and beta if that's sensible and helpful). If > resize were busted, do we really only want to find out and start > dealing with it, and maybe slipping on it, during final? Seems risky, > especially if a fix depends on upstream developers. Or public beta > eats OS X or Windows for lunch. Personally, no, I don't think that's correct. In fact we just got done doing the opposite change (after F18, we weakened the Alpha storage criteria quite a lot). My take is this: the criteria define what needs to be working for us to release. They do not define what we ought to be testing at each milestone. We ought to be testing everything at each milestone, ideally. If that's not possible we need to test as much as we can. I'm not a huge fan of the Release Level column in the matrices, because it kinda gives the wrong impression. Even if a given test would only block Final release if it failed, not Alpha or Beta, *that doesn't mean we should only run it at Final*. We should run it at Alpha and Beta too, so we know if it's broken. I'm as guilty of taking the shortcut and punting on doing early tests as anyone. We're all human. But conceptually, the questions of 'what needs testing when?' and 'what do we block the release on?' are separate questions, and it is incorrect to make modifications to the release criteria simply to 'force' us to test stuff earlier. The correct question to be answering when deciding "what should be in the Alpha release criteria?" is, simply, "what needs to be working for us to ship a product labelled Alpha?" It's that simple. > Since alpha and beta blocking criteria are still in effect post-beta, > there will still be storage related blocking bugs after beta release. > But there wouldn't be new blockers based on additional criteria. Just to reiterate the above, *that shouldn't be happening now anyway* (except when the code actually breaks between Beta and Final, which does happen). We should be doing the testing by Beta and identifying all the Final blockers that exist by Beta. This is the goal I'm trying to work towards with all the revisions I'm proposing and thinking about, insofar as that's plausible with fedora.next hanging over us. We should be able to run our entire set of validation tests at Alpha and Beta, we should not be staging the test workload. > Rather than increasing the quality of beta, the main idea is to > increase the predictability of final and reduce risk of regressions > and final release slip. I think this is a great goal indeed. > I think guided partitioning should be fairly rock solid, and even > though it's the "simple" path, it's still a beast of a matrix. Yup. That's definitely one of the problems. > I mentioned this in a different thread, but I think either LVM or LVM > Thin Provisioning needs to be demoted. We don't need two LVM options > in Guided. And if we can't get buy off on that, then we'll have to > just eat that extra testing, because I think Guided shouldn't get > people into trouble. I broadly agree with this. If we were designing to the test cases, I'd say we should just throw that damn dropdown out entirely. You want something other than our default filesystem (whatever it is), you go to custom partitioning. But the best design for testers is not necessary the best design for users :) It's possibly worth considering, though. As I mentioned, oldUI only let you pick LVM or ext4. newUI added btrfs, with the 'everything's going btrfs!' plan in mind, I think. And F20 added LVM thinp. So now we have 2x what oldUI had. (And actually, I think the 'don't use LVM' checkbox was only added to oldUI in like F15 or something). We did have a kind of clear policy with oldUI, which is that we tested its version of 'guided' partitioning quite extensively, and custom partitioning got a lot less in terms of testing and criteria guarantees. We've been pushing that boat out since F18; maybe we need to pull it back in again. newUI guided does, I think, provide just about all the same possibilities oldUI non-custom did, with a slightly different approach. I think, whatever the details we come up with, the broad direction "emphasize testing of guided, de-emphasize testing of custom" - along with the improvements to the guided UI that M
Re: Criterion revision proposal: KDE default applications
On Tue, 2013-12-17 at 09:45 -0700, Chris Murphy wrote: > On Dec 14, 2013, at 12:25 PM, Adam Williamson wrote: > > > > I really would like to see other people's proposals in this area. I'm > > not at all convinced I'm going to be the person who comes up with the > > best idea. I'd love to know what cmurf would suggest as an overall > > approach to designing a set of Final release criteria or a storage > > validation test plan, for instance. > > What do you think of moving any blocking storage related criteria and tests, > from final to beta or even alpha? Why not move as much potential for blockers > to alpha and beta releases as possible? > > An example of this is moving resize test and criterion to beta (or split > between alpha and beta if that's sensible and helpful). If resize were > busted, do we really only want to find out and start dealing with it, and > maybe slipping on it, during final? Seems risky, especially if a fix depends > on upstream developers. Or public beta eats OS X or Windows for lunch. > > Since alpha and beta blocking criteria are still in effect post-beta, there > will still be storage related blocking bugs after beta release. But there > wouldn't be new blockers based on additional criteria. Rather than increasing > the quality of beta, the main idea is to increase the predictability of final > and reduce risk of regressions and final release slip. > > I think guided partitioning should be fairly rock solid, and even though it's > the "simple" path, it's still a beast of a matrix. I mentioned this in a > different thread, but I think either LVM or LVM Thin Provisioning needs to be > demoted. We don't need two LVM options in Guided. And if we can't get buy off > on that, then we'll have to just eat that extra testing, because I think > Guided shouldn't get people into trouble. > > Custom partitioning needs to be triaged for certain use cases we really want > to work, and make those blocking if they fail. It may not be the same list > for i386, x86_64/EFI, and ARM. e.g. we supposedly block on raid5 for x86_64, > but does that make sense for ARM? Other combinations, even if there's a > crash, would be non-blocking bugs, and only the subjective FE determination > applies. > > Obviously the data corruption proscription is still in place, so crashes that > lead to mangled partition tables or previously working file systems, > presumably would block. However, I wonder if that criterion should be split > in two: clearly not OK block worthy cases probably ought to be an alpha or > beta blocker at the latest; and those that are suitable for FE or merely > being documented could be permitted post-beta since they're unlikely to block. > > > > Chris Murphy +1. Move as much as makes sense in the storage testing to as early as possible. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Dec 14, 2013, at 12:25 PM, Adam Williamson wrote: > > I really would like to see other people's proposals in this area. I'm > not at all convinced I'm going to be the person who comes up with the > best idea. I'd love to know what cmurf would suggest as an overall > approach to designing a set of Final release criteria or a storage > validation test plan, for instance. What do you think of moving any blocking storage related criteria and tests, from final to beta or even alpha? Why not move as much potential for blockers to alpha and beta releases as possible? An example of this is moving resize test and criterion to beta (or split between alpha and beta if that's sensible and helpful). If resize were busted, do we really only want to find out and start dealing with it, and maybe slipping on it, during final? Seems risky, especially if a fix depends on upstream developers. Or public beta eats OS X or Windows for lunch. Since alpha and beta blocking criteria are still in effect post-beta, there will still be storage related blocking bugs after beta release. But there wouldn't be new blockers based on additional criteria. Rather than increasing the quality of beta, the main idea is to increase the predictability of final and reduce risk of regressions and final release slip. I think guided partitioning should be fairly rock solid, and even though it's the "simple" path, it's still a beast of a matrix. I mentioned this in a different thread, but I think either LVM or LVM Thin Provisioning needs to be demoted. We don't need two LVM options in Guided. And if we can't get buy off on that, then we'll have to just eat that extra testing, because I think Guided shouldn't get people into trouble. Custom partitioning needs to be triaged for certain use cases we really want to work, and make those blocking if they fail. It may not be the same list for i386, x86_64/EFI, and ARM. e.g. we supposedly block on raid5 for x86_64, but does that make sense for ARM? Other combinations, even if there's a crash, would be non-blocking bugs, and only the subjective FE determination applies. Obviously the data corruption proscription is still in place, so crashes that lead to mangled partition tables or previously working file systems, presumably would block. However, I wonder if that criterion should be split in two: clearly not OK block worthy cases probably ought to be an alpha or beta blocker at the latest; and those that are suitable for FE or merely being documented could be permitted post-beta since they're unlikely to block. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
>With five Test Managers, become a Test Executive... Sorry, Adam, just an attempt to give you opportunity to smile. I am serious about the scalability issue, however. As you indicated, the typical FOSS activity does not map readily into a classic business hierarchical organization chart. I do not want that. It would likely be difficult, unproductive, and even incite antagonism. This does not mean all strategies will fail. I do not know any sure-fire way to multiply the effectiveness of QA, but your efforts to document what QA can do and what others might do seem headed in a useful direction. Test automation is useful, especially if developers can be engaged in its creation. Abrt and other infrastructure is productive, and can be improved. Documentation - how to test, how to collect and report information about errors - is useful, especially when new testers are sought. Bugzilla is not all that easy or intuitive to use. Some sort of coverage map might help: what pieces are people currently testing or planning to test; what parts have no people active. All depends on cost/benefit estimation. Direct implementation is costly; leverage from work done by others may be key. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On 15 December 2013 03:27, Richard Ryniker wrote: > > It is very crude, but I looked at how many models of USB flash drive > Amazon sells directly and see: > > 512MB & Under 4 > 1GB39 > 2GB 176 > 4GB 378 > 8GB 518 > 16GBB 407 > 32GB & Up 465 > > Two thirds are models with 8GB or larger capacity. That does not mean > this many flash drives sold have that capacity, but such capacity is > readily available. There still are many machines that do not boot > directly from USB, but that is a condition for which GRUB and friends > are made. > Cautionary note (and sorry for muddying waters further, already a lot said in this discussion so trying to keep out of it): not only does this not (as you say) reflect the number of drives being sold, but it also doesn't reflect the drives in existence. The larger drives dominate that list because people aren't making the smaller ones anymore, but I've got 2 and 4GB drives I still use. For burning DVDs it doesn't matter so much, they're relatively cheap per unit, but for a USB it's a bit of a stretch to expect people to buy new drives, especially if you're worried about things like accessibility in developing countries and environmental impact. (On the plus side, just got a 8GB for £10 retail - probably cheaper online, but needed it quickly - these are now getting so big that it's practical to use them for backup and temporary storage during a reinstall, rather than having to worry about upgrading or how you're going to backup and restore. Long run this is probably better than WORM.) -- imalone http://ibmalone.blogspot.co.uk -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Sun, 2013-12-15 at 17:47 +1300, Gavin Flower wrote: > I don't know... > > Possibly charge a lot of money, give out fancy certificates, and ensure > they have status and no real responsibilities! oh, I like it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On 15/12/13 17:41, Adam Williamson wrote: On Sat, 2013-12-14 at 22:27 -0500, Richard Ryniker wrote: Has Fedora QA discussed how much effort they should or can invest in organization and facilitation of others' test activities? Direct testing scales (approximately) linearly with number of people, but education, organization, and leadership has the potential to scale at greater multiples. |---| | Great opportunity! Become a Fedora test franchisee. We'll provide | | directions, training, and all the materials you need, so you too can | | participate in this fast-moving field. Gain experience, recruit | | others, become a Test Manager and train new Testers. With 10 or | | more Testers, select your own Test Managers (each of whom will direct | | at least five Testers) and advance to the Test Director level. With | | five Test Managers, become a Test Executive...| |---| It's a cute idea, but I'm firmly of the opinion that stuff like this just doesn't _work_ in a project like Fedora. It's a cliche that geeks and engineers aren't huge fans of 'bureaucracy' and 'management', and this is pure management - drawing up a nice little hierarchical org chart and giving people job titles. Does the Test Executive get a corner office and a nice chair? :) I kid, but you get the point. I don't know of a F/OSS project which has a strict pyramid structure and cutesy job titles like this, and that's for a reason: the whole "F/OSS is a meritocracy / F/OSS is a do-ocracy" thing has its own problem of bias and so on, but it is a _fairly_ accurate reflection of how F/OSS work actually happens in one respect: it's mostly the case that the work is done by the people who show up, and there usually isn't some kind of obvious hierarchy like you describe. I mean, we don't have Test Executives and Test Directors and Testers inside the QA group, so why would we expect it to work for other groups to do it? The general idea of trying to get other groups more involved in testing their own stuff is obviously a good one, but I don't think that's the right approach to achieve it :) I don't know... Possibly charge a lot of money, give out fancy certificates, and ensure they have status and no real responsibilities! Cheers, Gavin -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Sat, 2013-12-14 at 22:27 -0500, Richard Ryniker wrote: > Has Fedora QA discussed how much effort they should or can invest in > organization and facilitation of others' test activities? Direct > testing scales (approximately) linearly with number of people, but > education, organization, and leadership has the potential to scale at > greater multiples. > > |---| > | Great opportunity! Become a Fedora test franchisee. We'll provide | > | directions, training, and all the materials you need, so you too can | > | participate in this fast-moving field. Gain experience, recruit | > | others, become a Test Manager and train new Testers. With 10 or | > | more Testers, select your own Test Managers (each of whom will direct | > | at least five Testers) and advance to the Test Director level. With | > | five Test Managers, become a Test Executive...| > |---| It's a cute idea, but I'm firmly of the opinion that stuff like this just doesn't _work_ in a project like Fedora. It's a cliche that geeks and engineers aren't huge fans of 'bureaucracy' and 'management', and this is pure management - drawing up a nice little hierarchical org chart and giving people job titles. Does the Test Executive get a corner office and a nice chair? :) I kid, but you get the point. I don't know of a F/OSS project which has a strict pyramid structure and cutesy job titles like this, and that's for a reason: the whole "F/OSS is a meritocracy / F/OSS is a do-ocracy" thing has its own problem of bias and so on, but it is a _fairly_ accurate reflection of how F/OSS work actually happens in one respect: it's mostly the case that the work is done by the people who show up, and there usually isn't some kind of obvious hierarchy like you describe. I mean, we don't have Test Executives and Test Directors and Testers inside the QA group, so why would we expect it to work for other groups to do it? The general idea of trying to get other groups more involved in testing their own stuff is obviously a good one, but I don't think that's the right approach to achieve it :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Sat, 14 Dec 2013, at 11:25:40 -0800 Adam Williamson wrote: One thing they've floated as an idea is to have a separate 'installation environment' you could boot into from the live images - so you could either boot into 'try it out' live mode, or 'install it' installer mode, but not run the installer from within the live mode. That is pretty much what I had in mind. There would be no "live installer". The Fedora stand-alone installation medium would be large enough to have a live system that offered "try" mode, "install" mode (full anaconda, with local repository), and maybe "rescue" mode. The same system image would be used: options built into each choice would direct which mode to execute. I think Ubuntu (or one of its variants) uses a scheme like this, but I do not know if it copies the live image or offers multiple installation variations. It is very crude, but I looked at how many models of USB flash drive Amazon sells directly and see: 512MB & Under 4 1GB39 2GB 176 4GB 378 8GB 518 16GBB 407 32GB & Up 465 Two thirds are models with 8GB or larger capacity. That does not mean this many flash drives sold have that capacity, but such capacity is readily available. There still are many machines that do not boot directly from USB, but that is a condition for which GRUB and friends are made. I cannot quantify how much a single installer for Fedora saves over two (live and multiple-environment). If one installer is adequate, it still may not be worth the disruption caused when the other is dropped. The single installer choice could be made either way. The alternative is only a live installer, which becomes the starting point for subsequent installation by yum of the desired environment(s). if you're interested in making [a limited resource Fedora] happen... I think one of my problems is too much hardware, not too little. Somehow, I seem to have acquired the notion a new release of Fedora justifies a new machine on which to run it. I don't really see a lot of evidence that many other groups test their stuff at all in any particularly organized way There are many reasons this is so. One may be a perception there is a QA group that will do this, therefore little need exists to do first what will be done again. This is not the most important factor, I believe, but a consequence is the more QA does, the more this attitude grows. You become a victim of your own success. Greater clarity about what QA will not test may help. I'll note two design choices in storage which make this problem exponentially harder... Yes. Test the untestable. I do not think those choices are caprice; they allow users, most of whom are no more than casually familiar with Fedora installation, to find a more comfortable path through the installation process, one that permits minimal rework (avoids the "Something is wrong - start over" event) as understanding grows and bad choices are improved. Fedora testers, who usually have an abundance of installation experience, likely do not appreciate the value to less experienced users of this flexibility that makes tests so difficult. for upgrading, we only test upgrading a very clean installation of the previous release Upgrade is a can of worms. Yes, I too am beguiled by how much easier upgrade is than a new installation, and have often chosen upgrade, but something (many somethings!) sooner or later bite. There are just too many initial conditions, and too many distinct ways appropriate for different users to handle these conditions, to make possible an accurate understanding of what results from an upgrade. In lucid moments, I know upgrade should be exorcised, but it just is *so* convenient. Has Fedora QA discussed how much effort they should or can invest in organization and facilitation of others' test activities? Direct testing scales (approximately) linearly with number of people, but education, organization, and leadership has the potential to scale at greater multiples. |---| | Great opportunity! Become a Fedora test franchisee. We'll provide | | directions, training, and all the materials you need, so you too can | | participate in this fast-moving field. Gain experience, recruit | | others, become a Test Manager and train new Testers. With 10 or | | more Testers, select your own Test Managers (each of whom will direct | | at least five Testers) and advance to the Test Director level. With | | five Test Managers, become a Test Executive...| |---| -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On 12/14/2013 12:38 PM, T.C. Hollingsworth wrote: On Fri, Dec 13, 2013 at 3:54 AM, Gene Czarcinski wrote: Indeed! There are environments/situations where there is no network connectivity (at least to the Internet) and never will be. It is this type of situations that will require a DVD. I run Fedora on a system that exists in on the side of a mountain in the remote part of the Arizona desert that is lucky to even have electricity and running water. No Internet, except tethering on my smartphone in an area that doesn't even have 3G coverage. (Internet access would sort of defeat the usual purpose of me venturing out there, anyway. That machine wouldn't even exist period if it were not used by others; I'd just take my laptop out there or maybe not even that. ;-) Trying to run a `yum update` out there would probably take longer than I usually spend there, and I'm not particularly worried about security updates, since the only way that system could possibly be more airgapped would be for it to exist on Mars. :-p Anyway, the DVD is _completely_ useless for this system. Pretty much every use case I have for this system requires packages from a certain third-party repository we all know and love, and even if Fedora contained all the packages I needed for it, they all certainly wouldn't on the DVD. Also, I really don't care about 95% of the packages on the DVD; I certainly don't need six different desktops. ;-) So instead when I refresh it from time to time, I just anaconda install onto a USB stick, yum install everything I want to it, then take it out there and dd it to the hard disk, manually making grub happy if necessary. This also allows me to configure it the way I want before I leave, so when I get out there it only takes me a few minutes to get it completely updated. I guess I could craft a kickstart and use livecd-creator instead, but that seems like more hassle than it's worth. Plus I keep that USB stick around so I have something that matches that system exactly at home, so if I ever decide I want to install some more stuff on it I can be sure I download all the RPMs necessary for a complete transaction. (Supposedly there's some offline download/install support in PackageKit for that usecase too, but it doesn't seem to be documented very well. The only reason I even know it exists is because hughsie asked on his blog if he could kill it. ;-) So if we really care about this usecase, we need to rebirth revisor or something similar so people can actually make images for their disconnected systems that have the stuff they want on them easily, instead of a grab bag of packages most of which they have no use for. For bonus points, maybe flesh out the offline update support so there's a sane way to update/install stuff on them afterward. Keeping the DVD around "because offline systems" is really just ignoring these users' actual needs. It would be nice if some development effort were put to making this actually better, but it's really an edge case that can already be handled by other, less elegant solutions like mine, so I really don't blame developers for not bothering with it. The only other use case we really have for the install DVD is for handing out at conferences, etc., and I think the multi-live DVD is a much better fit for that personally. Look at http://wiki.sugarlabs.org/go/Build_Your_Own_Remix_with_Fedora Make an installable live CD/DVD .iso with cutomizations Another situation is where I am installing into a qemu-kvm virtual system. Yes, there will be Internet connectivity. Yes, it is nice to have everything updated on install. But, running with just the DVD image is a lot faster (takes much less wall-clock time). Nowadays we have nice qcow2 images for that use case. Much better than the DVD IMHO, especially since a `yum update` is the first thing I'd do regardless... -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Fri, Dec 13, 2013 at 3:54 AM, Gene Czarcinski wrote: > Indeed! There are environments/situations where there is no network > connectivity (at least to the Internet) and never will be. It is this type > of situations that will require a DVD. I run Fedora on a system that exists in on the side of a mountain in the remote part of the Arizona desert that is lucky to even have electricity and running water. No Internet, except tethering on my smartphone in an area that doesn't even have 3G coverage. (Internet access would sort of defeat the usual purpose of me venturing out there, anyway. That machine wouldn't even exist period if it were not used by others; I'd just take my laptop out there or maybe not even that. ;-) Trying to run a `yum update` out there would probably take longer than I usually spend there, and I'm not particularly worried about security updates, since the only way that system could possibly be more airgapped would be for it to exist on Mars. :-p Anyway, the DVD is _completely_ useless for this system. Pretty much every use case I have for this system requires packages from a certain third-party repository we all know and love, and even if Fedora contained all the packages I needed for it, they all certainly wouldn't on the DVD. Also, I really don't care about 95% of the packages on the DVD; I certainly don't need six different desktops. ;-) So instead when I refresh it from time to time, I just anaconda install onto a USB stick, yum install everything I want to it, then take it out there and dd it to the hard disk, manually making grub happy if necessary. This also allows me to configure it the way I want before I leave, so when I get out there it only takes me a few minutes to get it completely updated. I guess I could craft a kickstart and use livecd-creator instead, but that seems like more hassle than it's worth. Plus I keep that USB stick around so I have something that matches that system exactly at home, so if I ever decide I want to install some more stuff on it I can be sure I download all the RPMs necessary for a complete transaction. (Supposedly there's some offline download/install support in PackageKit for that usecase too, but it doesn't seem to be documented very well. The only reason I even know it exists is because hughsie asked on his blog if he could kill it. ;-) So if we really care about this usecase, we need to rebirth revisor or something similar so people can actually make images for their disconnected systems that have the stuff they want on them easily, instead of a grab bag of packages most of which they have no use for. For bonus points, maybe flesh out the offline update support so there's a sane way to update/install stuff on them afterward. Keeping the DVD around "because offline systems" is really just ignoring these users' actual needs. It would be nice if some development effort were put to making this actually better, but it's really an edge case that can already be handled by other, less elegant solutions like mine, so I really don't blame developers for not bothering with it. The only other use case we really have for the install DVD is for handing out at conferences, etc., and I think the multi-live DVD is a much better fit for that personally. > Another situation is where I am installing into a qemu-kvm virtual system. > Yes, there will be Internet connectivity. Yes, it is nice to have > everything updated on install. But, running with just the DVD image is a > lot faster (takes much less wall-clock time). Nowadays we have nice qcow2 images for that use case. Much better than the DVD IMHO, especially since a `yum update` is the first thing I'd do regardless... -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Sat, 2013-12-14 at 13:47 -0500, Richard Ryniker wrote: > The defining characteristic of the Live images is that they run > without installation on a user's disks. Beyond that, they have the > capability to install a minimal Fedora system to a local disk. Once > the size limit for a live image is increased beyond the capacity of a > CD (or other common media), there seems no reason to limit the live > image size to 1 GB, or any arbitrary value. There's no reason to limit it to any arbitrary value, but none of the values we've used or discussed is arbitrary. 1GB is the size of a 1GB USB stick, 2GB is the size of a 2GB USB stick. 3GB for example would make no sense as no-one makes media in that size. Obvious 'sensible' target sizes are 650MB CD, 700MB CD, 1GB USB, 2GB USB, 4GB USB, 4GiB (because of FAT32 filesystem issues...), single-layer DVD, 8GB USB, dual-layer DVD, 16GB USB. > Rather than struggle to find what can be be discarded from a live > image in order to achieve a particular size, why not build the DVD > product as a live system, or expand the existing live recipe to > include more of the frequently used packages and not build the DVD? > The DVD installer program has much more flexibility, but this is due > to that arbitrary size limit, I expect: there just is not space for > the full Fedora installation program (plus local repository) in > today's live images. No, it isn't, really. The live installer can only install the package set you actually get when booting live, because all it does is dump itself to the hard disk; it doesn't actually contain or install any packages per se. So I don't see how we can do the DVD-as-live-image thing in any practical way; the point of the DVD is that you can install _different_ environments from it, but there's no way you can do that from a live image. It's also worth noting that the installer team doesn't like installing from a live environment. It involves rather a lot of messy hacks and can cause breakage; the major problem they have is they cannot possibly trust that the system is in a 'clean' state when the installer initializes, which they can control from the 'traditional' installer mode. One thing they've floated as an idea is to have a separate 'installation environment' you could boot into from the live images - so you could either boot into 'try it out' live mode, or 'install it' installer mode, but not run the installer from within the live mode. > A sizable group of users may have very limited hardware resources - > no network, only a CD drive. This group would be a reasonable target > for a "Limited Resources" spin that seeks to tailor Fedora to such an > environment. For example, these systems may have too little memory to > support anaconda (and many of the applications in Fedora's default > configuration). Maybe a new SIG for this target. (Perhaps it already > exists and I, with richer hardware resources, never looked for it.) I don't believe it does, no. It seems like an interesting idea, so if you're interested in making it happen, you could certainly go ahead and make a proposal to the relevant authorities... > Modifications to limit and > make more specific the actual test coverage can help Fedora users > better understand what they have, and reflect the reality of QA > resource limits. I think we've always had this as a goal, but we've just winded up drifting slightly over the last few releases to the point where we're really struggling to keep up with the workload. > To this end, it would be good to have better distinction between what > QA tests and what other groups - SIG, upstream, packager, spin > creator, architecture group, etc. - are responsible to test. QA test > criteria is one place to document this, at least the QA view of it. This is something viking-ice is talking about as well, and I certainly agree with you guys that there's some value to it. The only problem I have is that I don't really see a lot of evidence that many other groups test their stuff at all in any particularly organized way, though I may well be missing something. I'd have a lot of time for a vision where we place some responsibility on the desktop SIG for desktop testing, on the KDE SIG for KDE testing and so on, but like I keep saying for the specific proposal here, we have to make sure it actually *happens*. I'm not a fan of QA just throwing our hands up and unilaterally saying "okay, we're just going to test X and trust that someone else cares about making sure Y and Z work", at least not until we've made some good-faith effort to make things better in a collaborative way. At present it feels a lot like people only test things when we (QA) draw up the test plans and then go out and make a fairly strenuous effort to plead with others to test them. I mean, if we just fire a TC/RC and stick the desktop matrices up, it's only intermittently that I've seen desktop SIG folks show up and run through the validation testing. If I or someone
Re: Criterion revision proposal: KDE default applications
The defining characteristic of the Live images is that they run without installation on a user's disks. Beyond that, they have the capability to install a minimal Fedora system to a local disk. Once the size limit for a live image is increased beyond the capacity of a CD (or other common media), there seems no reason to limit the live image size to 1 GB, or any arbitrary value. Rather than struggle to find what can be be discarded from a live image in order to achieve a particular size, why not build the DVD product as a live system, or expand the existing live recipe to include more of the frequently used packages and not build the DVD? The DVD installer program has much more flexibility, but this is due to that arbitrary size limit, I expect: there just is not space for the full Fedora installation program (plus local repository) in today's live images. Others have stated the need for something like the DVD collection of packages. Without this, those who need something like it will have to build their own, obtain it from a third party, or look at another distribution. For this reason, to simplify the Fedora products to (1) network installation and (2) stand-alone installation, I submit the installation DVD could be built as a live image. I do not like the thought that many users might decide they have to copy an entire Fedora repository to a portable hard drive in order to install the Fedora system they want on a machine without a good Internet connection. A sizable group of users may have very limited hardware resources - no network, only a CD drive. This group would be a reasonable target for a "Limited Resources" spin that seeks to tailor Fedora to such an environment. For example, these systems may have too little memory to support anaconda (and many of the applications in Fedora's default configuration). Maybe a new SIG for this target. (Perhaps it already exists and I, with richer hardware resources, never looked for it.) In any case, Adam Williamson's articulate comment about the practical limits to what Quality Assurance can achieve with a six month release cycle and the available resources is very relevant. The release criteria, in part, seek to define what will be tested, but they read more like a prescription for what "should" be tested. Modifications to limit and make more specific the actual test coverage can help Fedora users better understand what they have, and reflect the reality of QA resource limits. To this end, it would be good to have better distinction between what QA tests and what other groups - SIG, upstream, packager, spin creator, architecture group, etc. - are responsible to test. QA test criteria is one place to document this, at least the QA view of it. Adam, your recent work on storage tests reads like a Unit Test Plan for anaconda: something that tries to exercise all the code paths of the program. Is this the proper function of Fedora QA? If it is, what is the proper fraction of the anaconda development budget to be allocated to Fedora QA for this purpose? I use this as an example to support your observation that QA clearly does not have resources to test all it might want to test, and clearer definition is required for what QA will test and what others have to test. Your storage test cases look like something anaconda developers should run before they let a new version loose. Throw away a package because it was not tested, failed a test, or missed a deadline is not a solution, however vexed one might be about what has not been done. It is natural that many changes will occur in Fedora's package roster. I counted 39,500 rpm files in the F20 repository. Lots of changes, for many reasons, are normal, but it is not sensible to expect all these parts to work properly. It is not even reasonable to expect the ten percent of these files on the DVD to all work properly. Fedora QA, as a group, should probably take a pragmatic approach and focus on "critical path" and installation issues that affect large groups of users, and refer more detailed tests to others. Do more, certainly, if resources permit. And try to influence others to be more aware and effective in their test activities. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On lau 14.des 2013 00:54, Adam Williamson wrote: That requires will on the part of the desktop SIGs, though. QA is not going to be responsible for this. My position is either the desktop SIGs fix their stuff, or we will have to change the criteria as I proposed, because what other choice do we have? We will remove everything non core/base related out of our criteria and assist the communities surrounding those products to come up with criteria ( as well as test cases maybe ) specifically tailored for those products but that's where our ( QA communities ) involvement with the output from WG's ends period. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Sat, 2013-12-14 at 07:31 +0100, drago01 wrote: > On Sat, Dec 14, 2013 at 1:54 AM, Adam Williamson wrote: > > On Fri, 2013-12-13 at 18:49 -0500, Rahul Sundaram wrote: > >> Hi > >> > >> > >> On Fri, Dec 13, 2013 at 4:58 PM, Adam Williamson wrote: > >> > >> > >> > >> Well, then there's the problem. We can't have release criteria > >> that say > >> "we really stand behind the package sets installed from the > >> DVD" if we > >> don't. > >> > >> > >> That is true however the solution is not to weaken the release > >> criteria but decide a) do we need the DVD anymore b) if we need it, > >> whether there is anything against trimming down the default package > >> sets to be consistent with what is included in the live images. With > >> the new model, I think the right answer is to drop the DVD image > >> entirely but b) is the minimum we should do. > > > > That requires will on the part of the desktop SIGs, though. QA is not > > going to be responsible for this. My position is either the desktop SIGs > > fix their stuff, or we will have to change the criteria as I proposed, > > because what other choice do we have? > > Talk to FESCo ? Ask for them to remove the offending crap once we hit it? > Or "if the app does not start and is not part of live kick it out". > Its a one line change. It still means we have to find time to actually test them all at some point, which we don't have a great record of doing lately. See my notes on the status of the KDE desktop_menus test case in F20. It seems a bit bizarre to me that we'd wind up in a state which could be described as "we'll install stuff from the DVD that we don't really care about and have no idea if it works properly, until QA runs it and clicks a button and it crashes. At that point we'll take it out." What? Can we go back to my suggestion of increasing the size target for the desktop lives, deciding what packages you actually _do_ want to have in a default install of your desktops, and making the lives and DVDs both install precisely that package set? It'd be good to know the desktop team's take on that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Sat, Dec 14, 2013 at 1:54 AM, Adam Williamson wrote: > On Fri, 2013-12-13 at 18:49 -0500, Rahul Sundaram wrote: >> Hi >> >> >> On Fri, Dec 13, 2013 at 4:58 PM, Adam Williamson wrote: >> >> >> >> Well, then there's the problem. We can't have release criteria >> that say >> "we really stand behind the package sets installed from the >> DVD" if we >> don't. >> >> >> That is true however the solution is not to weaken the release >> criteria but decide a) do we need the DVD anymore b) if we need it, >> whether there is anything against trimming down the default package >> sets to be consistent with what is included in the live images. With >> the new model, I think the right answer is to drop the DVD image >> entirely but b) is the minimum we should do. > > That requires will on the part of the desktop SIGs, though. QA is not > going to be responsible for this. My position is either the desktop SIGs > fix their stuff, or we will have to change the criteria as I proposed, > because what other choice do we have? Talk to FESCo ? Ask for them to remove the offending crap once we hit it? Or "if the app does not start and is not part of live kick it out". Its a one line change. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On 14/12/13 12:49, Rahul Sundaram wrote: Hi On Fri, Dec 13, 2013 at 4:58 PM, Adam Williamson wrote: Well, then there's the problem. We can't have release criteria that say "we really stand behind the package sets installed from the DVD" if we don't. That is true however the solution is not to weaken the release criteria but decide a) do we need the DVD anymore b) if we need it, whether there is anything against trimming down the default package sets to be consistent with what is included in the live images. With the new model, I think the right answer is to drop the DVD image entirely but b) is the minimum we should do. Rahul I use use DVD's to initially load the system, sometimes I've given copies to others. Possibly I should again try a net install? Cheers, Gavin -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Fri, 2013-12-13 at 18:49 -0500, Rahul Sundaram wrote: > Hi > > > On Fri, Dec 13, 2013 at 4:58 PM, Adam Williamson wrote: > > > > Well, then there's the problem. We can't have release criteria > that say > "we really stand behind the package sets installed from the > DVD" if we > don't. > > > That is true however the solution is not to weaken the release > criteria but decide a) do we need the DVD anymore b) if we need it, > whether there is anything against trimming down the default package > sets to be consistent with what is included in the live images. With > the new model, I think the right answer is to drop the DVD image > entirely but b) is the minimum we should do. That requires will on the part of the desktop SIGs, though. QA is not going to be responsible for this. My position is either the desktop SIGs fix their stuff, or we will have to change the criteria as I proposed, because what other choice do we have? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
Hi On Fri, Dec 13, 2013 at 4:58 PM, Adam Williamson wrote: > > > Well, then there's the problem. We can't have release criteria that say > "we really stand behind the package sets installed from the DVD" if we > don't. > That is true however the solution is not to weaken the release criteria but decide a) do we need the DVD anymore b) if we need it, whether there is anything against trimming down the default package sets to be consistent with what is included in the live images. With the new model, I think the right answer is to drop the DVD image entirely but b) is the minimum we should do. Rahul -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Fri, 2013-12-13 at 16:42 -0500, Matthias Clasen wrote: > On Fri, 2013-12-13 at 12:44 -0800, Adam Williamson wrote: > > > As I've said, if people are willing to actually go out and do that, then > > fine. Does desktop team actively curate the DVD-installed package set? > > And to play the counter-factual game: imagine there had been a bug > > analogous to https://bugzilla.redhat.com/show_bug.cgi?id=1040922 in > > GNOME on the day of Go/No-Go meeting. Is the desktop SIG willing to take > > a stand and say 'yes, we should delay the release multiple weeks over > > Christmas if such a bug is discovered'? > > > > If so, then we can continue with the current criteria, though it would > > be ideal if desktop and KDE sigs could commit to helping with the > > testing. > > No, I take pretty much the same stance wrt. to the DVD: I pay attention > to the live image, and make sure it works. I don't think I've ever > downloaded or tried the DVD. I always found it very odd and awkward that > we hand out something at conferences and shows that nobody really pays > attention to. Well, then there's the problem. We can't have release criteria that say "we really stand behind the package sets installed from the DVD" if we don't. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Fri, 2013-12-13 at 12:44 -0800, Adam Williamson wrote: > As I've said, if people are willing to actually go out and do that, then > fine. Does desktop team actively curate the DVD-installed package set? > And to play the counter-factual game: imagine there had been a bug > analogous to https://bugzilla.redhat.com/show_bug.cgi?id=1040922 in > GNOME on the day of Go/No-Go meeting. Is the desktop SIG willing to take > a stand and say 'yes, we should delay the release multiple weeks over > Christmas if such a bug is discovered'? > > If so, then we can continue with the current criteria, though it would > be ideal if desktop and KDE sigs could commit to helping with the > testing. No, I take pretty much the same stance wrt. to the DVD: I pay attention to the live image, and make sure it works. I don't think I've ever downloaded or tried the DVD. I always found it very odd and awkward that we hand out something at conferences and shows that nobody really pays attention to. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Fri, 2013-12-13 at 21:36 +0100, drago01 wrote: > On Fri, Dec 13, 2013 at 3:05 AM, Adam Williamson wrote: > > It was clear at the Go/No-Go meeting today that KDE SIG does not > > consider this release criterion applicable/desired: > > > > "All applications that can be launched using the standard graphical > > mechanism of a release-blocking desktop after a default installation of > > that desktop must start successfully and withstand a basic functionality > > test." > > > > https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_application_functionality > > > > jreznik says they consider the live image their 'polished product' where > > everything must work, while the DVD install is more of a grab-bag - they > > install a whole bunch of stuff, and don't think it's the end of the > > world if one or two bits are broken. > > > > Given that, I propose re-wording as follows: > > > > "All applications that can be launched using the standard graphical > > mechanism of a release-blocking live image after an installation of that > > image must start successfully and withstand a basic functionality test." > > > > So, that doesn't just apply to KDE. True, but I actually think it's a > > reasonable revision for GNOME as well. It makes sense to see the live > > images as defining what our 'polished core desktops' consist of, and the > > DVD as more of a grab-bag of packages. > > No that makes zero sense. You solution is not a solution at all "we > found out that we ship random crap on the DVD that does not even start > up ... so lets pretend we don't know about it" ... the proper solution > (as others said) is to simply to *NOT* install random stuff by default > just because there is space on the media. As I've said, if people are willing to actually go out and do that, then fine. Does desktop team actively curate the DVD-installed package set? And to play the counter-factual game: imagine there had been a bug analogous to https://bugzilla.redhat.com/show_bug.cgi?id=1040922 in GNOME on the day of Go/No-Go meeting. Is the desktop SIG willing to take a stand and say 'yes, we should delay the release multiple weeks over Christmas if such a bug is discovered'? If so, then we can continue with the current criteria, though it would be ideal if desktop and KDE sigs could commit to helping with the testing. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Fri, Dec 13, 2013 at 3:05 AM, Adam Williamson wrote: > It was clear at the Go/No-Go meeting today that KDE SIG does not > consider this release criterion applicable/desired: > > "All applications that can be launched using the standard graphical > mechanism of a release-blocking desktop after a default installation of > that desktop must start successfully and withstand a basic functionality > test." > > https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_application_functionality > > jreznik says they consider the live image their 'polished product' where > everything must work, while the DVD install is more of a grab-bag - they > install a whole bunch of stuff, and don't think it's the end of the > world if one or two bits are broken. > > Given that, I propose re-wording as follows: > > "All applications that can be launched using the standard graphical > mechanism of a release-blocking live image after an installation of that > image must start successfully and withstand a basic functionality test." > > So, that doesn't just apply to KDE. True, but I actually think it's a > reasonable revision for GNOME as well. It makes sense to see the live > images as defining what our 'polished core desktops' consist of, and the > DVD as more of a grab-bag of packages. No that makes zero sense. You solution is not a solution at all "we found out that we ship random crap on the DVD that does not even start up ... so lets pretend we don't know about it" ... the proper solution (as others said) is to simply to *NOT* install random stuff by default just because there is space on the media. We should improve the software installation experience so that people can easily find and install software they need (that's what we have started to do in F20 which is a way better approach then "just install tons of stuff by default"). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
"Jóhann B. Guðmundsson" (johan...@gmail.com) said: > The DVD is releng/fesco responsibility, they dictate and decide > what's on it and what not and how it's delivered not the > sub-community's. Really? The KDE SIG has full access to change what gets installed when you install from the DVD. If you're saying it's releng and FESCo's responsibility to fix that, then as a releng and FESCo member, I'll fix it... commit f349ff05510a1f60cb43470cb544d55136c837c3 (HEAD, f20) Author: Bill Nottingham Date: Fri Dec 13 12:22:39 2013 -0500 Drop KDE from the DVD, to avoid blocker bugs due to installed package set. diff --git a/fedora-install-fedora.ks b/fedora-install-fedora.ks index f1a767f..fd9f4e9 100644 --- a/fedora-install-fedora.ks +++ b/fedora-install-fedora.ks @@ -73,13 +73,6 @@ dracut-* @libreoffice @gnome-games -## KDE -@kde-desktop -@kde-apps -@kde-education -@kde-media -@kde-office - ## XFCE @xfce-desktop @xfce-apps @@ -111,7 +104,6 @@ dracut-* @rpm-development-tools @fedora-packager @gnome-software-development -@kde-software-development @x-software-development @virtualization @web-server @@ -139,8 +131,6 @@ autocorr-* eclipse-nls-* hunspell-* hyphen-* -calligra-l10n-* -kde-l10n-* libreoffice-langpack-* man-pages-* mythes-* commit 833fdfaf7ec6a9588b1d51a11b9a2a9d956ab873 (HEAD, master) Author: Bill Nottingham Date: Fri Dec 13 12:25:13 2013 -0500 Drop KDE environment as an installation choice. Live media is the SIG-supported install method. diff --git a/comps-f21.xml.in b/comps-f21.xml.in index 66ff5c5..f462e58 100644 --- a/comps-f21.xml.in +++ b/comps-f21.xml.in @@ -6200,34 +6200,6 @@ -kde-desktop-environment -<_name>KDE Plasma Workspaces -<_description>The KDE Plasma Workspaces, a highly-configurable graphical user interface which includes a panel, desktop, system icons and desktop widgets, and many powerful KDE applications. -10 - - base-x - standard - core - admin-tools - dial-up - fonts - input-methods - multimedia - hardware-support - printing - guest-desktop-agents - kde-desktop - - - kde-apps - kde-education - kde-media - kde-office - kde-telepathy - 3d-printing - - - xfce-desktop-environment <_name>Xfce Desktop <_description>A lightweight desktop environment that works well on low end machines. Ready to push whenever. Now, I'm ASSuming they don't actually want that. But, to be clear: the installation choices of the assorted desktops on the DVD/netinstall are the provence of those SIGs. If they don't want to maintain them, we can absolutely remove them, just as we'd do for any Spin that was not maintained or tested. Bill -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Fri, 2013-12-13 at 05:54 -0500, Gene Czarcinski wrote: > On 12/13/2013 03:20 AM, poma wrote: > > On 13.12.2013 08:25, "Jóhann B. Guðmundsson" wrote: > > > >> >I argue that we should get rid of the DVD it's an era of the past and > >> >just provide net-install iso and lives. > > Probably there are good reasons why the DVD is still here. > Indeed! There are environments/situations where there is no network > connectivity (at least to the Internet) and never will be. It is this > type of situations that will require a DVD. > > Another situation is where I am installing into a qemu-kvm virtual > system. Yes, there will be Internet connectivity. Yes, it is nice to > have everything updated on install. But, running with just the DVD > image is a lot faster (takes much less wall-clock time). Not that I necessarily agree with johann on this one, but he did say to keep the netinst *and the lives*. Live installs work without a network and are even faster than DVD installs in VMs. > BTW, if a live image is suppose to represent "The" set for a desktop > such as KDE, then that should be the same on the DVD. But, if there > really should be more than can fit on a live cdrom image, then why not > change that to be a live DVD image. After all, how many computers out > only have a cdrom drive as oppose to a dvd drive capable of handling > both cdroms and dvds? We already gave up on CDs a couple of releases back. GNOME and KDE are currently targeting 1GB (power-of-ten), but still have to cut stuff out to make size. They can choose to go up to 2GB or higher if they like; it's up to the SIGs to decide (at the start of a release cycle, of course). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On 12/13/2013 04:24 PM, Gene Czarcinski wrote: > On 12/13/2013 03:20 AM, poma wrote: >> On 13.12.2013 08:25, "Jóhann B. Guðmundsson" wrote: >> >>> >I argue that we should get rid of the DVD it's an era of the past and >>> >just provide net-install iso and lives. >> Probably there are good reasons why the DVD is still here. > Indeed! There are environments/situations where there is no network > connectivity (at least to the Internet) and never will be. It is this > type of situations that will require a DVD. > > Another situation is where I am installing into a qemu-kvm virtual > system. Yes, there will be Internet connectivity. Yes, it is nice to > have everything updated on install. But, running with just the DVD > image is a lot faster (takes much less wall-clock time). > > BTW, if a live image is suppose to represent "The" set for a desktop > such as KDE, then that should be the same on the DVD. But, if there > really should be more than can fit on a live cdrom image, then why not > change that to be a live DVD image. After all, how many computers out > only have a cdrom drive as oppose to a dvd drive capable of handling > both cdroms and dvds? > The Fedora Gnome and KDE images are currently too big for a CD, we actually have transitioned to live DVD. Only the XFCE, LXDE, and MATE-Compiz Live Spins can be accommodated on a CD. > Gene -- Regards, Rejy M Cyriac (rmc) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On 12/13/2013 12:55 PM, "Jóhann B. Guðmundsson" wrote: > > On fös 13.des 2013 06:30, Adam Williamson wrote: >> On Fri, 2013-12-13 at 05:31 +, "Jóhann B. Guðmundsson" wrote: >>> On fös 13.des 2013 02:05, Adam Williamson wrote: It was clear at the Go/No-Go meeting today that KDE SIG does not consider this release criterion applicable/desired: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_application_functionality jreznik says they consider the live image their 'polished product' where everything must work, while the DVD install is more of a grab-bag - they install a whole bunch of stuff, and don't think it's the end of the world if one or two bits are broken. Given that, I propose re-wording as follows: >>> You are trying to fix the problem on the wrong end thus leave the >>> criteria as is. >>> >>> The installing should not differ ( or in other word be consistent ) >>> regardless if you install from the live or from the dvd the end result >>> should be the same. >>> >>> You should have the same service enablement, the same desktop instalment >>> and experience etc. >>> >>> So get releng to get their act together and fix that for the dvd so >>> matches with the live. >> Per my long reply on the other sub-thread, I'm fine with that if it >> actually _happens_. But it's not releng's responsibility; it's the KDE >> and desktop SIGs. They own this stuff: it's their responsibility to >> choose what packages go in the lives and what packages are deployed when >> you do a DVD install of their desktops. > > The DVD is releng/fesco responsibility, they dictate and decide what's > on it and what not and how it's delivered not the sub-community's. > > There are other differences then just the package selection that get > installed for example which services are enabled etc. compared to the > lives. > > I argue that we should get rid of the DVD it's an era of the past and > just provide net-install iso and lives. > I differ with you on this point. There are still so many places in the world with limited/expensive/slow, or even no network connectivity at all. In fact, it is only in the developed countries that broadband is prevalent like water, and in the rest of the world, just like water, it is a limited resource. On a related note, folks in the developed world might be surprised to know that 32-bit processors are still very much in use. I work with the Free Media project of Fedora, and I know of so many instances where providing the Fedora DVD (32 and 64 bit) has empowered the lives of people and small organisations. > Those lives should be under full control of the sub-community both in > terms of size,partitioning, filesystem layout.filesystem type, package > selection as well as service enablement even to the use an alternative > installer but those sub-community should also be responsible for QA-ing > ( testing/triaging ) as well as the necessary release engineering work > to release their own lives.. > > JBG -- Regards, Rejy M Cyriac (rmc) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On 12/13/2013 03:20 AM, poma wrote: On 13.12.2013 08:25, "Jóhann B. Guðmundsson" wrote: >I argue that we should get rid of the DVD it's an era of the past and >just provide net-install iso and lives. Probably there are good reasons why the DVD is still here. Indeed! There are environments/situations where there is no network connectivity (at least to the Internet) and never will be. It is this type of situations that will require a DVD. Another situation is where I am installing into a qemu-kvm virtual system. Yes, there will be Internet connectivity. Yes, it is nice to have everything updated on install. But, running with just the DVD image is a lot faster (takes much less wall-clock time). BTW, if a live image is suppose to represent "The" set for a desktop such as KDE, then that should be the same on the DVD. But, if there really should be more than can fit on a live cdrom image, then why not change that to be a live DVD image. After all, how many computers out only have a cdrom drive as oppose to a dvd drive capable of handling both cdroms and dvds? Gene -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On 13.12.2013 08:25, "Jóhann B. Guðmundsson" wrote: > I argue that we should get rid of the DVD it's an era of the past and > just provide net-install iso and lives. Probably there are good reasons why the DVD is still here. poma -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On fös 13.des 2013 06:30, Adam Williamson wrote: On Fri, 2013-12-13 at 05:31 +, "Jóhann B. Guðmundsson" wrote: On fös 13.des 2013 02:05, Adam Williamson wrote: It was clear at the Go/No-Go meeting today that KDE SIG does not consider this release criterion applicable/desired: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_application_functionality jreznik says they consider the live image their 'polished product' where everything must work, while the DVD install is more of a grab-bag - they install a whole bunch of stuff, and don't think it's the end of the world if one or two bits are broken. Given that, I propose re-wording as follows: You are trying to fix the problem on the wrong end thus leave the criteria as is. The installing should not differ ( or in other word be consistent ) regardless if you install from the live or from the dvd the end result should be the same. You should have the same service enablement, the same desktop instalment and experience etc. So get releng to get their act together and fix that for the dvd so matches with the live. Per my long reply on the other sub-thread, I'm fine with that if it actually _happens_. But it's not releng's responsibility; it's the KDE and desktop SIGs. They own this stuff: it's their responsibility to choose what packages go in the lives and what packages are deployed when you do a DVD install of their desktops. The DVD is releng/fesco responsibility, they dictate and decide what's on it and what not and how it's delivered not the sub-community's. There are other differences then just the package selection that get installed for example which services are enabled etc. compared to the lives. I argue that we should get rid of the DVD it's an era of the past and just provide net-install iso and lives. Those lives should be under full control of the sub-community both in terms of size,partitioning, filesystem layout.filesystem type, package selection as well as service enablement even to the use an alternative installer but those sub-community should also be responsible for QA-ing ( testing/triaging ) as well as the necessary release engineering work to release their own lives.. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Fri, 2013-12-13 at 05:31 +, "Jóhann B. Guðmundsson" wrote: > On fös 13.des 2013 02:05, Adam Williamson wrote: > > It was clear at the Go/No-Go meeting today that KDE SIG does not > > consider this release criterion applicable/desired: > > > > "All applications that can be launched using the standard graphical > > mechanism of a release-blocking desktop after a default installation of > > that desktop must start successfully and withstand a basic functionality > > test." > > > > https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_application_functionality > > > > jreznik says they consider the live image their 'polished product' where > > everything must work, while the DVD install is more of a grab-bag - they > > install a whole bunch of stuff, and don't think it's the end of the > > world if one or two bits are broken. > > > > Given that, I propose re-wording as follows: > > You are trying to fix the problem on the wrong end thus leave the > criteria as is. > > The installing should not differ ( or in other word be consistent ) > regardless if you install from the live or from the dvd the end result > should be the same. > > You should have the same service enablement, the same desktop instalment > and experience etc. > > So get releng to get their act together and fix that for the dvd so > matches with the live. Per my long reply on the other sub-thread, I'm fine with that if it actually _happens_. But it's not releng's responsibility; it's the KDE and desktop SIGs. They own this stuff: it's their responsibility to choose what packages go in the lives and what packages are deployed when you do a DVD install of their desktops. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Fri, 2013-12-13 at 05:38 +, "Jóhann B. Guðmundsson" wrote: > On fös 13.des 2013 04:06, Adam Williamson wrote: > > it was -1'ed at go/no-go meeting in about five seconds. No-one voted +1 > > blocker on it. > > For the first I was not present there since I arrived later then usual > due to $dayjob but otherwise I would have voted +1 on it ( which would > have then just have been me ) + most of individual present have been > voting to push the release out the door to meet that arbitrary deadline > we never make anyway which renders this argument mood. Well, it's not an arbitrary deadline. It's the release schedule. Fedora's supposed to be strongly tied to its schedule; we're not a feature-based release project. So, it inevitably has to be the case that we have to calibrate our quality standards to what it's practical to achieve, in terms of testing and fixing, approximately within that cycle. The way Fedora is set up, it is reasonable for us to slip, oh, say up to three weeks a cycle, to fix really serious problems. But we shouldn't be slipping almost every milestone for every release, which we are. We shouldn't be putting ourselves into positions, _repeatedly_, where we have the choice of fudging our quality standards or delaying releases for multiple months. When those things are happening, what it indicates is that there is a fundamental mismatch between the quality standards we're setting ourselves, the development goals we're setting ourselves, and the resources - in terms of overall tester/developer hours, i.e. a product of the number of devs and testers we have and the release cycle we chose - we have to achieve those things. The last few cycles we've theoretically set our standards at a certain point, and then not really got close to living up to them. If we say we're going to block on every possible partition layout, we need to test at least some reasonable representative sample of all possible partition layouts by, at latest, Beta RC1. That didn't happen. If we say we're going to block on every single app installed by default for either of two desktops, we need to actually test every single app installed by default on either of those two desktops by Beta RC1, and ideally keep doing it with every relevant change pushed stable after that. That doesn't happen. The current state is that we're setting a standard which we clearly don't have the QA resources to stand behind sufficiently within the timeframe the project is comfortable with spending on a release, and on freeze/test/stabilize cycles. Pete knows what's coming out of the three-product proposal, but somehow I don't see it making the freezes longer or the set of deliverables any smaller. If we want to maintain the standards of quality we claimed to be setting for F18, F19 and F20 and actually live up to them, we would need to either drastically increase the resources we dedicate to QA and bugfixing, or reduce the development goals we set. It never seems like it's on the cards to reduce Fedora's pace of development: no-one seems to have the appetite for it. No-one wants to be the person who says 'no, that is a nice sounding feature but we don't have time for it. Put it in the next release.' It never happens. So we're left with the resources. Red Hat does not have a dozen interns lying around the place we can feed into the Fedora QA hopper. We've certainly got excellent community testers, and some who've started contributing or contributing more in recent releases and helped hugely to make them less of a disaster than they could have been. But it's not like we're getting a dozen new volunteers who'll put in multiple hours per day on testing either. Extending the release cycle or lengthening freezes seems to be as unlikely to happen as reducing the development churn; look at how this thing with trying to make the F21 cycle longer is going with FESCo. So, the way I see it, if we can't significantly reduce the pace of Fedora development, significantly increase the number of QA and developer people we have available, or lengthen the release cycle or freezes to give us the effect of more resources dedicated to stabilization with the same number of people, we either reduce the expectations we say we have, or we keep on basically lying about what our quality expectations are and then coming up with paper-thin excuses as to why not meeting them doesn't 'really' mean we have to block, while running around like headless chickens throwing builds against the wall one day before go/no-go to fix a bug we didn't know about until 1.1 days before go/no-go. I dunno about you, but the headless chicken act and the hero validation runs are wearing on me. Maybe if we do what I'm suggesting, and we do well for a while, we'll start feeling like we're on top of everything and we have the confidence to move in the direction of increasing the standards again. But right now, honestly, can you say we're in a position where we're able to realistically meet al
Re: Criterion revision proposal: KDE default applications
On fös 13.des 2013 02:05, Adam Williamson wrote: It was clear at the Go/No-Go meeting today that KDE SIG does not consider this release criterion applicable/desired: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_application_functionality jreznik says they consider the live image their 'polished product' where everything must work, while the DVD install is more of a grab-bag - they install a whole bunch of stuff, and don't think it's the end of the world if one or two bits are broken. Given that, I propose re-wording as follows: You are trying to fix the problem on the wrong end thus leave the criteria as is. The installing should not differ ( or in other word be consistent ) regardless if you install from the live or from the dvd the end result should be the same. You should have the same service enablement, the same desktop instalment and experience etc. So get releng to get their act together and fix that for the dvd so matches with the live. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Criterion revision proposal: KDE default applications
It was clear at the Go/No-Go meeting today that KDE SIG does not consider this release criterion applicable/desired: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_application_functionality jreznik says they consider the live image their 'polished product' where everything must work, while the DVD install is more of a grab-bag - they install a whole bunch of stuff, and don't think it's the end of the world if one or two bits are broken. Given that, I propose re-wording as follows: "All applications that can be launched using the standard graphical mechanism of a release-blocking live image after an installation of that image must start successfully and withstand a basic functionality test." So, that doesn't just apply to KDE. True, but I actually think it's a reasonable revision for GNOME as well. It makes sense to see the live images as defining what our 'polished core desktops' consist of, and the DVD as more of a grab-bag of packages. The lives will (should) always contain the bits the desktop SIGs think are absolutely key pieces of the desktop. And I think we could generally do with a bit of criteria watering-down; we're starting to do a lot of fudges and waives, which indicates the criteria are currently too tight for us to realistically enforce. Things are better when we can stand solidly behind the criteria without fudging stuff. CCing KDE and desktop lists. If folks feel that we should restrict this change to KDE only, please do yell, but I'm kinda liking the simple version. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
