[Xcb] About next release of xcb/util

[Barton C Massey]

In message <20100324191316.GA4331 at feather> you wrote:
> This seems like a *bad* idea to me at this stage.  I do
> agree that we should build exactly one .so per repository.
> However, I disagree that we should merge a pile of
> libraries of varying maturity into a single xcb-util.so.

Except for keyboard, I don't think the libraries we are
proposing to merge are "of varying maturity".  They're all
code that supplies basic functionality that almost everyone
using XCB wants to link with.

I think it's a close call whether to merge keyboard, but I
don't really see any organizational issue in doing so.
What's the expected trouble case here?  It will mean
frequent upgrades of the merged library, but AFAICT we can
live with that.

> I'd advocate, instead, that we keep exactly the libraries
> we have right now, split them all into separate repos, and
> then *possibly* work on distilling the best of these into
> an xcb-util.so in the future.

I don't get why this plan buys us anything for the libraries
we are proposing to merge.  Right now we have multiple
libraries being built from a single repo.  This suggests
either splitting the repo or merging the libraries.  J's and
my plan does some of each.  I don't see a problem here.

> Review from previous messages in this thread already
> suggested that much of xcb-aux seems unnecessary,

Strongly disagree.  After much discussion, I still think
that most of us agree that most of xcb-aux is quite useful.
AFAICT we identified exactly one function that should die.
Horribly.  By fire.

> and you already mentioned that event, reply, and property
> mostly need to die.

Yes, we are now proposing splitting those and maybe killing
them.

> We should probably do an equally careful review of atom,
> icccm, and ewmh, to figure out what of those needs to
> survive and what doesn't.

Feel free. :-) As much as I'm not a fan of a lot of the code
in atom, I'm not sure what I would do without it if I was
doing anything substantial with XCB. I think the client-side
icccm and ewmh stuff is also pretty essential to writing
clients for the most part.  Feelings on whether to sort it
out from the wm-side stuff seem pretty mixed.

> But I don't think any of that should stop Arnaud from
> splitting up the repositories by libraries.

I don't think anybody should split anything until we have a
sensible plan.  XCB is already a twisty maze of tiny Git
repos; if we're going to multiply that even further, I want
to do it only once every few years and get it as right as we
can.

    Bart