RE: Proto initial GNOME 2.6 new modules decision

[Murray Cumming Comneon com]

> > It's not an optional dependency, so I think we all expect 
> it to follow 
> > the GNOME release schedule, and that's why it was listed as 
> a proposed 
> > new GNOME 2.6 module. Please tell us very clearly if you do 
> not expect 
> > libxklavier to follow the GNOME Desktop release schedule.
>
> Well, well. You really caught me here. The thing is that I 
> would be happy to follow the GNOME schedule. And in a future, 
> I will try. But for 2.6 I really cannot promise. The support 
> for non-xkb-able platforms (just compilation!) made me 
> release 0.97 which effectively broke API used in g-c-c and 
> g-c. Sorry, but I had no choice (and could not do it before 
> because I simply have no Solaris/HPUX box around). The 
> compatible (compilable and working) code for g-c-c and g-a is 
> in CVS, sure - but the previous development releases are 
> broken, they are not buildable with 0.97. I am sorry but I 
> could do nothing about it. Release team can kill me if it 
> makes them feel better.

Please request a freeze break in future:
http://developer.gnome.org/dotplan/tasks.html#ApprovingFreezeBreaks
 
> That is why I would consider libxklavier as external 
> dependency for 2.6
> - and probably would include it as a core library in 2.8, 
> when we settle platform support down. But this is just my idea.

Obviously we don't like API changes even in Desktop modules, because they
require recompiles of the GNOME modules that need them - gnome-applets in
this case, I think.

However, Desktop modules do not need to follow the same API rules as
Platform modules. For instance, gstreamer does not have a stable API yet. I
think they freeze their API when the GNOME schedule says so, and wait until
the next release schedule to make other changes. In contrast, GNOME Platform
modules can not change their API ever - they can only add API.

But in reality, breaking APIs even between GNOME 2.6 and 2.8 would be
unpleasant. In this case, a parallel-installable API is usually the
solution. For intance, libgnomeprint (also a GNOME Desktop module, but not a
GNOME Platform module), has a libgnomeprint 2.2 API that can be installed in
parallel with libgnomeprint 2.0, so that existing applications will not be
broken.
  
> > Keep asking and keep repeating the issues, I guess.
>
> I am trying. It seems, the major problem is the speed of 
> support on legacy platforms (Solaris, HPUX etc) is the poor 
> XKB implementation (even if it exists!). Just quite recently 
> it was found Solaris does not set necessary root window 
> property (current XKB configuration) - and God knows how long 
> it will take for Sun people to fix it.
> 
> That's the whole truth.

Murray Cumming
www.murrayc.com
murrayc usa net