Re: API freeze release ... status so far.

On Fri, 3 Aug 2001, Michael Meeks wrote:

> Hi Sander,
> On Thu, 2 Aug 2001, Sander Vesik wrote:
> > Suprise!!! Starting with a big platform change 4 days before supposed
> > API freeze broke lots of things.
>         The change is not in fact that large - and amounts mostly to a
> bunch of seds. It took me only ~ 2 hours to port all of the relevant
> modules to bonobo-activation, and only ~ 1 day to get the patches approved
> [ mainly due to people not being awake ].

Well, an otherwise small change of changing the name of a library and
making 1 line changes to makefiles in other modules would still be a hughe
change if it was done just before the freeze.

size_of_change = size_of_diff / time_to_release

> > OTOH we really need to make sure everything freezes and is released
> > ASAP. The reason there is a thing called 'library beta 1' scheduled to
> > happen in 5 weeks time is so as much as possible of non-API bug fixing
> > could be pushed to post-freeze and make it easier for people to
> > participate.
>         So, I see priorities as glade / libglade, printing and gal / eel,
> and any other misc. foundation libraries we need.

The problem is that printing is a bith more "core" than that and we really
need libglade. So everybody please bury the maintainers in patches to make
them API-ready.

Unless gal and eel are ready and frozen *NOW* I would personally rather
not include them in the set of public advertised core APIs. I do believe
there are open issues around which part of these would be moved into 
gtk+ 2.2, so if gnome 2.0 and a follow on gnome 2.2 happen, adding
either/both in the follow-on would be a low cost, compatible operation. 

If they are not ready *NOW*, then it is do lkate in the game to wait for
them, at least IMVHO.

>         Also - I hear rumours of GStreamer being used as a sound API - and
> I wonder:
>         * Who uses this API
>         * Where is the API published ?
>         * Is it frozen ? / can it be frozen now ?
>         * Can we ship packages for it that don't require thousands of
>           obscure support libraries ?

The problem with GStreamer is that while the GStreamer (and associated)
people are using the age-old trick of always calling Gstreamer the gnome
sound API whenever talking about it even though I don't think there has
been *ANY* deceision about that.

>         Regards,
>                 Michael.
> -- 
>  mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot


I haven't been vampired. You've been Weatherwaxed.

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