Re: rfc: expectations for partitioning, Fedora.next
On Feb 24, 2014, at 10:34 AM, Bruno Wolff III br...@wolff.to wrote: On Sat, Feb 22, 2014 at 18:33:17 -0700, Chris Murphy li...@colorremedies.com wrote: The bootable raid1 case is actually fragile due to the use of mdadm version 0.9 metadata; I believe that version 1.0 is used for boot partitions, not 0.9. That way they still work with bootloaders that don't understand md raid. Yes I knew that, I don't know why I wrote 0.9. https://bugzilla.redhat.com/show_bug.cgi?id=1046725#c16 However, both are in approximately the same position at the end of the physical device, and still work with bootloaders that don't treat them as members in an array. But this is not considered a good practice. https://bugzilla.redhat.com/show_bug.cgi?id=1046725#c9 If using raid, use a bootloader that understands it. I confirmed in the bug that GRUB2 boots from mdadm metadata version 1.2 superblocks just fine. That's the version we should be using. https://bugzilla.redhat.com/show_bug.cgi?id=1046725#c18 Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rfc: expectations for partitioning, Fedora.next
On Wed, 19 Feb 2014 16:55:56 -0700 Chris Murphy li...@colorremedies.com wrote: and the user gets to choose a couple of variations: encryption, and a way to reuse an existing /home. Personally, I wouldn't be happy with too restrictive. home lan setup I setup fresh install Desktops with a min of four hds' One partition per hd /boot + 2mb boot bios (or whatever it's called) ssd / /home + hd for each extra user if required swap installed non LVM, ext4 luks I can use 10-20 per server. (raid1) # I've been hearing for years storage is cheap. ___ Regards Frank frankly3d.com -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rfc: expectations for partitioning, Fedora.next
On Feb 22, 2014, at 1:57 AM, Frank Murphy frankl...@gmail.com wrote: On Wed, 19 Feb 2014 16:55:56 -0700 Chris Murphy li...@colorremedies.com wrote: and the user gets to choose a couple of variations: encryption, and a way to reuse an existing /home. Personally, I wouldn't be happy with too restrictive. home lan setup I setup fresh install Desktops with a min of four hds' One partition per hd /boot + 2mb boot bios (or whatever it's called) ssd / /home + hd for each extra user if required swap installed non LVM, ext4 luks I can use 10-20 per server. (raid1) # I've been hearing for years storage is cheap. The context of what you quoted from me above is the Automatic/guided path. I can't tell you how Automatic partitioning works with four disks, but it definitely doesn't do raid1. However, it's an interesting data point that your installations involved a minimum of four hard drives. That's really unheard of on Windows or OS X - which I include only to underscore how rare a configuration it is, not whether it's right or wrong. I really wish we had more data on how people are configuring their servers and workstations, or want to. The bootable raid1 case is actually fragile due to the use of mdadm version 0.9 metadata; and also there's a regression on UEFI computers that makes it decently likely the system can't be (re)booted degraded. So if there's merit in bootable (rootfs on) degraded raid1 or 10 or 5, some work needs to be done. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rfc: expectations for partitioning, Fedora.next
On 2014-02-22 18:49 (GMT-0700) Chris Murphy composed: This crappy partioning GUI in the installer is does not give me the amount of control on partitioning desired by me. I don't understand this. It's the most capable GUI partitioner + OS installer I've ever encountered, and I've used quite a few installers, yet maybe I'm missing something obvious? openSUSE? Nothing else comes close. To start with, it doesn't need even 500M RAM to run. I've used it not so long ago on 384M, and seen anecdotes of needing as little as 128M or 160M with swap available not so long ago. It's built on the same YaST2 that's used for configuration in live installations. Practically nothing is impossible in its installer GUI that's possible in its live system configuration GUI. WRT GUI software selection during installation, everything else is several orders of magnitude behind openSUSE. I can't give full details about using its partitioner during installation, because I use a proprietary partitioner to prepare all to be used in advance of installation 99.6% of the time. It's easy to use to configure RAID, and to select mount points and mount options, with a tree configuration that doesn't confound by inexplicably repeating the same partitions under various anti-sorted individual and grouped names the way Anaconda does. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rfc: expectations for partitioning, Fedora.next
On Feb 22, 2014, at 7:33 PM, Felix Miata mrma...@earthlink.net wrote: On 2014-02-22 18:49 (GMT-0700) Chris Murphy composed: This crappy partioning GUI in the installer is does not give me the amount of control on partitioning desired by me. I don't understand this. It's the most capable GUI partitioner + OS installer I've ever encountered, and I've used quite a few installers, yet maybe I'm missing something obvious? openSUSE? Nothing else comes close. Good example. There's a lot of nitty gritty reveals in openSUSE expert partitioner: I can set the right ext4/XFS mkfs options for proper hardware RAID alignment, and disable the ext4 journal, and a ton of other stuff. But partitioning, RAID, and LVM wise, I'm not seeing what I can do with openSUSE expert partitioning that I can't do with anaconda. However, on anaconda, I can create RAID 4 arrays, which seems unnecessary. Anyway, there's sufficient duplicative effort between then openSUSE and Fedora installers when it comes to ninja partitioning I'm not really understanding why they don't share an upstream project. And why they prevent their users from leveraging these capabilities to create storage outside of an OS install context, and for making modifications to existing storage. They aren't as pretty as gparted, but do a lot more. It's a lot of wheels being reinvented. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rfc: expectations for partitioning, Fedora.next
On 2014-02-22 20:57 (GMT-0700) Chris Murphy composed: there's sufficient duplicative effort between then openSUSE and Fedora installers when it comes to ninja partitioning I'm not really understanding why they don't share an upstream project. YaST2 is traditionally one of the top 2 things that keeps openSUSE users openSUSE users, a long way off from branching out to become a project independent its SUSE heritage. YaST is YaST, not an installer. What it does as an installer is a (major) byproduct of what it is, a comprehensive user friendly configuration UI (Yet Another Setup Tool, v2, on its way to becoming v3...). And why they prevent their users from leveraging these capabilities to create storage outside of an OS install context, and for making modifications to existing storage. They aren't as pretty as gparted, but do a lot more. It's a lot of wheels being reinvented. I'm pretty sure the YaST partitioner is *parted working underneath its GTK/QT personalities. Last year YaST2 began the long process of refactoring from its original language to Ruby, in part in order to to attract more outsiders to participate in its maintenance and evolution, but also to more easily import and export the many components that make it what it is. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rfc: expectations for partitioning, Fedora.next
On 02/23/2014 03:33 AM, Felix Miata wrote: On 2014-02-22 18:49 (GMT-0700) Chris Murphy composed: This crappy partioning GUI in the installer is does not give me the amount of control on partitioning desired by me. I don't understand this. It's the most capable GUI partitioner + OS installer I've ever encountered, and I've used quite a few installers, yet maybe I'm missing something obvious? openSUSE? That's one point. Most people I have been talking to, are German and thus quite likely have experience with the openSUSE. I for one, also consider it to be the most evolved partitioner amongst those installers/partitioners I've encountered throughout the years. Another point people are referring to, is the Usability of Fedora's partitioner's GUI. Esp. users with some Linux experience (no absolute new comers nor experts/nerds), complain about too much hidden voodoo and shy away from installing Fedora, because they are afraid of the partitioner killing their existing partioning and them loosing the other OSes they already have installed (Often Win + Ubuntu). Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rfc: expectations for partitioning, Fedora.next
On 02/19/2014 10:59 PM, Chris Murphy wrote: On Feb 19, 2014, at 6:07 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2014-02-19 at 16:55 -0700, Chris Murphy wrote: If the bar is going to be raised, Just as a sidebar, I'm not sure you're entirely on track with this assessment - I haven't quite read the same 'undertone' into the .next discussions. I don't have a way to qualify the magnitude of the raising. So whether it's static or is raised, and if raised then by how much, is something sufficiently open ended right now that it needs to be made more clear. Or I need remedial attention. then my instinct is to be even more aggressive with how the installer should only present recommended or at least sane outcomes to users. It probably shouldn't ever crash. snip for clarity We probably should have *one* file system option for Guided partitioning, which is the recommended layout, and the user gets to choose a couple of variations: encryption, and a way to reuse an existing /home. Based on the last discussion on anaconda-devel, I'm not sure we can get down to one, but I think there is some leeway for cutting it down from four. This definitely needs to be proposed to the anaconda devs, though. I would be in favor of at least cutting it down from the current set. I think there's inherent value in the project saying this is the layout we recommend wen it comes to the guided path. It's not much of a guide to have four massively different partition schemes: one of which was a surprising new comer that didn't work at all up until beta and then imploded at the last second before ship. One of which at the time was still labeled experimental in the kernel, but that status wasn't revealed to the user, they had to go read tea leaves or visit the water cooler in the 5th floor stair well to know that. So I'd push for one and maybe we get two. *shrug* I'm well aware that suggesting greater conservatism on the guided path very well might mean Btrfs gets booted, even though I'd pick it as easier to learn and manage than LVM. So really, I'm fairly convinced at this point that what's needed is feature chop, it's just a matter of how much which depends on what quality level expectations the WGs decide upon. What's your plan for moving forward with this? No plan. But I question whether WG members really understand the state of the installer: how many outcomes it enables; how many QA resources go into testing it as a percentage of all testing; and yet despite that, as a percentage of outcomes, how QA likely isn't testing even a majority of Manual partitioning outcomes; and the perception of Fedora users expecting that these outcomes have at least been attempted by QA. I think there's a disconnect. And I'm happy to be totally wrong about that, but when I look at other installers, I can't help but think they're successful not because of what they can do, but what they refuse to do. And yeah, we aren't going to ever have an installer that only produces 5 or 6 outcomes, it'll probably always be several dozen at a minimum. But several dozen right now would be an f'n godsend compared to what we've got. So I think the factual information of the installer state of affair, user perception and WG expectations for the installer need better qualification. Chris Murphy I've been pondering this, and I have an idea that I borrowed from the enemy (M$). When you install anything in Windows land - including the OS, IIRC - you are given a choice: default install, or custom. Why can't we set anaconda up this way, say, at the initial boot where you're given the choice to check the media or install. Set one more option there, let the options be: Install Fedora to this system (default, guided installation) Install Fedora to this system (custom, manual selection *WARNING - AT YOUR OWN RISK*) Check this media and install Fedora to this system (default, guided installation). Then in the easy path, the user is given two choices - standard partitions or LVM (or btrfs if Chris gets his way). We test these as the #1 critical must work selections. Anything in the manual path is either in between or bonus. Dan -- Dan Mossor Systems Engineer at Large Fedora QA Team Volunteer FAS: dmossor IRC: danofsatx San Antonio, Texas, USA -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rfc: expectations for partitioning, Fedora.next
On Fri, 2014-02-21 at 10:54 -0600, Dan Mossor wrote: I've been pondering this, and I have an idea that I borrowed from the enemy (M$). When you install anything in Windows land - including the OS, IIRC - you are given a choice: default install, or custom. Why can't we set anaconda up this way, say, at the initial boot where you're given the choice to check the media or install. Set one more option there, let the options be: Install Fedora to this system (default, guided installation) Install Fedora to this system (custom, manual selection *WARNING - AT YOUR OWN RISK*) Check this media and install Fedora to this system (default, guided installation). Then in the easy path, the user is given two choices - standard partitions or LVM (or btrfs if Chris gets his way). We test these as the #1 critical must work selections. Anything in the manual path is either in between or bonus. We already have that choice, only it happens at the appropriate point (the Installation Destination spoke). -- 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: rfc: expectations for partitioning, Fedora.next
On Feb 21, 2014, at 10:50 AM, Adam Williamson awill...@redhat.com wrote: On Fri, 2014-02-21 at 10:54 -0600, Dan Mossor wrote: I've been pondering this, and I have an idea that I borrowed from the enemy (M$). When you install anything in Windows land - including the OS, IIRC - you are given a choice: default install, or custom. Why can't we set anaconda up this way, say, at the initial boot where you're given the choice to check the media or install. Set one more option there, let the options be: Install Fedora to this system (default, guided installation) Install Fedora to this system (custom, manual selection *WARNING - AT YOUR OWN RISK*) Check this media and install Fedora to this system (default, guided installation). Then in the easy path, the user is given two choices - standard partitions or LVM (or btrfs if Chris gets his way). We test these as the #1 critical must work selections. Anything in the manual path is either in between or bonus. We already have that choice, only it happens at the appropriate point (the Installation Destination spoke). We don't really have that choice because the Windows default path is the choice to not be further molested with additional, superfluous, and undefined options. Our easy path is more complicated than the Windows custom path. The distro should present a recommendation, as in one, when using the Automatic/guided/easy path, and spare the user from nonsense options. I'd even suck it up in favor of the technically meritless and user hostile LVM layout as the default if it means no other options. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rfc: expectations for partitioning, Fedora.next
On Wed, 19 Feb 2014 21:59:54 -0700 Chris Murphy li...@colorremedies.com wrote: On Feb 19, 2014, at 6:07 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2014-02-19 at 16:55 -0700, Chris Murphy wrote: If the bar is going to be raised, Just as a sidebar, I'm not sure you're entirely on track with this assessment - I haven't quite read the same 'undertone' into the .next discussions. I don't have a way to qualify the magnitude of the raising. So whether it's static or is raised, and if raised then by how much, is something sufficiently open ended right now that it needs to be made more clear. Or I need remedial attention. then my instinct is to be even more aggressive with how the installer should only present recommended or at least sane outcomes to users. It probably shouldn't ever crash. I don't think you'll get this past the devs. IIRC, their position is that it is best to crash with a useful traceback in any case where you somehow wind up in a situation where the installer is not completely confident about what's going on, for two reasons: 1) they only want installation to proceed if they are very confident it will work correctly 2) it helps to fix problems, because they get much / all of the necessary information from the bug reporting process They're generally very reluctant to have anaconda try to 'sweep things under the carpet and just go ahead anyway' when it runs into problems, for the above two reasons. I completely understand that argument, and especially post-beta I've supported rough edges in the installer not being blockers because of realism. But *if* the bar is being raised, I think there's a necessary commensurate change (and thus a risk) that the installer is going to have to be held to a higher standard too. And if that's not tenable, what I'd say is that to get to better stability is to chop out peripheral, esoteric outcomes that are maybe nice to haves or bad ass but really aren't strictly necessary. After all this is about getting an OS installed that works. 80 outcomes?! Is that really necessary? I concur with this reasoning. 80+ outcomes seems a little much - cutting some edge cases would be good. I don't know how wise it would be to 'sweep errors under the carpet' - The anaconda devs argument here is a sound one. Another question (and we should likely include the anaconda devs in this discussion) is if there's a way to catch errors, submit a bug report with the right information and then restart the installation inline (I realize this isn't a trivial addition - and might not be possible either). I don't think we get to say the bar is being raised while the installer gets to offer marginally popular layouts, themselves probably edge cases, that then result in confusing dead ends, crashes, or don't boot after install. Such bugs are effectively fixed by simply disallowing those paths. The resources are then spent maturing more common paths. Otherwise it's just a free for all, and quite honestly that's where I think the installer has been headed. It's not being given that much opportunity since newui to stabilize because new stuff keeps getting added. So I think a triage mentality needs to take over even before the context is Fedora.next let alone if Fedora.next decides a higher bar. The hard part, IMO, is figuring out what 'common configurations' should be included with the installer. I would imagine the answer to this is going to be different for each of the WG products. I wouldn't be surprised if going forward we end up with multiple installers (at some point down the line) - or multiple versions of anaconda. We probably should have *one* file system option for Guided partitioning, which is the recommended layout, and the user gets to choose a couple of variations: encryption, and a way to reuse an existing /home. Based on the last discussion on anaconda-devel, I'm not sure we can get down to one, but I think there is some leeway for cutting it down from four. This definitely needs to be proposed to the anaconda devs, though. I would be in favor of at least cutting it down from the current set. I think there's inherent value in the project saying this is the layout we recommend wen it comes to the guided path. It's not much of a guide to have four massively different partition schemes: one of which was a surprising new comer that didn't work at all up until beta and then imploded at the last second before ship. One of which at the time was still labeled experimental in the kernel, but that status wasn't revealed to the user, they had to go read tea leaves or visit the water cooler in the 5th floor stair well to know that. So I'd push for one and maybe we get two. *shrug* I'm well aware that suggesting greater conservatism on the guided path very well might mean Btrfs gets booted, even though I'd pick it as easier to learn and manage than
Re: rfc: expectations for partitioning, Fedora.next
On Feb 21, 2014, at 12:46 PM, Mike Ruckman ro...@fedoraproject.org wrote: The hard part, IMO, is figuring out what 'common configurations' should be included with the installer. I think the hard part is having the guts to make a subjective, yet reasonably well informed decision, and just stick to it. Harder for some than others is ignoring the peripheral squawking that ensues, but is easier when reminded that 99% of those people aren't the intended target market for this path. The ideological decision, is that there should be no partition scheme option. Not which one should be chosen. If I bemoan Btrfs vanishing from the Automatic/guided path partition scheme pop-up, give me an egg and tell me to suck it. Seriously. I would imagine the answer to this is going to be different for each of the WG products. I wouldn't be surprised if going forward we end up with multiple installers (at some point down the line) - or multiple versions of anaconda. I go in the other direction. Chop out everything that causes the installer to be customizable by product, and instead have a post-install interface that flavors the base install as a particular product and downloads whatever else is necessary to achieve that. What is in common for Server and Workstation? They have to boot, and startup to a working prompt or gdm. That's all the installer needs to do to be successful. Goose. Gander. Good. I think we shoot ourselves in both feet by creating derivatives of the installer. Maybe it's realistic to have each product decide what, if anything, is hidden. But we are only talking about two products. The Cloud product will have images, installer isn't applicable. Even then, if we were able to trim the installation options to one or two options, those options aren't going to be the same across WGs. Heavens to Betsy we might have to have FESCo host an arm wrestle! I'd pay for that if we add mud. Server folks might want XFS, to be in parity with RHEL 7. I don't know why that would bother Workstation folks, XFS is just fine for that use case too. I'd say Workstation should do what Server does, unless all outstanding Btrfs concerns and questions are fully and satisfactorily addressed by the flip date. For Manual/custom path it needs some more consideration but I'd say no Server or Workstation derivatives. Rename it Advanced Partitioning (or Advanced Storage Configuration since it really isn't about partitioning as much as oldui). And then we see how realistic and helpful it is to hide certain features. The challenge there it's not any one particular tick box that makes it hard, it's when used in combination that things get complicated. Example, for rootfs I'd say do not expose raid 4 or 6. Maybe even don't expose raid 5 at this default reveal level for rootfs, only for /home. That sort of thing. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rfc: expectations for partitioning, Fedora.next
On Fri, 2014-02-21 at 14:47 -0700, Chris Murphy wrote: What is in common for Server and Workstation? They have to boot, and startup to a working prompt or gdm. That's all the installer needs to do to be successful. Goose. Gander. Good. I think we shoot ourselves in both feet by creating derivatives of the installer. Maybe it's realistic to have each product decide what, if anything, is hidden. But we are only talking about two products. The Cloud product will have images, installer isn't applicable. Even then, if we were able to trim the installation options to one or two options, those options aren't going to be the same across WGs. Heavens to Betsy we might have to have FESCo host an arm wrestle! I'd pay for that if we add mud. Server folks might want XFS, to be in parity with RHEL 7. I don't know why that would bother Workstation folks, XFS is just fine for that use case too. I'd say Workstation should do what Server does, unless all outstanding Btrfs concerns and questions are fully and satisfactorily addressed by the flip date. For Manual/custom path it needs some more consideration but I'd say no Server or Workstation derivatives. Rename it Advanced Partitioning (or Advanced Storage Configuration since it really isn't about partitioning as much as oldui). And then we see how realistic and helpful it is to hide certain features. The challenge there it's not any one particular tick box that makes it hard, it's when used in combination that things get complicated. Example, for rootfs I'd say do not expose raid 4 or 6. Maybe even don't expose raid 5 at this default reveal level for rootfs, only for /home. That sort of thing. I think just chewing the cud about this on test@ is kind of pointless at this point; we're all aware of the issues and the general goal of 'make it simpler'. I think we need to be talking to other teams about it. See the message I just cross-posted to a bunch of lists with the topic [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs. -- 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: rfc: expectations for partitioning, Fedora.next
On Fri, 21 Feb 2014 14:47:45 -0700 Chris Murphy li...@colorremedies.com wrote: On Feb 21, 2014, at 12:46 PM, Mike Ruckman ro...@fedoraproject.org wrote: The hard part, IMO, is figuring out what 'common configurations' should be included with the installer. I think the hard part is having the guts to make a subjective, yet reasonably well informed decision, and just stick to it. Harder for some than others is ignoring the peripheral squawking that ensues, but is easier when reminded that 99% of those people aren't the intended target market for this path. The ideological decision, is that there should be no partition scheme option. Not which one should be chosen. If I bemoan Btrfs vanishing from the Automatic/guided path partition scheme pop-up, give me an egg and tell me to suck it. Seriously. I agree with you. The ideological decision is easy - I was just pointing out that using terms like 'common configuration' leads to this kind of 'what gets included when?' decision tree. I don't have any hard opinions on how things 'should' be - I'm no expert in this arena. I would imagine the answer to this is going to be different for each of the WG products. I wouldn't be surprised if going forward we end up with multiple installers (at some point down the line) - or multiple versions of anaconda. I go in the other direction. Chop out everything that causes the installer to be customizable by product, and instead have a post-install interface that flavors the base install as a particular product and downloads whatever else is necessary to achieve that. What is in common for Server and Workstation? They have to boot, and startup to a working prompt or gdm. That's all the installer needs to do to be successful. Goose. Gander. Good. I think we shoot ourselves in both feet by creating derivatives of the installer. Maybe it's realistic to have each product decide what, if anything, is hidden. But we are only talking about two products. The Cloud product will have images, installer isn't applicable. That sounds reasonable to me. I don't like the idea of deviating from one installer - and I would argue against it if proposed. However, I can see all too easily people wanting to. Chris Murphy signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rfc: expectations for partitioning, Fedora.next
On Fri, 21 Feb 2014 13:56:41 -0800 Adam Williamson awill...@redhat.com wrote: I think just chewing the cud about this on test@ is kind of pointless at this point; we're all aware of the issues and the general goal of 'make it simpler'. I think we need to be talking to other teams about it. See the message I just cross-posted to a bunch of lists with the topic [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs. Makes sense to me. // Roshi signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
