Changing private symbols to public (was: Re: CVS Update: xc (branch: trunk))
Mike A. Harris
mharris at redhat.com
Tue Feb 1 04:00:01 PST 2005
On Tue, 1 Feb 2005, Daniel Stone wrote:
>On Tue, Feb 01, 2005 at 12:35:03AM -0500, Mike A. Harris wrote:
>> I searched the mailing list, and I couldn't find any emails
>> mentioning the rationale or approval for this change. Was this
>> discussed on a confcall or somesuch?
>
>No, it wasn't.
IMHO, such API changes should be discussed and concensus reached
before any changes occur.
>> Could someone summarize the rationale for the change, and it's
>> acceptance into CVS head?
>
>The rationale is simple: if another library is using it, it is not
>private API, no matter how many underscores you put in front of the
>symbol, and no matter that you put a comment saying 'this is private
>API'. It's simply not.
I don't disagree with that. X.Org needs to be enhanced to hide
it's internal library symbols using gcc's attribute((hidden))
functionality (and potentially other compiler's similar
functionality). Jakub Jelinek wrote some stuff for XFree86
before to do this which nobody ever bothered integrating for
whatever reason.
>I made this change so we could actually delineate between what
>was and was not private API. I don't know what the rationale
>for intruding on another library's allegedly private API was in
>the first place, but I just made it official: either it should
>be public, or libSM must not rely on it.
This indicates that there is indeed a problem, and that someone
should investigate potential solutions for the problem, discuss
the problem openly on the mailing lists, and get other people's
thoughts on weighing the ups and downs of the different potential
solutions.
Then, once concensus can be reached between the parties
discussing the potential solutions, whichever solution is
decided, can be approved and changed officially.
I don't think it is a good idea for random developers (whoever
they are) to just go ahead and make API changes of this nature
without consulting other developers who will be potentially
impacted by the changes.
>I committed it into CVS HEAD as it was quite obviously correct. I
>moved the symbol into public API visibility, and bumped the soversion
>by 0.1 as it introduced a new symbol. Backwards compatibility was
>retained.
You consider it correct obviously, or you wouldn't have committed
the change. So far, nobody has stated the change is incorrect,
nor pointed out any problems with it, and it may very well turn
out to be deemed the correct change by everyone, and left in
tact.
The point I'm trying to make, is that no discussion about this
change ever took place on any mailing list or other forum that
I'm aware of.
Does this establish precedence that it is ok for anyone with CVS
commit access to change the X library API's in any way they deem
to be "obviously correct" without any pre-discussion between
other developers?
I think we need to establish some CVS policies to ensure that any
changes of this nature are adequately discussed and agreed upon
by multiple developers via peer review of some sort.
Again, my point isn't necessarily about the specific change, but
rather the fact that it occured without discussion.
Comments/feedback from anyone and everyone appreciated.
TIA
--
Mike A. Harris, Systems Engineer - X11 Development team, Red Hat Canada, Ltd.
IT executives rate Red Hat #1 for value: http://www.redhat.com/promo/vendor
More information about the xorg
mailing list