Re: Issues with library version numbers




Jeff:

In reviewing interface stability, I have been looking at the differences
between the interfaces exposed in the various GNOME libraries.  I notice
that there are a few libraries which have not changed version number since
GNOME 2.0, but have also had modifications to their exposed interfaces.

Brian, the release team can't do anything about this issue at this point in
the release cycle. You are best off mailing gnome-hackers about it, and
suggesting specific changes maintainers can make (and documenting them) and
making sure it happens in the 2.13 process.

I wasn't suggesting that the release team should do anything directly to
fix the bugs I highlighted.  I agree that addressing these issues in the
2.13 timeframe makes the most sense.

I mention this issue on the release-team mail alias because the release
team is responsible for quality and API/ABI compatibility.  Perhaps when
the release team sends out API freeze notices, they could better emphasize
what maintainers need to do.  There seems to be evidence that some
maintainers may not be following process or may be unaware of release
team expectations.

The fact that interfaces have been removed from libraries may indicate a
breakage of current policy, which I think is something that the release
team should be aware.  Perhaps the release team needs to make it more
clear to maintainers that removal of interfaces and following proper
library versioning is something that needs to be done with more
consideration.  There currently is no mention about how API/ABI or
library versioning rules apply to Maintainers on the Release Team's
"For Maintainers" website.  Perhaps this could be improved.

> Brian, it has been quite well known throughout the project that we are
> trying to shift away from Bonobo. We should have deprecated it ages ago,
> we've just been procrastinating to avoid the social intrigue required to get
> it done. ORBit2 is a slightly different story. It's there mostly for Bonobo,
> but we've used it in other places too. Many will shift to d-bus (gnome-vfs,
> gconfd, e-d-s), but the conversation is wide open for a11y.

Perhaps it is clear to some people, but I think that these sorts of plans
have not been well communicated to GNOME users who could reasonably be
depending on GNOME interfaces.  The Release team website suggests that
any Platform library should be safe to use.  I'm not sure this statement
is what we should be telling users if we know interfaces are going away.
I'm suggesting that the release team consider how to better send the right
message to our users.

> Keep in mind that Project Ridley is focused on getting stuff into GTK+ that
> should belong there. It does not have a direct impact on how we define the
> stability or supportability of the GNOME Developer Platform libraries. But
> the renewed focus on our entire platform means Ridley will inspire us to get
> the GNOME Developer Platform mess fixed too.

I hope so.  I am not trying to suggest that we should lump together Project
Ridley with sorting out the other libraries.  I'm just wondering if the
release team has any idea of the future story for the libraries in the
Platform that won't be affected by Ridley.  Perhaps this needs to be
sorted out on gnome-hackers first.  I was just wondering if the release
team might have an idea.

I would be happy to propose patches to the release team website geared
towards communicating things more clearly if that would be helpful, or
if anyone has any suggestions about how I could better be involved to
make things better, that would be great.

The point of this email could have been communicated in about 10 lines, btw.
> :-)

I apologize if the way I communicate is counter-productive or annoying.  I do
try to be concise, I really do, but I will try harder.  Communication is a
two way street, though, so let's try to work together.  :-)

Brian



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