GNOME and Regressions

Monday, January 12, 2009 10:41 - GNOME

Years ago, I was not in the same position, but I looked at Project Utopia and oh it was so cool, kernel and user-space communicating to achieve a grand goal, look you can plug your camera and then there is this event generated by the kernel and then there is HAL and then there is gnome-volume-manager and voila there is gthumb opening on your desktop. It sure was better than mangling with permissions in /dev/, hacking hotplug scripts, and, for mass-storage systems, the disk-mount applet.

Did we speak of regressions back then? I do not think so, there was a vision and it was well communicated and everybody was happy reading new Robert Love posts on HAL, udev, g-p-m and co.

Things change. Robert writes about the economy and the excitement should now build on "statistics on power usage will now also be aggregated when waiting in gdm". Mmmm, so exciting!

Nobody spoke of regressions back in Utopia time, it was all enthousiasm, "Next stop Utopia, full steam ahead"; it was well understood the effort encompassed lots of components and it was worth it.

"You won't have power statistics any longer if you do not have udev 130"; and then nobody is allowed to tell it is a "regression", "such a loaded term", "stop-energy", "you do not see it is progression", etc.

I believe in discussion, I believe ignoring comments just because the dreaded "regression" word was used is not a good idea; what could be done instead? I have two points:

  • We should explain the benefits, the tradeoffs, see for example Richard post on DeviceKit-power latency control; hopefully people will see where we are heading, and agree on the direction.
  • When necessary (and it will be difficult to judge, listen to users, listen to downstream contributors), we should keep previous code as a legacy component, it may well be unmaintained, and certainly won't get new features, but will avoid people shouting about disappearing features.

Last Modification: Monday, January 12, 2009 10:41

What I think we need to learn is that regressions are _bad_ things. Everyone wants to see progress, of course, but I don't want to upgrade my system to find out that something just stoped working. Migration paths are as important now that we are starting to have a number of non-technical users. I can deal with my system changing beneath my feet, but my mother is not able to do the same. Of course I can do it for her, but we should be targeting allowing non-technical users to take care of their own systems.

I believe regressions are really going to become a hotter topic now. The days when we coded for our small community are ending; we're now coding stuff that is used in corporate desktops, and being sold pre-installed in mainstream-market machines. We should think real hard on how to improve while providing an upgrade path.

Comment by Gustavo Noronha on January 12, 2009 21:25

Comments on this entry have been closed.