On 7/15/05, Andy Green <andy@xxxxxxxxxxx> wrote: > They understand that RHAT has some flexibility > in terms of overrides (patches) of upstream providers. And when they bring it up with regard to gnome desktop functionality, they are repeatedly told to move discussion upstream. The issue isn't that people, start the discussion here.. the issue is people (people who know better) refuse to move the discussion upstream once they are told it would be more effective to discuss this upstream. As the move from bluecurve to clearlooks illustrates there appears to be a concerted effort by the gnome maintainers to move closer to upstream not to further pull away from it. > Although I don't use Gnome as a desktop, I use enough Gnome apps to be > constantly reminded of the ineffective choices (Ctrl-L... if you can > magically find out about it -- it's not on the dialog -- then make > coffee while it tries to populate /usr/bin) foisted on folks via File > Open dialogs for example. It seems to me there is a genuine problem > with the trend of Gnome development and the use of changing defaults to > try to program their users. They could be more modest and provide > compatability with conventional expectations as the default, and a > simple choice into the new methods. If the new methods rock, they will > be taken up by word of mouth and become default by demand. All of this, are comments on gnome's process for introducing and laying out features. Without making a judgement as to whether or not your concerns are valid, these would be more effectively expressed as part of upstream gnome discussions or in the case of the keyboard shortcuts, rfes into upstream bugzilla. > Well despite taking your point that upstream has more power over the > direction of upstream, some care needs to be taken not to blow off > genuine observations. The power of RHAT to patch its desires into > reality is real, as we see in the kernel. No one has blown off the observations with regard to the specific issue of terminal menu item. Clark chimed in very early on with upstream information concerning how the terminal menu item is being re-implemented as an addon. People took that information and are now starting the packaging of that addon for Extras. But this thread degraded into general comments about how gnome is making upstream decisions, about how gnome has become a "social experiement" on users. Even YOU just now decided it was worthwhile to make a comment about how upstream gnome is changing defaults and how you think they should be doing it. These sorts of comments don't need to be discussed here.. in fact they will get lost in the noise and never make it back to gnome. To quote you again: "It seems to me there is a genuine problem with the trend of Gnome development and the use of changing defaults to try to program their users." In no way shape or form is a comment about the "trend of gnome development" worthwhile to discuss in fedora-devel. Comments like these only serve to frustrate list participants, because comments about the general trends in gnome development made in this list are not going to lead to any changes into how gnome does things. If you want to make a comment about "general trends" of ANY upstream project.. take it to the upstream project. > Well despite taking your point that upstream has more power over the > direction of upstream, some care needs to be taken not to blow off > genuine observations. The power of RHAT to patch its desires into > reality is real, as we see in the kernel. Its a huge logical fallacy to hold up what goes on with kernel development as an example of whats going on with desktop application development... inside redhat or even upstream. What the fedora kernel people think is appropriate in terms of patching the kernel.. is immaterial to what the desktop people think is appropriate in terms of patching gnome functionality. There are no parallels nor conclusions worth drawing in that comparison. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
