Re: Approval required for a fix in evolution-data-server module (Re: [evolution-patches] [EDS-libedataserver] Fix for #271969)

[Elijah Newren <newren gmail com>]

On 8/16/05, Luis Villa <luis villa gmail com> wrote:
> On 8/16/05, Veerapuram Varadhan <vvaradhan novell com> wrote:
> > On Tue, 2005-08-16 at 08:38 -0400, Luis Villa wrote:
> > > On 8/16/05, Veerapuram Varadhan <vvaradhan novell com> wrote:
> > > > Hi,
> > > >
> > > > The fix for http://bugzilla.gnome.org/show_bug.cgi?id=271969 requires a
> > > > function to be added to an exposed header file in evolution-data-server
> > > > module, thus breaking the *norms* of API freeze.
> > > >
> > > > Below mail-thread and the above bugzilla link will give you complete
> > > > information as to why this fix is *very critical* for the forth coming
> > > > Evolution 2.4 release.
> > > >
> > > > I request you to kindly approve this fix ASAP.
> > >
> > > I'm not quite sure what is being asked here- the referenced bug says
> > > nothing about a new function,
> > The patch in
> > http://bugzilla.gnome.org/attachment.cgi?id=50785&action=view
> > exposes a new function (pasted below for reference) in
> > e-d-s/libedataserver/e-xml-hash-utils.h.
> >
> > +void           e_xmlhash_foreach_key_remove (EXmlHash     *hash,
> > +                                     EXmlHashRemoveFunc  func,
> > +                                     gpointer      user_data);
> > +
> >
> > and since, the new function is added to an exposed header-file, I
> > thought it could break the API freeze, so requested for an approval.
> 
> I see. It does technically violate the freeze; but given that no one
> guarantees api stability for e-d-s, and this is an addition and not a
> change/removal, this is fine. [I think- I'd love someone else from r-t
> to weigh in on this.]

It was suggested last release cycle that we make an API freeze for
libraries in the desktop release that other modules depend on and
aren't considered private (e.g. who cares if libmetacity-private,
which is only used by control-center, makes an incompatible change so
long as control center is updated to sync with it); see
http://mail.gnome.org/archives/desktop-devel-list/2005-February/msg00398.html.
  (And this happened to be suggested because of the grief that I
caused...)  Alex specifically wanted to exclude API addtions for such
modules from the freeze, though, so even if that had become a rule
your particular patch would still be allowed without release team
approval.  Anyway, there was rough consensus for this proposal (though
Jeff wanted to keep it as an advisory freeze and leave it up to the
module maintainers), but we never really finalized it.

In other words, since e-d-s is in the desktop release, this API
addition doesn't break any applicable freezes.

Elijah