GRUB menu hidden by default?

[Adam Williamson]

On Fri, 2013-01-04 at 23:29 +0100, Miloslav Trmač wrote:
> On Fri, Jan 4, 2013 at 11:20 PM, Adam Williamson <awilliam at redhat.com> wrote:
> > Apart from all the bullshit about cars, which part of "it's part of
> > upstream grub2" are you people not understanding? This is not our code.
> > This is how grub2-mkconfig works. We are not going to get into the game
> > of patching bootloader behaviour downstream again. You don't want grub2
> > to generate nested menus by default, you can go upstream and argue with
> > the grub developers. Please keep this crap out of Fedora lists.
> 
> Not that I care about the details of grub2 - still I don't understand
> the above reasoning.  If an user-visible aspect of the user experience
> is "not our code" and doesn't belong on these lists, what _does_
> belong on Fedora-devel?  After all there is a separate mailing list
> even for Anaconda.

Well, let's look at the recent threads:

"Results of a test mass rebuild of rawhide/x86_64 with
gcc-4.8.0-0.1.fc19"

Hey look, that's about building the distribution. So, 'devel'oping
'fedora'. Seems relevant!

"perl-podlators-2.5.0 in F19"

notification of a change for dependent package builds: relevant!

"Please review vdr-vnsiserver - VDR plugin to handle XBMC clients via
VNSI"

request for a package review: relevant!

It's not like we're short of appropriate discussions.

> And if we are not supposed to patch code shipped by upstreams, what
> good can Fedora do at all?

We provide upstream code in a unified set of repositories, tested to
interact properly. Did I say that we're not supposed to patch code
shipped by upstream? No. What I said - or rather, the belief my
statement was based on, because this isn't exactly what I said - is that
we don't generally carry permanent long-term downstream patches just to
change upstream behaviour that we disagree with. This is a bad thing to
do.

Here's what our policies say:

https://fedoraproject.org/wiki/Packaging:Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment

"All patches should have an upstream bug link or comment

All patches in Fedora spec files SHOULD have a comment above them about
their upstream status. Any time you create a patch, it is best practice
to file it in an upstream bug tracker, and include a link to that in the
comment above the patch."

This is based on (and links to)
https://fedoraproject.org/wiki/Staying_close_to_upstream_projects :

"The Fedora Project focuses, as much as possible, on not deviating from
upstream in the software it includes in the repository. The following
guidelines are a general set of best practices, and provide reasons why
this is a good idea, tips for sending your patches upstream, and
potential exceptions Fedora might make. The primary goal is to share the
benefits of a common codebase for end users and developers while
simultaneously reducing unnecessary maintenance efforts."

i.e., we try to avoid carrying patches permanently downstream, except in
cases where we obviously have to patch something which it would not be
appropriate to upstream (say, adding a Fedora logo to the login screen,
or something).

> (I can perhaps see a case for "we are not going to significantly
> diverge from bootloader's upstream again", as a way to avoid repeating
> the grub1 semi-fork.  However applying it to the configuration of the
> bootloader is a stretch.)
>     Mirek

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net