| 1 |
On Thu, 2003-08-28 at 14:52, dams@×××.fr wrote: |
| 2 |
|
| 3 |
> Maybe add a vanilla flags, that can be unset. When unset, the DE are |
| 4 |
> preconfigured and gentoo touched. |
| 5 |
> The pb is that you want vanilla, but you want also some core feature like |
| 6 |
> centralized menu system, which is not compatible. So either we decide not to |
| 7 |
> include such features, or to have a flag. |
| 8 |
|
| 9 |
I'm quite against this, there should be one Gentoo to rule them all. I'm |
| 10 |
not against adding some extra patches, as long as they add clear |
| 11 |
functionality we can maintain (this is most important). No need for |
| 12 |
flags for vanilla and not so vanilla. |
| 13 |
|
| 14 |
The menu system is a difficult one i know, but in reality there are few |
| 15 |
people who use more than one DE. We cater the masses well at the moment, |
| 16 |
those who want to work with a different look 'n feel every day should be |
| 17 |
able to handle the downsides. |
| 18 |
|
| 19 |
The proposed implementation i have seen i dislike for several reasons, |
| 20 |
but mostly because of the reasons i stated down here in my last mail |
| 21 |
(compliance part). I think other possible solutions may be a lot more |
| 22 |
workable and should be investigated first. But these are details, this |
| 23 |
isn't the place to discuss this. |
| 24 |
|
| 25 |
> >> - write guidelines to be more (free)desktop compliant, to be used by the whole |
| 26 |
> >> gentoo devs for their packages. |
| 27 |
> > |
| 28 |
> > We shouldn't be compliant, we should push upstream developers to be or |
| 29 |
> > work on their packages being compliant. Us providing some hackish layer |
| 30 |
> > of compliance is a recipe for disaster. It is fighting symptoms, while |
| 31 |
> > you should be attacking the problem by its root. I don't see our already |
| 32 |
> > heavily pressured teams do all sorts of compliance work. |
| 33 |
> > |
| 34 |
> > And no, just hiring a few more people is no solution if you want to have |
| 35 |
> > the same quality/involvement. |
| 36 |
> |
| 37 |
> That's a possibility, but that means that, as a linux distribution, we don't |
| 38 |
> provide additional compliance. If you keep the desktop vanilla, we don't either |
| 39 |
> provide additional desktop default. That can be what we want. But what will |
| 40 |
> provide gentoo linux, as desktop, then? |
| 41 |
|
| 42 |
We provide the power to work with the desktop as intended upstream. The |
| 43 |
GNOME Desktop is an idea as a whole, we provide it as it is. And for say |
| 44 |
corporate users you could say they could easily adapt their installs to |
| 45 |
their needs, without the necessity to hack out all sorts of distro |
| 46 |
specific stuff. Or for granny's email machine (installed by her |
| 47 |
son-in-law) she just get what she needs and not all sorts of extra cruft |
| 48 |
(no granny doesn't need no CD burn tools or LDAP support in her mailer). |
| 49 |
|
| 50 |
> I think a perfect corporate desktop would : |
| 51 |
> |
| 52 |
> - be cheap |
| 53 |
> - be installable by not so good technical guys quickly |
| 54 |
> - be useable at soon as it is installed |
| 55 |
|
| 56 |
'emerge gnome' and maybe in the future (but we lack time as it is) |
| 57 |
'emerge gnome-office' and off you go. I suppose KDE could create similar |
| 58 |
meta ebuilds. |
| 59 |
|
| 60 |
> |
| 61 |
> Now if the guy has to configure each workstation, it's not very convenient... |
| 62 |
|
| 63 |
Humm, that wouldn't be a bright guy. It would be better to work from one |
| 64 |
'image' machine in a workstation situation. I don't really see how you |
| 65 |
mean configuration beyond that. User configuration is ok by default |
| 66 |
mostly (at least for GNOME) and it is up to them to alter it to their |
| 67 |
preference. |
| 68 |
|
| 69 |
- foser |
| 70 |
|
| 71 |
|
| 72 |
-- |
| 73 |
gentoo-dev@g.o mailing list |
Archives