Commit notifications for specs

[Pau Garcia i Quiles]

Quoting Vincent Untz <vuntz at gnome.org>:

> Le mercredi 30 avril 2008, à 17:18 +0200, Pau Garcia i Quiles a écrit :
>> Quoting Vincent Untz <vuntz at gnome.org>:
>>
>> > I totally agree that we need to put more than just versions of the
>> > specs, but also the adoption status, a kind of stability status (is it
>> > still in development, with potential incompatible changes in the
>> > future?), draft vs released status, etc.
>>
>> Regarding the adoption status, stability status, etc, I'd like to urge
>> both KDE eV and Gnome Foundation to "enforce" FreeDesktop.org's
>> specifications, as I discussed with Vincent and others at Guademy last
>> weekend.
>>
>> Long story short, it would be like this: if there is a fd.o spec for
>> what you are doing and you are not using it, your app/library won't
>> enter the official KDE/Gnome/whatever repository *unless* you provide
>> good reasons for not implementing the fd.o spec (that "unless" is
>> there in case the spec is disconnected from reality or plain junk).
>
> Oh, I remember you mentioning this, but I forgot to ask you: any example
> of KDE or GNOME apps not following a spec without a good reason?
>
> (note that the issue is a bit orthogonal to the discussion, since the
> specs are, hopefully, more widely adopted than just in GNOME & KDE)

For example, KIconLoader in KDE.

And two other examples, not exactly what you asked but important IMHO:

- The KUIServer developer is trying to put together a JobViewServer  
spec but, AFAIK, the Mathusalem developer helping too much. Bad for  
everybody because we might end with a sub-par spec which is too tied  
to KDE/Qt.

- KIO, GIO and GnomeVFS. KIO is the I/O framework used by KDE since,  
at least, 1999. But the Gtk+ developers decided to go on their own and  
implement GIO without talking to KDE developers. GIO was developed  
while KDE was developing the 4.0 version, a very good moment to break  
compatibility. This has been a sad, missed opportunity to define a  
common spec. Even if a "Freedestop.org Input/Output spec" is defined  
now, it would probably imply deep changes in KIO and GIO which are  
probably not acceptable.

Please note I'm not saying software that does not implement the fd.o  
spec should be trashed, only that if you want your software to be part  
of the official repository:
* If you don't implement the fd.o spec, you *must* justify it (i. e.  
show why it is a bad spec)
* If you don't implement the fd.o because for no reason, keep your  
software in your own repository.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)