Re: API freeze for GNOME 2

[Daniel Veillard <daniel veillard com>]

On Thu, Nov 15, 2001 at 04:58:48PM -0500, Michael Meeks wrote:
> 
> Hi Daniel,

  Hi Michael,

 First could you update your pine email list, though I'm garanteed
my @w3.org email will be kept working, this is not my email anymore.

>         You do realize that the board resolution - as transmitted to me by
> authoritative hearsay on the release team list - includes not adding APIs.

  The board output is in the Minutes I sent earlier today. And Maciej
sent exactly was said at the Baord, me included. This was that *changing*
APIs should be nearly vetoed, and that adding APIs should be examined
closely.

>         So ... I suggest that you follow the release rules; only insofar
> as they concord with common sense. [ I note the board meeting notes, don't
> mention this aspect of not adding APIs ( especialy ludicrous for use
> outside Gnome ) so perhaps I've got confused somewhere ]. The last thing
> we want is module stagnation.

  But the first thing we want is apps to be ported. This requires a
"promise" that *now* is the right time to start, and that means that
the API freeze must occur. Of course this should not prevent changes
if porting the apps proves impossible if the APIs are broken, but if
this happen then that simply mean the whole process must be delayed.

  The goal of avoiding new APIs is multiple:
    - help preparing the doc
    - making sure all entry points gets "registered" and in some sense reviewd
    - avoiding people from making new APIs at the last minute if
      the existing ones are broken

  The point of the exercise is that the freeze allows to test the
current state, and then see if the whole pack is actually in a releasable
state. It's definitely not a stagnation, there is still a huge amount
of work needed during a free even by developpers:
    - checking docs and all entry points 
    - be available and help the guys on the upper layers trying
      to use the stuff.

  This is an exercise in transmitting information, and unfortunately
if the programmer keep focusing on code and not users, well the uper
layer are likely to misuse the platform and the result at the end-user
level will show up. 

  So I really don't see a freeze as a module stagnation, If really the
free would put a programmer only in frustration mode then there is still
the possibility to branch in CVS.

  To go back to the API I added, I did it because redoing it at the
user level would likely be done wrong, it was requested, it was already
existing in part inside libxml but not properly isolated, and it was
really a distinct API not a variation of an existing one.  Also
libxml/libxslt really had the equivalent of it's freeze around July for
the 2.4.0/1.0.0 set of releases. But still I think a freeze/checkpoint
at this time is a good idea even for those modules.

    Yours,

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/