Now that GNOME 2.14 is almost out I would like to propose an overarching goal for GNOME 2.16. Codenames that reflect this goal are:
GNOME 2.16: No New Features.
or
GNOME 2.16: Polish, polish, polish.
Yes, you heard me. I would like to see six months of GNOME development love going in to fixing bugs and improving the GNOME infrastructure in terms of documentation and web sites. I know that would be boring for many of you, but please: think of the children! Ooops, I mean users.
By "Bug Fixing" I mean not only clearing things out of bugzilla, but also attending to the things that are often talked about as being in need of improvement. I am willing to help where I can. Please bear in mind that I am not a developer, but apart from that, feel free to approach me with tasks. I don't want to be just a complainer ;-)
I was impressed by a comment made at GNOME.conf.au in Dunedin recently. Someone mentioned the how the policy in New York City of "Zero Tolerance" to crime worked so well. Apparently the story is that if even the smallest of crimes (like littering and jaywalking) are not tolerated, there is a corresponding fall in the crime rate for the more major crimes. The reasoning behind this is (IIRC) explained in the book "The Tipping Point".) Please, if I'm getting these details wrong, let me know.)
I am reminded of the situation with TeX, and also LaTeX: there are practically no bugs in these packages. We can argue about why this is, or whether it is possible for GNOME to emulate the acheivements of Donald Knuth, but the point remains that bug-free software is possible, and that feeping creaturism must be resisted.
I, and almost all of my normal user buddies, HATE new features almost as much as we hate bugs. (OK, that's an exaggeration.) But honestly, whenever we hear that our versions of Windows, Office or whatever is going to be upgraded, we groan. Because amongst all the new features there is almost never anything actually useful, and all we get are new bugs. Often we have to learn new ways of doing things that don't seem any better than the existing ways. And most of the old bugs don't go away either. The "upgrade" cycle seems to be driven by the IT department needing new central management functionality rather than the actual users demanding new features.
Adding new features to software is largely driven by commercial imperatives, where common business wisdom goes along the lines of "constant innovation is not just the key for success, but a necessity for survival". We in the GNOME community do not have these imperatives.
Adding features is necessary (as opposed to fun) only when we have a desire to produce a system that is a replacement for other systems. (Getting people to start using GNOME in place of something else.) In that case it is necessary to match a large subset, but by no means all, of the system that you are trying to replace. If we are talking GNOME and GNU/Linux versus Windows XP and Mac OS X, there are a few major areas to achieve parity:
1. Multimedia handling
2. Printing
3. Laptop support
Wouldn't it be great if you could buy a new laptop, pop a CD of the latest version of you favourite distro in the drive and install the sucker with no more hassle than if you were trying to install one of the other systems? (Note I am not saying "with no hassle"!)
And then, imagine you could use your laptop without feeling like a second class citizen in the computing world, because your system can't read/play certain files or plug in to the local corporate infrastructure. Wouldn't that be great?
How much of this simply can't be done because hardware and software manufacturers will not let GNU/Linux and GNOME hackers have access to the relevant information? How much of it could be acheived by simply setting it as a goal? I do not pretend to have these answers.
Having re-read this article before posting I realise that I have been ranting. (Actually, I knew that as I was writing it.) I am hesitant to publish this rant, but I will; if only to find out if anyone shares my pain ;-)
Oh, and before I forget:
THANKS!
Thanks to all you GNOME hackers for making a really good GUI for GNU/Linux (and others). A really good desktop environment that has the potential to be great. If it was crap I would just switch to KDE :-)
Love,
John
Subscribe to:
Post Comments (Atom)
Posts
35 comments:
You are indeed true but it seems that Gnome is more or less following this path since 2.10.
No major breakthrought (my mom doesn't notice upgrade, that why I can say that) but a lot of polish every release.
IMHO, there's a lot of things that sucks and that need this improvment :
- Wifi handling. (that really sucks ATM)
- Performance, performance, performance
- Less ram, less ram, less ram
- Evolution
and all things you said in your previous posts
100% agree John. "No new features" would be a great marketing campaign. I'm being serious here, this is a really great idea. One other place that some attention could be placed would be memory usage.
Imagine how great a Gnome release would be that used half the memory of the previous, with less bugs. Wow.
>How much of this simply can't be done because hardware and software manufacturers will not let GNU/Linux and GNOME hackers have access to the relevant information?
Not much. Situation for WLAN might be improved well if there were more specs out there but thats it ( almost ).
Developing drivers for hardware takes up a lot of resources, as long as you are not the vendor: You simply need the hardware. The main issue is that product iteration cycles are too short to allow external developers to follow.
Take a printer: It takes months to write a good working driver for a printer but after months, the next model is already at the start. For the vendor, this is not an issue since the vendor can write the driver while developing the device. For a third party developer, you only shot on a moving target.
Take laptops: One of the main issues with laptops is that wrong ACPI tables are provided which cause linux to fail on this laptop ( or to fail to enter suspend etc ). For the vendor, this is not an issue since they can workaround all these bugs in the drivers for the device during development cycle. For third-party developers this is virtually impossible.
Point is: For any device that does not follow some standard ( like Postscript for printers ), developing up-to-date drivers is virtually only possible for vendors.
Oh, I forgot regarding "No new features": We all want XGL niceties in 2.16 ( at least ), don't we? ;-)
Totally agree on this... Tired of never having apps 99% stable. When a bug is corrected, another feature comes and breaks it all... That's the main problem over Windows I think. You want that app, upgrade your whole distro if no backport is available... That app then works better but another one is broken... sic...
I think the first app that should be given love on memory reduction and performance improvement is nautilus. After all, it's an app most users *must* use. However, there's ATM 1024 bugs for this product in bugzilla...
Evolution is pretty close, too.
We really need to get some polish on the desktop, and maybe the 6 months cycle is too short for this...
Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes!
Christian Sasso (GNOME fan)
Go for polish! And maybe only polish the user experience of the window handling and so... For me as a macosx user - and former gnome user - it's hard to come back to gnome...
What about a convenience pack for gnome that emulates the handling of a macosx or windows xp gui, from a shortcut point of view.
Or... maybe that is left for the distributions?!
Memory + performance!!
I have to use a dual boot system, and while I love GNOME, it scares me how much faster my WinXP feels. Admittedly it is a very basic XP setup (just the Office and some tools), but the point is that the desktop as a whole feels more responsive. When I switch to Ubuntu, the difference is noticeable, especially in long work sessions.
Featurewise I'm more than happy with what GNOME offers me, for me the biggest step forward would be performance.
Thanks to all developers, in any case, for the amazing work!! Looking forward to the future!
Actually I think it should something like "monsterhunt", errr..."big bughunt of gnome fields" :)
But if seriously, my view it's what's happening now with GNOME - big big stabilisation and tweaking and polishing. As far as I have seen. Lot of apps are getting very matured - pure example are Sound Juicer, finally Rhythmbox takes shape and are stable somehow (lot of bugs still to fix).
I also agree that there is HUGE work for underlayers like printing, scanning, sound (kudos to GST team, they working in right direction), search (current search applet works, but feels very outdated, waiting for beagle/other fun). They are actually NO new features, only replacements for old ones. For example, finally GNOME sound mixer looks really usable. Also priting dialogs got some tweakage.
I think we should start thinking about GNOME 3.0 - and it should be not full rewrite, but let's take those things who works now, let's rewrite those things who clearly doesn't work (hi, gnome session management), and rethink UI - for example, is Novell provided new variant of panel is good, or not so good. What can be taken, or not.
I would vote for such schema:
* GNOME 2.x series - left for polish, tweaks, and drop-in replacements which doesn't change or worsen system behaviour.
* GNOME "New world order" series - development series, which could be used by developers, fans and testers. It could be a testbed for radical UI changes, rewrites of subsystems, etc.
I have tevoted myself to bughunt, as I am not advanced developer as I would like to be. Join the revolution!
1. You assume wrongly that all effort that goes into new features could be diverted into bug-fixing. But hacking is rarely a commodity. Man-months are mythical. So you'd often be telling people "No, we don't want your help".
2. Distros want to add features, usually because new sets of features fix large long-standing bugs. "I can't print" is a bug as much as a lack of features. You'd have to persuade distros of this strategy.
The current release process accepts that both features and bug-fixing happen, and tries not to let things get unstable while that's happening.
But when something should be a priority it should be given more time in the schedule. For instance, Ubuntu Dapper's time-based release-process has an early feature-freeze and a long bug-fixing time after that, as part of an overall longer-than-normal schedule.
Murray
I vote for "GNOME 2.16: Polish, polish, polish." :)
Apparently the story is that if even the smallest of crimes (like littering and jaywalking) are not tolerated, there is a corresponding fall in the crime rate for the more major crimes.
That's the theory, that implementing "broken windows" policing lowered the crime rate.
The facts, best as I can tell, are different. First, the crime rate lowered because New York City drastically increased the number of police on the street. This is discussed in Freakonomics: http://www.amazon.com/gp/product/006073132X/sr=1-1/qid=1139408847/ref=pd_bbs_1/002-4865496-5184060?%5Fencoding=UTF8
The second reason crime has lowered is due to "a shift in police tactics":
he N.Y.P.D. has a computerized map showing, in real time, precisely where serious crimes are being reported, and at any moment the map typically shows a few dozen constantly shifting high-crime hot spots, some as small as two or three blocks square. ... “We took two-thirds of our graduating class and linked them with experienced officers, and focussed on those areas,” Kelly said. “Well, what has happened is that over time we have averaged about a thirty-five-per-cent crime reduction in impact zones.”
See: http://www.newyorker.com/fact/content/articles/060206fa_fact
Following a "No new features" policy seems very difficult. As a developer I really think it is boring to see something missing, have it ready and waiting 6 months until I can get that in the main tree, and another 6 months until release.
Seriously, that can kill a project. I find it frustating enough when I don't get something included in the very next release because the project is freezed 3 months before a release!
What I think we should do is to have more "Bug days" and a Bug squad. Experience tells me that there is very little support to newbies, and if there were some Bug squad committed to help those newbies to learn GNOME internals fixing bugs, that would be enough. Those people could "sit close" to the newbie and show newbies the path, even if the bug was as easy as 123, that would show some respect, support and incentivate those newbies.
Of course, in the path we would get more workforce and lots of bugs fixed.
I quote arne on the XGL side ;)
http://kugghiuns.altervista.org/xoen_blog/2006/02/07/mac-os-x-we-are-coming-soon/
The "no new features" maybe is too because I think almost all like new features, and new features are a good way of marketing.
I think "more users" is better, we must try to take users from windows and the tipical windows user likes eye candy ;)
The "No bugs in my GNOME" is a good policy, but a) You said there is no sosftware without bug ;) b) The maintenance releases are done for this purpose, and it work.
For example, I _LOVE_ GNOME and I like to test the lastest version, and I do this on my desktop computer, but I also have a laptop and on this I have GNOME 2.12 ...
I think GNOME is fast, but I think also it can be faster and lighter.
So the "ultimate GNOME 2.16 goal IMHO" (TM) is "Faster, lighter, and even cooler" ;)
Does GNOME depend on esound? I think GStreamer should be more integrated into GNOME
I think that part of the solution involves forcing Miguel, Nat and Havoc to actually use what they code and nothing else. This would, among other thing, involve locking their desktop down and forever forcing them to use nothing but Evolution as their MUA.
i wanted to refute the ny crime prevention stategy, but the other anonymous came first. crime in ny didn't go down more than in other citys that only got more police without the strategy of penalizing chewing gum on the streets.
the numbers aren't lying.
IME, we dread Windows and Office upgrades, but look forward to most of the rest. Most Mac users watch Steve at the keynote and say "wow, sweet feature -- I want that now". And then when they have it, they wonder how they ever lived without it (Spotlight, Expose, ...).
As for trying this with GNOME, others have already pointed out why it's not such a great idea. I'd just like to add that, because users like features, and already have specific features they want, this is basically begging for somebody to fork GNOME. (I already know what they'll say: "If the GNOME people ever get off their butts and start adding features we need, again, we can always just merge our changes back in.)
It feels as though this might kill the GNOME foundation as the leader of the GNOME project, in exchange for less-buggy software. Is it worth it? I don't know.
IME, we dread Windows and Office upgrades, but look forward to most of the rest. Most Mac users watch Steve at the keynote and say "wow, sweet feature -- I want that now". And then when they have it, they wonder how they ever lived without it (Spotlight, Expose, ...).
As for trying this with GNOME, others have already pointed out why it's not such a great idea. I'd just like to add that, because users like features, and already have specific features they want, this is basically begging for somebody to fork GNOME. (I already know what they'll say: "If the GNOME people ever get off their butts and start adding features we need, again, we can always just merge our changes back in.)
It feels as though this might kill the GNOME foundation as the leader of the GNOME project, in exchange for less-buggy software. Is it worth it? I don't know.
Feeping Creaturism! What a wonderful spoonerism. :)
Yes, I agree mostly. But I want to see really some features in nautilus that would ease my pain in browsing the file system: the grazy tree view thing on the right side should be removed, when I am using explorer mode (or at least I'd like to have an option to turn it off), so that I can have a normal list display. Nautilus could be faster and less memory hungry. I would like to have some kind of quick access to several positions by shortcuts, like it is implemented in KDE's konquerror (I mean quick access on the left side, so that I can browse the new location immediately)... But I would really thread these things as polish, not new features.
I really consider this bug-buddy thing as very important (you posted about it earlier). And another thing - bugzilla should be dropped and replaced by something simpler and more practical. Why not send the bug directly to the maintainer of the related component? He could forward the mail to someone who likes to fix it. Plain mails are much more efficient than these bugdb overhead: they burn on the nails of the developer, he sees the mail every day. The bug database makes it more easy to forget about things - just my opinion & experience.
I see where you're going with it, but don't entirely agree, for a couple of reasons:
Other OS also have a lot of hassle, it's just better hidden: Windows comes pre-installed, and because of the gigantic market share it is guaranteed to have drivers available. The driver quality often sucks, there's a miriad different ways to install them, and they drag in lots of useless control panels and software, but they're there; they exist. The hassle in this case is hidden because like I said most computers come pre-installed with Windows.
MacOSX has way less hardware variety to support: beige G3 systems aren't supported anymore since a while (10.3?) - even though they're perfectly capable to run the newest MacOSX. So Apple can and chooses to focus on a relatively homogenous hardware platform, so little wonder everything works as advertised. (they support 2 wireless network cards, the ones they ship: the Airport (lucent/orinoco) and Airport Extreme (broadcom bcm43xx). For anything else you're likely to encounter almost as much hassle finding ok drivers for MacOSX as you would on Linux)
Linux has to deal with the fact that they get extremely little support from the hardware guys, and that they try to support a huge variety of hardware. (And honestly, when it comes to old hardware it supports it often better than Windows; Often there's simply no drivers available at all, just try finding Voodoo3 drivers for Windows XP, or drivers that behave with SMP etc etc)
It's true that in the case of wireless, Linux's "natural selection" has just not gotten its act together quickly enough though, it's not only "no specs" and "FCC's a bitch" but also, "we got like 15 different wireless stacks, all with varying levels completeness/robustness/etc";
But then, that's an issue for the kernel, not Gnome.
I also agree with the sentiment of a previous poster that excluding new features won't make those new-feature-developers all of a sudden want to spend time polishing things.
Personally, I feel like there's too little experimenting going on - if you had to force me to name one new feature of 2.12 vs 2.10, I'd probably have a hard time naming one. It's hard to get excited over it - sure it's "newer/better", but not "killer app/gotta have it".
It's difficult to get new users with little changes, and easy to piss off existing users with little changes.
You're totally right!
Keep going on with your remarks, you're making a good job (from a french point of view...)
Keep up the good work with your posts. Although a "No new features" release would pretty much equate to the end of gnome, focusing more on polish is a great idea.
What we need is more people working on the existing bugs but it's hard for new people to "start hacking on gnome" Look at the gnome developer documentation versus the equivalent kde developer documentation...
Gnome needs to work on lowering the bar for entry level developers to begin fixing small bugs.
Disclaimer: this is spoken from a gnome zealot that thinks kde kills small children.
bugzilla should be dropped and replaced by something simpler and more practical.
Have specific suggestions? Reading your comments make me believe you do not have thought this out.
Why not send the bug directly to the maintainer of the related component?
That is already done. And it might not be one maintainer; it currently sends it to one or more maintainers, triagers and interested persons.
He could forward the mail to someone who likes to fix it.
How would of of the maintainers know such a person? How would the other persons know that person forwarded it. After the email was forwarded, how would you keep track of progress.. you need a bug tracker.
Plain mails are much more efficient than these bugdb overhead: they burn on the nails of the developer, he sees the mail every day.
So get rid of all the triagers we currently have and mail a developer directly? That is not going to work for the big projects. Evolution gets 150+ bugreports in a week. Also seeing the mail every day. You think a developer notices such a mail between the hundreds of others that arrive in just a month?
Furthermore, bugreports are already emailed. Using only email get rids of all the benifits a bugtracker provides. So if a maintainer leaves without a trace, the next person has to hope every reporter notices that and mails the new developer?
The bug database makes it more easy to forget about things - just my opinion & experience.
So you have experience that having 200.000+ seperate emails are better than a bug tracker? Using only email messages might work for a small project, but not for big ones; you need a bug tracker for that. And do not bring up debbugs, that is also a bug tracker. Very different from 'only using email messages and forwarding that'.
I could go on.. but really.. not using a bugtracker is strange.
I have only two whishes for the future:
1. Get GEdit (or all apps for that matter) match leafpad in startuptime.
2. Get Devolt into a state where a typical itch-scratcher with no Gnome development experience can get from itch to first test-run of new code in under 10min.
Each time I get ready to roll up my sleeves and do some hacking I end up diverging further and further from my goal by configuring and learning all tools that I need and setting up a test environement that I just give up.
Getting a hackable and testable source into some kind of IDE or similar should be as easy as a single "apt-get install".
I'd be more than willing to wait a year for the XGL stuff to stabilize before supporting it officially in mainline gnome.
No New Features sounds like a great idea to me.
I think your are damn right. Making 2.16 the "polish, polish, polish" release would be really great. There's so much little details forgotten in our favorite DE that you feel like a second class citizen, as you said.
I think Gnome should shift focus back and forth:
6 months> focus "more" toward stability aka 'polish'
6 months> focus "more" toward new features
...
repeat
repeat
alternate the focus, that way the polishing cycle is effectively a way to clean up the mess that the new features bring in, cleanup time after the fun. ;-p
The >only< reason some people i know use KDE over Gnome is because they say "I can't do --insert some cool transparent effect here-- in Gnome....and I'm stuck having to agree with them, because even if you can do it in Gnome, it takes at least 5+ more intermediate-> advanced steps to implement, and then it's buggy because it's either using software made for K and not Gnome, or is just not well kept software.
I don't like KDE much because I get far more crashes in it when compared to Gnome in regard to my usual activities. But I feel the compromise is that I must deal with having a Panel that lacks the configurable capabilities of K Desktop's.
I mention K because amongst my friends it's KDE vs Gnome constantly ;-p
If we do one release just polishing that would mean no news for one year! (because we drop new features in mid-time). I think we can not do this. But I would agree if you would say:
* identify the most annoying things
* solve these
This can be done also with innovation. Printing, for instance - it is very, very, very BAD in GNOME. I would wish we would have a better printing system and take all the energy for that till 2.16.
There should be at least some points where people will get excited about. That is not so difficult. Some things can be done very easily. I would rather follow the path of Miguel. Change things, let people test ist and then fix it later on. I think, though that the innovation of spatial Nautilus was not well thought through and has cost quite some users in the end. BEst is to provide innovation from one new project of 2 or 3 people. That does not cost ressources but makes users happy. And my main wish is: Cooperate,Cooperate, Cooperate (with KDE!)
You can't improve what you can't measure. Maybe Bug Buddy should take some ideas from here?
Then you would at least be able to answer the question "what application crashes most often?". When you have the answer to that question, then you know where to start fixing things.
If you want to make it more stable have a team work on stable sub-releases: 2.14.1, 2.14.2, 2.14.3, etc.
Let people who want to do new work, do their work.
To me, too many things are still missing, that KDE, fo rone has. These are mostly smaller applets and utility applications that we are lacking, such as a KPPP equivalent, a good burner like K3B, a Scheduler/Cron front-end, Colour Picker (had one in the GNOME 1 series but I don't know why it was dropped), a better hardware detection application (can't think of the name of the KDE one) and so on.
These are all major gaps that need to be addresed. Once this is done, yes, begin to focus on polish.
Yes, polish is needed but I would also like attention focused on
addressing all of these suggestions:
http://chabada.sk/better-desktop/
Also, there are still huge gaps in things liek the lack of kppp and kinfocetner equivalents.
The last version of Gnome used less memory than its predecessor. And I don't really notice any bugs in Gnome programs. Also, Gnome on Ubuntu is completely usable on a machine with 256 megs of RAM, and probably less memory too.
Some projects are suited to having releases which are just bugfixes; I think Gnome, as a very visible part of the Linux computing experience, is unsuitable for this. Still, I don't oppose the idea of adding slightly fewer features and having a longer bugfixing cycle!
Post a Comment