Re: ARC & GNOME [Was: How we make decisions...]



Havoc Pennington wrote:
On Tue, 2004-11-30 at 19:27 +1300, Glynn Foster wrote:
  
I've seen a number of references to concerns about interface stability
from Sun; I'm curious what the examples are. 
      
We're not just talking about library interfaces here. We're also talking
about binary names, file locations, file formats, package names, ... you
name it. I think GNOME has done a pretty decent job for library
stability [1], but the other stuff we've not been so good with.

    

Right, that makes sense. I believe this is primarily a QA problem fwiw.
I don't think process will help. What will help is tools for tracking
the stuff, and people filing bugs and making noise about them.
  
    I see leaving it to QA have 2 problems:
    - more complete QA is generally done after the GNOME release has been adopted by the various distros.
    - lot of these breakages are only exposed when users upgrades from one release to the next.
      For example the gnome-panel patch which Mark has nicely fixed.
         http://mail.gnome.org/archives/desktop-devel-list/2004-November/msg00318.html
        That bug was really been raised after 2 releases later.

    Fixing a released product is costly. It would be better if this can be picked while in development cycle!

    If somewhere alone here we can come up with a checklist where the developers  can go through before
they release a new module or version such as:

- Have I changed my library version?
- Have I created/removed any binary?
- Have I created/removed any configuration file?
- Have I added/changed any gconf key?
    ... so on
    I am sure others can come up with a longer relevant yet simple list.
   
    Have a simple template as part of the release mail so that all can use.

-Ghee

A lot of this we just aren't going to consider public interface, though,
FWIW.

  
[1] The only breakages we're seeing on our side from 2.0 were from
libgnomeprint* and a single API or so that we introduced before the
multihead GTK+ got upstream
    

Right, and libgnomeprint wasn't public API at that time iirc, or at
least should not have been, and the gtk thing is an object lesson in the
problem with non-upstream patches ;-)

I think we should be rapidly converging on the point where the public
API is "GTK plus dependencies" which is much simpler to explain.

Right now the Red Hat to ISV recommendation is "GTK+, GConf,
libgnomeprint, libgnomeprintui, and libglade"

Havoc


_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
  



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]