if we were to vote on every single change we would never get any work done. this is not important enough for a vote.

and, if you think everything should be up for a vote, what is the point in having a design team, or fesco, or even the board? the simple answer is having every fedora contributor to vote on every decision is not ralistic and counter-productive.

sent from a mobile device so please excuse spelling mistakes.

On Jun 20, 2012 11:28 PM, "Dan Mashal" <dan.mashal@gmail.com> wrote:

Then maybe we should have a vote on it just like we did with release names? Maybe we should do more voting on more major changes? Maybe we should make it a full democracy instead of the engineering team decides is "better for the novice user" when they don't even communicate with the novice user.

Dan

On Jun 20, 2012 1:12 PM, "Elad Alfassa" <elad@fedoraproject.org> wrote:

I do not like this approach, way too much clutter.

On Wed, Jun 20, 2012 at 11:11 PM, Dan Mashal <dan.mashal@gmail.com> wrote:

However, keep one thing in mind. It already automagically selects the lates Fedora kernel without user intervention, Martin. ;)

On Jun 20, 2012 12:39 PM, "Martin Sourada" <martin.sourada@gmail.com> wrote:

On Wed, 20 Jun 2012 08:03:35 -0700
Kirk Bridger wrote:

>
> Perhaps we can put some additional solution ideas forward.
>
> As a quasi-novice kernel user I always found it helpful to have the
> kernel versions visible.  When I update Fedora and the nvidia blob
> causes X to fail, I like being able to choose older versions because
> I can't do anything else.  When a pre-upgrade ends up with a
> non-working version, I like to be able to run an older version to
> stay productive while I research the problem.
>
> I'm not an expert user but I don't think I'm novice either.  I don't
> see why we need to *hide* the older versions behind another menu,
> just perhaps make it more clear that the old versions are still
> functional but are not the latest on the machine.
>
> Novice users have the "out" of saying "I don't know what this all
> means but I know I want to launch the most current version".  And if
> they're dropped back here after a failure or two trying the current
> version they can try the older versions.
>
> This all assumes that we're limited to the current console-style
> menu. If we can use HTML/CSS or some other layout and styling we can
> make this info much more parse-able with styling and different font
> sizes/layout. If we can do more than just console can someone send a
> screenshot of what we can do, and maybe we can mock something up?
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Welcome to Fedora 17 (BeefyMiracle)
>
> *Current Versions*
> Fedora 17 (kernel-3.6.0-1.fc17)
> *
> Superceded Versions*
> Fedora 17 (kernel-3.5.20-3.fc17)
> Fedora 17 (kernel-3.5.20-2.fc17)
> Fedora 16 (kernel-3.2.10-4.fc16)
>
> *Other Operating Systems*
> Microsoft Windows 7
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
IMHO not a bad idea. I have a few notes though:
 * Fedora 16 and Fedora 17 should be considered separate operating
  systems (*if* they use different root).
 * Boot loader should behave look like boot-loader not like an already
  running operating system (the "Welcome to Fedora 17" text is
  misleading)
 * Why have Fedora stylistically higher priority than other operating
  systems?

IMHO, there are multiple different types of users, who use fedora,
let's divide them into few different groups.

1. Dual booters -- Fedora and Windows (or Mac)
==============================================
These people probably just want to boot the latest version unless
something is broken. They might or might not know what the kernel
versions mean. It might be better to "hide" older kernels in submenu
(or if grub2 allows some better css-like way, why not?)

2. *nix enthusiasts/developers -- multi-booters
==============================================
These people will probably have multiple operating systems installed,
maybe even various versions of fedora. Let's say they have (for example)
Fedora Rawhide, Fedora 17, Debian 6.0, FreeBSD 9 and Arch Linux. They
know very well what kernel is, but if all installed kernels are listed
there, the list gets rather large and it gets hard to quickly find the
latest kernel. Especially for the two Fedoras that you can tell apart
only by the fc18 vs. fc17 in kernel release number... While it would
make selecting *older* kernel versions slower, I think it would be
better to *hide* the older kernels in submenu, thus making the main
menu easier to navigate. IMHO the gain of quicker selection of most
recent kernel for each release would outweigh the less frequent slow
down introduced by submenus.

3. Massive virtualization
=========================
These people have only one host operating system, the rest is in
virtual machines. IMHO they are the only group that would *not* benefit
from switch to sub-menus.

IMHO, the gains to the first two groups outweigh the loss of the third
group, but well, others might disagree. That's why we discuss things,
right?

So how would the bootloader screen would look like?

----------------------------------------------------
               Welcome to GRUB 2
             Select an OS to boot:

* Fedora Rawhide (with linux-3.6.0-23.fc18)
* Fedora 17 (with linux-3.6.0-23.fc17)
* Debian 6.0 (with linux-2.6.28.3-23)
* Microsoft Windows 7
      --------
* Fedora Rawhide (Rescue)
 - older kernels listed in this submenu, and possibly some special
  rescue mode(s)
* Fedora 17 (Rescue)
 - older kernels listed in this submenu, and possibly some special
  rescue mode(s)
* Debian 6.0 (Rescue)
 - older kernels listed in this submenu, and possibly some special
  rescue mode(s)
* Microsoft Windows 7
 - if we can only chainload win 7, this would not make sense, however
  if we could run rescue modes for win from grub, this where it would
  be.

----------------------------------------------------


THanks,
Martin
_______________________________________________
design-team mailing list
design-team@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/design-team

_______________________________________________
design-team mailing list
design-team@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/design-team

--

-Elad Alfassa.

_______________________________________________
design-team mailing list
design-team@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/design-team

_______________________________________________
design-team mailing list
design-team@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/design-team

_______________________________________________
design-team mailing list
design-team@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/design-team