Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[foser]

On Sun, 2003-09-28 at 20:14, Paul de Vrieze wrote:
> That the original is what is original. People want the original, but might not
> know which one is. I think a useflag makes sense as long as it is global, not
> local.

Well, actually there is not one original. GDM comes with two themes
vanilla, we add one. The choice of one over the other is an esthetical
one. And as said, by default the graphical greeter is disabled, so the
discussion should not be focused on what theme we provide by default,
but if we should enable the graphical greeter by default or not.

> > Why do you have a problem with the theme while the default package
> > doesn't even enable the graphical greeter or is that a problem too or is
> > this just meant to pick a gnome change we once made ? Do you dislike the
> > splash we used as well, is it really that intrusive ?
> >
> Know, I like it, certainly. I actually use it and prefer it over kdm, but
> there are cases where one ones the original packages. If you have ever seen a
> standard redhat 9.0 gnome install you know why. As someone who hardly uses
> gnome I have no clue whatsoever to set that back into the default settings.

We are not RedHat, we don't do that. I see these changes as
non-intrusive, if someone disagrees and has a good point about it I'm
willing to remove them. But in this case i don't think someone would
prefer one of the default themes over the Gentoo theme. A lot of people
seem to like a little branding, have you ever thought about our
'default' grub splash ? Do you think that would need a USE flag too ? I
would not easily make changes that go beyond these and are not easily
adaptable. You can shutdown from GDM, then you know how to configure it
: it's in the same menu.

> What is a change in behaviour? While I agree on having things go upstream
> there are cases when the updated behaviour is not available upstream (yet),
> but still desirable in the distribution. In such cases there is the option of
> providing this enhanced behaviour, but allowing users to either enable or
> disable it.
>  An example would be the gentoo menu system. Such a system is so
> interrelated between many applications that it will take a very long time for
> such a thing to be put through upstream that it is viable to do it ourselves.
> It does change behaviour though, and as we offer choice it should be possible
> to not apply the patches to the windowmanager that allow it to happen, even
> if they default to standard behaviour.

Let's not go into individual cases, there's always the odd one out. But
the Gentoo menu system in it's _proposed_ implementation would need it's
own flag, not some general flag. So that's 2 flags for non-default
behaviour already, good start, let's add some more.

If the final proposed menu implementation is good enough (and i think it
can be although not in it's current form) then i even doubt it would
need a USE flag. Again transparency : the menu system should blend in so
well the difference between having it and not having it is negligible.

> Certainly I don't like those questionable patches, however in less havilly
> used packages than kde and gnome there are often patches that greatly enhance
> the behaviour of the package and might make it upstream (however upstream is
> not well maintained), but are stable and valuable enough to allready include
> now instead of waiting another half year for the new version (or go with a
> cvs version)

This is what i mean with the blurb about go into upstream CVS in the
foreseeable future. To stay with the examples we used : the gnome
dropshadow patch will not make it into CVS as it is, if ever. Certainly
not as long there's no proper X support for features like transparency.

Useful patches can go in, but something which won't make it in and is
unmaintainable on our side should not go in. If i start adding all sorts
of fancy patches here and there i really sound would have regression
with breaking patches i can't repair. This is partially due to how
Gentoo is managed, relatively few developers and a lot of packages. Not
like eg. Debian where every package has often one (or more) dedicated
maintainer(s) or Redhat where they have people work fulltime, so being
able to do much more work on packages.

It's the herds lead/developers that should assess what patch is viable
to have in and what not, that comes down to common sense. But i think we
should be very careful with adding intrusive patches which change
behaviour considerably.

> > Now we have different cases that need one flag, but some people might
> > argue that some special cases need another flag and next thing you know
> > we have a dozen flags for customizations that are non-intrusive, for
> > providing mandrake like total rewritten fool-proof config files and what
> > not.
> >
> I think we need a policy, but some packages allready do things that could be
> argued to be not vanilla enough, but still are very valuable.

Policy here, policy there. Policy is all good, but in the end it comes
down to a bit of common sense. I know some developers feel more
confident with a few (or a lot) written down rules backing them up, I
just argue a case over with myself and a few other (involved) devs if
needed. I can justify the things i do to myself and if someone disagrees
they can discuss it with me and we can work it out. I can of course be
wrong at times, but that's human. 

If packages do things that can be argued, then they should be argued.
Mistakes made in the past can be corrected, that's not a reason to make
a policy for these cases.

> > We need no flag, it is simple : if the change can't be justified for all
> > users, it shouldn't go in.
> >
> > And i don't think a little non-intrusive branding needs a flag and i
> > call it justified as a means of showing one is using the Gentoo distro,
> > but if you disagree we could maybe drop the GDM theme for the sake of
> > it. On the other hand you are the first to have a problem with it, most
> > people really liked it.
> >
>
> I like it, it was an example. I have no problem whith it whatsoever. However,
> gentoo is about choice. That includes the choice not to have patches that do
> more than fix bugs.

I think Gentoo is about power, power to have a distribution without
fuzz, packages as upstream developers intended them to be. The power of
Gentoo lies in the ease way you can adapt it to your needs. Ebuilds are
not black magic, whoever needs to manipulate them can do so.

I keep repeating myself here, but i really think holding hands like some
other distros do is not needed. The defaults should be good enough for
the majority of users, the ones who need more (and know so) i deem smart
enough to manipulate ebuilds to their needs. Holding hands is insulting
the intelligence of our users.

- foser


--
gentoo-dev@g.o mailing list