|| ||David Reveman <davidr-AT-novell.com>|
|| ||Robert Carr <racarr-AT-beryl-project.org>|
|| ||Re: Beryl and Compiz Merge: What's actually going on?|
|| ||Wed, 28 Mar 2007 12:11:25 +0200|
|| ||Beryl development list <beryl-dev-AT-lists.beryl-project.org>,
On Sun, 2007-03-25 at 08:07 -0400, Robert Carr wrote:
> Compiz and Beryl merge: What's really going on?
> Recently Quinns post to the beryl-dev mailing list entitled 'Merge on'
> has led to a lot of discussion, some of which has been good and some
> of which has led to a lot of misinformation, to clear things up I'd
> like to give the story of the merge, and the justification for some of
> the more peculiar aspects. Basically lets try to avoid misinformation
> and make sure everyone has a realistic picture of what's happening.
> The first thing I want to note is: The merge is NOT ON, it looks
> incredibly likely, and it's looked incredibly likely for a few weeks
> now, but there are still some very important things to work out, and a
> lot of discussion still needs to happen.
> Around a month and a half ago some of us were discussing some rather
> radical changes to the design of beryl-core which we inherited from
> Compiz, this inevitably led to "We should talk to Compiz about this to
> keep things synced", which even more inevitably leads to "If we are
> going to talk to Compiz to keep our designs similar, so on, so forth,
> are our differences really so large that we need to be two seperate
> projects?". After talking to a few people I sent an email to David
> Reveman of Compiz on a personal basis suggesting the idea as something
> worth discussing, and not really sure what to expect as a response
> (not having interacted with David before). The response was better
> than I could have hoped for, and David seemed very interesting in
> working with us. Excited, a few of us organized a quick adhoc-meeting
> and worked out a few things that we'd feel neccesary for a merge to
> work, and a few of these have raised some rather controversy ridden
> discussion now that they are well known, so I'd like to enumerate some
> and justify them here.
> Beryl has about 3 times as much code as Compiz, we've written this
> because we feel it's neccesary or improves things in some way and we
> want to see things integrated rather than go to waste. This one is
> trivial really, it's obvious why we would like this, and we set up a
> list of differences, discussed it a bit with Compiz people, and we're
> able to quickly come to answers on most of the differences. This
> was eased by Compiz's announcement that they plan to make
> compiz-extras more of an official project, which has much of the same
> as Beryl, this made it evident that a lot of our goals really were the same.
> New project under a new name, this has been the most controversial
> point as a lot of people don't feel it's fair or that it will lead to
> a lot of unneccesary difficulty, that it will lead to distributions
> unwilling to support such a new window manager or dozens of other
> complaints. I've thought about this quite a bit, and I'm going to try
> and justify here why we initially asked for this, and likely why
> Compiz is good with it. The primary reason is the difference in
> structure between the two projects, Beryl and Compiz handle management
> differently, handle new contributors differently, handle releases
> differently, handle a LOT of things differently. Frankly I feel if we
> merged under one of the previous projects (Call it X), then there
> would be a tendancy to just give everyone from the other project (Call
> it Y) a developer account, start merging the code from Y and say
> "Merge done!". This will NOT work, all of us feel pretty strongly that
> for the new project to succeeed it needs to include the best aspects
> of both Beryl and Compiz, and under the envelope of the already
> established Project X it's difficult and possibly impossible to
> integrate the 'core' (not as in beryl-core as in metaphorical core),
> of Y
> properly. It's better to start from a blank organizational state and
> decide everything together, we HAVE to decide things together,
> frankly the worst imaginable situation is a month from now Project Y
> says "This isn't what I expected from a merge! REFORK!". Another
> crucial point is the communities, open source projects are built
> around communities, and no community wants to be absorbed en masse in
> another, theres a lot of bitterness between the Compiz and Beryl
> communities and theres no better way to resolve this than the two work
> together to make a new and better community. We'd also all like to
> avoid the new project being stuck with whatever conceptions formed
> around the name of the aforenamed project X, the new project will be a
> merger of the Compiz and Beryl code yes, but it will be something
> new, better, and with a broader scope, and we hope it can be looked at
> that way.
> Some sort of well defined leadership structure, probably decided
> through some sort of vote. Again, the reasons for this are obvious.
> no just "Having David and Quinn share leadership" is most definitely
> definitely definitely not a viable option.
> So, anyway back to the story. After this David and I (more on behalf
> of Beryl at this point) exchanged quite a few emails back, having some
> basic discussion as to how the technical differences can be resolved,
> and then the discussion kind of died for a bit, though David did set
> maniac onestone and I up with Compiz accounts. At this point we mostly
> just went back to doing what we were doing even though it seemed like
> everyone (except Quinn) was behind the merge. This kind of exposed a
> big problem Beryl had, we had no way to make a decision outside of
> consensus (not forming an official decision for the project), besides
> a ruling from Quinn; rather ironic considering some of the reasons for
> the fork, and frankly Quinn just wasn't willing to budge or really
> discuss it in a reasonable fashion, so things were kind of dead. After
> a while onestone started working on a new libberylsettings in tandem
> with David (and drew a few others in to working on it), so that we
> could reunite the Compiz and Beryl settings systems (the biggest
> differences), and this kind of brought some interest back to the
> merge. None of us were really sure how to make it happen due to the
> aforementioned inability to make a decision, so eventually 4 of us
> (onestone, maniac, iXce, and I) (at the risk of being colloquial) said
> "Screw it" and contacted Compiz leadership essentially saying "We
> can't get Quinn on board, but everyone else is, so why don't we just
> go ahead and set up the new merged project, and announce that is where
> we will be working in the future, everyone else will follow (as
> EVERYONE was for it with the aforementioned exception), and it's
> clearly the best thing for both projects." A few hours later Quinn
> changed her mind, made the post mentioned at the start (Thanks Quinn
> for taking another look at things and being willing to change your
> mind, this makes things a lot easier, and is never easy).
> So, that's where we stand now, some of the final details are being
> discussed now and once David gets back from brainshare we hope to be
> able to work out the remaining problems and have some more news within
> a week or so!
Thanks for keeping people updated.
I think you're making this into a bigger thing than what it is. Lets
focus on solving the technical part first, most importantly move to
having one core. I'm only talking about the code that's currently built
into the compiz binary, none of the plugins. Merging plugin code is not
nearly as important as the move to having one core.
We're not very far away from having one core as I understand. There's
clearly not 3 times as much code in beryl core as in compiz core, you
must be talking about plugins here. The differences that been brought up
to me have all been minor changes that I don't see any reason why they
can't be resolved.
The merge is done by moving changes made to beryl into compiz or by
adding alternative solutions to compiz. No changes are made to the
design of compiz and 99% of the code is still code being written as part
of the compiz project so I'm having a hard time to justify a name change
of the core and I know that most people in the compiz community are
firmly against such a name change. A more plugin oriented side-project
under a new name could make sense, though. Like what compiz-extra is
supposed to be but my opinion is not as important here as I'm not as
involved in that part.
Regarding leadership, having anything but a technical leadership of the
core where the people who write the code and the people with most
knowledge gets to decide is silly to me. Community leadership, who's in
charge of the web site and such is a different thing and maybe a bit
harder to solve but I'm sure it can be worked out in time.
The technical part of the merge seems pretty straight forward from my
point of view and I've got the understanding that so is also the case
for the main contributors to the core of beryl.
to post comments)