Havoc Pennington wrote:I see leaving it to QA have 2 problems: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. - 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 upstreamRight, 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 |