Possible Merger with Beryl [Archive] - Compiz Community Forums

imnotpc

March 24th, 2007, 04:23 AM

As many of you already know, there have been sporadic discussions with members of the Beryl community over the last few weeks regarding the possibility of reuniting. While these discussions have been informal, they have led to greater cooperation between the communities.

Shortly after I published the description of the proposed restructuring of compiz, Quinn Storm of Beryl published a proposed redefinition of Beryl that was very similar. After some discussions with the Beryl community we came to the conclusion that that Compiz-Extra and Beryl would be nearly identical projects competing against each other using the same (or very similar) core, the same plugins, and having goals that were very similar. The obvious question then became: "Why are we competing?"

At this point we are actively discussing the possibility of reuniting. Many of the issues that caused the fork and have kept us apart are now resolved or irrelevant. The idea we have discussed is combining the Compiz-Extra and Beryl communities under a new name. Compiz would continue to exist as a smaller package as described in this post: http://forum.go-compiz.org/viewtopic.php?t=677

The members of the Managing Committee represent you, the Compiz Community. We need to know what you think.

Jeff

rememo

March 24th, 2007, 09:55 AM

Well, this sounds great. I'm all for reuniting!

Anyways, what I wouldn't like to see, is a rebranding of compiz-core in the new "call-it-whatever-community-project". It should only depend on compiz-core and maybe provide packages but never rebrand it or provide a patched core.

If there are features that come up that won't be running with official compiz-core, there should be patches sended upstream to provide the functionality or use the core-git-access of community-members (they are spanning a bridge between the community-project and official compiz-core).

I think all the infrastructure is in place to get this merge going and create the united project.
I think next to do is to decide about a name (maybe having a poll at beryl and here). Then create a new projects page and repos and throw in everything both projects currently have that will run with unpatched compiz-core. If there are any plugins, settings-managers, composite-programs, decorators, etc. that won't run with unpatched core they will have to stay outside the repos until the proper patches to official compiz-core have been accepted by both compiz-core (i.e. David and all other devs that decide to be core developers) and "compiz/beryl-community" (i.e. onestone|maniac|mikedee|...) members that have core git-access.

Looking forward to a great time :)

delfick

March 24th, 2007, 10:38 AM

cool :D

finally !! :D

also, will the beryl and compiz forums stay ??

i think that would be a wise decision, since both forums have different members (i.e. this forum is quieter and more serious, whereas the beryl forums are busier and not so serious :D)

patpi

March 24th, 2007, 10:40 AM

Well, this sounds great. I'm all for reuniting!

me too :) Thumbs up!

But I won't believe it unless i will see this...

rememo

March 24th, 2007, 11:27 AM

also, will the beryl and compiz forums stay ??

If we really want the merge, we will need a new forum at the new project-site.
Compiz will not have any official forum anymore, all discussion will be through mailing-list until David or a core dev decides to put up a forum.
Remember that the merge is based on the idea: Compiz(=core) and "community-project"(=former beryl+former compiz-site) are independent projects (only bridged by community-devs with git-access), whereas "community-project" depends on (and enhances) Compiz, but Compiz runs alone (providing basic composite and window-manager functionality, but for example doesn't burn down windows :) ).
I think the beryl-forums will be kept up for maintenance of beryl-0.2.0, but the new project-site will be the better place for forums. Maybe to make transitions easier mirror the two forums we have now at the new page, but imho it would be better to start with new forums.

since both forums have different members (i.e. this forum is quieter and more serious, whereas the beryl forums are busier and not so serious

Regarding this I think this all depends on a good designed forum layout. I wouldn't want to have two forums with different members from former beryl or compiz. Remember we want to unite the communities.
But maybe it's a good decision to provide two forums at the new site, one for developers, to post plugins/etc. and get technical help (etc. ...) and one for users, to get help using and installing, package-announcements, plugin-announcements, feature-requests and general chatting. This will keep all technical things away from the users (providing a busier and not so serious place :) ) and the devs that need help "free" from many user-posts (providing a quieter and more serious place). Anyways, one could also use mailing-lists for technical discussion but this needs to be decided on by the devs.

mikedee

March 24th, 2007, 01:18 PM

But maybe it's a good decision to provide two forums at the new site, one for developers, to post plugins/etc. and get technical help (etc. ...) and one for users, to get help using and installing, package-announcements, plugin-announcements, feature-requests and general chatting. This will keep all technical things away from the users (providing a busier and not so serious place :) ) and the devs that need help "free" from many user-posts (providing a quieter and more serious place). Anyways, one could also use mailing-lists for technical discussion but this needs to be decided on by the devs.

This sounds like a bad idea to me for a few reasons.

1. The benefit of compiz-quinn forums and these is that users know that they can get hold of a developer, plus it means that ideas flow freely between the 2.
2. There is not enough weight of developers to support an entire forum. The developer forum would die out and the users will be left reporting bugs to each other (does this sound familiar?).
3. Confusion on behalf of the users (ie. which forum should I post my feature request/bug to?)

On the whole subject of a merge. I think that I have personally merged most of the useful code already. I have spent the last 6 months porting plugins and working out the differences so that I could commit patches to compiz. Other people are now doing the same with other programs. The hard work of merging beryl is being done by non-beryl people, the main reason given at the time for not merging back was that it would be 'too hard'.

The idea of merging was put forward right when the fork was announced, but they were too full of themselves to help with the hard work of merging. Now the hard work is done, what do we have to gain exactly? What is the incentive to throw away everything we have spent the last 6 months rebuilding?

I think we have already replaced beryl because they were not interested in working together before, I think its strange that they are only interested now.

I want to concentrate on writing code, rather than constantly chasing our tails and redoing work all the time. I think that the forums here are just about right and why would we want to get rid of them?

If beryl people want to contribute then great, but what should we change everything just to make 3-4 people feel better about what they have done.

Sorry if this is not 'community' enough for you but I have spend a significant amount of time merging beryl and compiz code (with nothing but abuse from them). Now they want to help, but we must change our name and make them 'leaders' before they will do anything. People need to contribute an awful lot more before I think they can have right to be leaders or dictate what happens here.

So far the contribution to compiz from beryl people has been slight to say the least, but we are expected to believe that if we change the name and do whatever they want then suddenly we will have all this amazing software.

delfick

March 24th, 2007, 01:47 PM

good point rememo

a seperate forum would be good

and also good point mikedee

devs and users should share the same forum

though, if this is to be done, it should be done properly

as in we must choose

a) a decent forum software (not phpbb, it is crap)
b) designate forum mods (i haven't been visiting the beryl forums much lately, due to lack of time but before when was always on there, moderators were a rare sight
c) a decent forum administrator (i.e. not nesl :D)

and also after a merge, it'd probably be a good idea to appoint someone as a correspondent between devs and the community, so that the community are made aware of changes to both the code, and to how the users use the code......

right now, the beryl forums have negative communication between devs and users (always has been) and not only does it unnecessarily create confusion...it is annoying...... (especially when bombshells are dropped on us *cough* name change to beryl *cough* (long time ago, i know, but that's beside the point :D

mikedee

March 24th, 2007, 02:06 PM

a) a decent forum software (not phpbb, it is crap)

Yes, we agree too. It has been discussed on the compizadmin list. I think the general consensus of opinion is that there is a lot to do at the moment and we should do that before migrating the forum software. We have some infrastructure issues which we need to sort out in the short-term. The new wiki and forum design will be up soon thanks to Amgeex, RYX and imnotpc, I am sure that once all that is up the attention will move.

b) designate forum mods (i haven't been visiting the beryl forums much lately, due to lack of time but before when was always on there, moderators were a rare sight

We have 4 mods here. I know that I take that responsibility seriously and I move threads and delete spam regularly.

c) a decent forum administrator (i.e. not nesl :D)

imnotpc is doing a very good job IMHO, I am sure that he would like help with some things if people were to offer ;)

imnotpc

March 24th, 2007, 02:36 PM

imnotpc is doing a very good job IMHO, I am sure that he would like help with some things if people were to offer Wink
Thanks mikedee. While mikedee and I have our differences, we've been in the trenches together with amgeex and RYX since the beginning fighting to rebuild. And I can tell you that if it weren't for mikedee we wouldn't be here today.

I strongly support the reunification of the communities for many reasons. I'm in the middle of a big project at work so I don't have time to go into it now, but I'll post my opinion in detail within the next day or so. Regarding the name, when I drafted the description of the project I used Compiz-Extra since that name was already used for some of the code. I prefer that we use a different name to avoid confusion between compiz the window manager and compiz the desktop software, but I think the community should select the combined project name.

Interestingly, there is a poll the Beryl forums about merging. Currently everyone is in favor of merging with votes equally divided between using compiz(-extra) and selecting a new name. http://forum.beryl-project.org/viewtopic.php?f=41&t=5235

Jeff

rememo

March 24th, 2007, 02:53 PM

@mikedee:

This sounds like a bad idea to me for a few reasons.

1. The benefit of compiz-quinn forums and these is that users know that they can get hold of a developer, plus it means that ideas flow freely between the

Yes, I knew about the benefits and thats why I said there could be a plugin-announcement section in user-forum where ideas and feature requests could be posted.

2. There is not enough weight of developers to support an entire forum. The developer forum would die out and the users will be left reporting bugs to each other (does this sound familiar?).

Hmm, I think there would be quite a few developers after a merge. The technical forum would only be used for tech-help. Bugs should be managed through a bug-tracker and not in forum. If not, the plugin-announcement in user-forum could be used.

3. Confusion on behalf of the users (ie. which forum should I post my feature request/bug to?)

Plugin-announcement section as said above. Bugs should go in bug-tracker.
Users should generally only visit the user forum and if they decide to become devs, code some stuff and visit the dev-forum if they want help or to post plugins. It's that easy :)

Regarding your other things.

On the whole subject of a merge. I think that I have personally merged most of the useful code already. I have spent the last 6 months porting plugins and working out the differences so that I could commit patches to compiz. Other people are now doing the same with other programs. The hard work of merging beryl is being done by non-beryl people, the main reason given at the time for not merging back was that it would be 'too hard'.

The idea of merging was put forward right when the fork was announced, but they were too full of themselves to help with the hard work of merging. Now the hard work is done, what do we have to gain exactly? What is the incentive to throw away everything we have spent the last 6 months rebuilding?

I think we have already replaced beryl because they were not interested in working together before, I think its strange that they are only interested now.

Yes, I'm surprised myself to see that they agreed on merging. Anyways, many of the devs wanted a merge for quite a few weeks now. But quinn, as their apparent leader was against it until a newer discussion. So it's not that surprising to see the fast agreemement they've reached now. What we could gain exactly?

A lot of new user base and dev-power by merging the two projects together and an awful lot of not having to port code over or writing redundant code therefore saving time.

As I said throwing all things together that currently work with unpatched compiz (including your work on porting plugins too) at a new site would be a beginning. For sure, beryl devs would have to contribute too.

I want to concentrate on writing code, rather than constantly chasing our tails and redoing work all the time. I think that the forums here are just about right and why would we want to get rid of them?

If beryl people want to contribute then great, but what should we change everything just to make 3-4 people feel better about what they have done.

Sorry if this is not 'community' enough for you but I have spend a significant amount of time merging beryl and compiz code (with nothing but abuse from them). Now they want to help, but we must change our name and make them 'leaders' before they will do anything. People need to contribute an awful lot more before I think they can have right to be leaders or dictate what happens here.

I fully do understand your point. I myself would really like to see everything staying here at go-compiz, using the git-repos we currently have and not renaming. But do you really want to keep the current situation (what will come out, if we don't make a compromise on both sides) if we could have what I've said we could gain above? I don't know what is planned for the leader-structure of a new-project, but I think these are things that can be discussed between the community-leaders (to which you belong too) on both sides.

So far the contribution to compiz from beryl people has been slight to say the least, but we are expected to believe that if we change the name and do whatever they want then suddenly we will have all this amazing software.

Yes, it's a risk. But I think we (current compiz-community) and the compiz-community leaders know what we want. Imnotpc has outlined this in his definition of compiz-extra. A name-change and a new project-site isn't that hard as long as core stays unpatched and clean and this stupid fork ends with the help from both (not only ours) sides! If they don't agree on this then there will probably be no merge.

RYX

March 24th, 2007, 02:58 PM

Maybe delfick is right in that we would need some more moderators as the commmunity grows. If we suddenly have 4000 additional members we mods will definetly have a hard job :) ...

And maybe phpBB is really crap, but I recently looked at its code and all it would need is a plugin/mod which implements a better way of theming it. If the themes were PHP-files (like in SMF/wordpress/mediawiki/...), phpBB would suddenly get way better. The template-engine is kinda odd ...

@delfick: Sorry for being so serious all the time :D:D ... I have some problems to be funny in english, I'm not half as serious as I sound all the time (and I do my best to always to put some smileys into my posts :) ...). I think the problem that you rarely "see" a Moderator is that half of our mods are living on the other side of the globe :D ... I have to stay up really long (or get up very early) to meet you in "real-time" :D ..

:)

mikedee

March 24th, 2007, 03:05 PM

2. There is not enough weight of developers to support an entire forum. The developer forum would die out and the users will be left reporting bugs to each other (does this sound familiar?).

Hmm, I think there would be quite a few developers after a merge. The technical forum would only be used for tech-help. Bugs should be managed through a bug-tracker and not in forum. If not, the plugin-announcement in user-forum could be used.

The mailing list is for developer help. The benefit of using that is that David generally responds to those and doesn't really use the forums much. If you have a simple query it can be posted here, otherwise use the mailing list. This method seems to work well (both at the original compiz.org forum and here)

All of this leads to confusion and duplication of information. Developers do not have enough time to monitor a user forum as well as a developer forum and a mailing list. Users will feel ignored if developers do not post on their forum.

rememo

March 24th, 2007, 03:18 PM

Good point mikedee.
Forgot about the compiz mailing-list :oops: , any developer wanting help with compiz of course should use the mailing-list. So drop the tech-forum! But what about questions regarding new libraries that get introduced by the community-project? We would need a place where developers can get help regarding apps of the community-project I doubt that David wants to answer these questions on compiz mailing list.

mikedee

March 24th, 2007, 03:20 PM

So the question remains...

What exactly do we gain from a merge?

As far as I can see is the main motivation is that everyone stops wasting time and duplication of effort. The main problem is that as I said most of the time wasting has already been done because people did not want to cooperate 6 months ago.

Creating a new site etc etc will just be more wasted effort in my opinion when we could really use that effort to promote compiz and linux in general.

Davids the leader (based on his contribution so far), compiz is the name. Cant we just get down to writing software?

The compiz-extra package is just that... A package. It is there for people to get into distributions easily along with compiz. If anyone has a plugin or piece of software that deserves or needs its own site then I am sure it will happen. Even something like kiba-dock cannot sustain its own forum.

Compiz-extra makes life much easier for packagers and users (especially compared to the massive range of packages available for beryl)

FunkyM

March 24th, 2007, 04:04 PM

This is about "merging back" with the original project, which is named Compiz, a back-merge doesn't force the original project to change it's name (You know? You fork to new project -> new name, You go merge back to original project -> old name; Logic)
The important parts which merge are the communities, not code (that one is almost done, see next point)
A whole load of stuff is already ported (gj mikedee and others on plugins, decorators, tools, ...) and everything should be fixed to run with unpatched compiz
Creating a new forum or setting up stuff from scratch now is obsolete work and totally wasted effort (if you got the time...)
After normalization, Beryl is compiz-extra, if the selection of plugins and tools calls themself Coral, compiz-beryl or remains Beryl is totally irrelevant to Compiz and up to the maintainers of the bundled projects
A merge could mean that the communities receive a common platform for discussion and development (wiki, forum, tracker, ...)
A merge means that plugins and tools are developed to be used with compiz GIT. Core patches are sent upstream, validated and accepted or rejected. I think a couple of Beryl devs have no trouble to understand that this is not a problem nor has that ever been one. Anything else was FUD.
A merge means code-wise to stop duplicated work
Changing the layout of the forum plus WIKI to unify the looks and adapt the new Compiz logo is long overdue. I would be willing to do that in 1-2 days, however even just getting WIKI write access seems like a hard thing (I asked about it a few times).
This is a software project, not religion or similar

Respect for the Beryl guys and everyone involved on moving into the right direction, but please don't try to loose that respect again and learn from the past; avoid wasted efforts/black-hole productivity.

karmapolice

March 24th, 2007, 04:18 PM

I've been using compiz for a while and even was informed about the fork before it happened to create a theme for emerald and the only reason I received when I asked why was the one all we know: the not accepted patches.

I used beryl for a while and then came back to compiz and really the only difference at least at first sight are the extra plugins so I think it's a good idea to keep the compiz name at least for the core and maybe rename compiz-extra to something else.

About the forums I think that it would be enough to maybe add more categories in this forum and add a bug tracker so common users like me could report bugs eventhough sometimes this isn't a good idea because a lot of users think that if they cannot compile it it's a bug or they duplicate bugs.

rememo

March 24th, 2007, 05:07 PM

Maybe there is some misunderstanding lately here, as imnotpc drafted:

1."official compiz", compiz-core (basic compositer and window manager features, with a few plugins): uses go-compiz.org wiki and compiz mailing list
Function during merge:
-> never ever will get renamed during a merge, but gets new patches from beryl to support compiz-extra (allready mostly done by mikedee)

2."community compiz", compiz-extra (all other plugins, decorators, etc. not essentially needed): uses go-compiz.org forum and git repos (rock3d and go-compiz ones)
Function during merge:
-> gets all plugins and apps from beryl, ported where possible without patching core (allready mostly done by mikedee), but currently not up2date that's why a merge would be nice
-> maybe rename for the sake of a merge (with beryl-forum), and use new forum and repo-site as beryl-devs demand this

Using go-compiz.org-forums and git for compiz-extra during a merge as drafted by imnotpc definitely should be the way to go. But you won't get all beryl-devs to accept this (i.e. quinnstorm! ) and then really work for and cooperate with compiz-extra. So the compromise for reunitig is to choose a new name and forum/repo-site. I know this is stupid in the light that beryl forked from compiz, but what is the alternative: keeping the fork alive or hoping that sometimes they change their mind (you will know best that they won't do this even after lengthy discussions)? If we now have the chance to unfork and double powers, should we just let it pass?
I really would like to see keeping current compiz infrastructure, but as I said we won't get them to accept this.

BUT: ... in the end maybe you're right if we want to do a merge we should insist on doing it right, by going back to where this fork began: towards a compiz named community site.

nightfrost

March 24th, 2007, 07:45 PM

This thread has been a very interesting read. After reading I must say agree that compiz should keep its name (due to the various reasons mentioned).

However, I don't see why compiz-extra can't be renamed beryl? Isn't that almost how the case is now? The core is compiz, all extra plugins are beryl. This way end-users install compiz, and if they want they can extend its functionality with additional plugins by using a package called beryl.

In the end there's a choice between a "solo" compiz package, or a "beryl-powered" compiz package.

But I think the name compiz should stay (although I didn't really like it from the start).

Edit: By the way, I just read the poll thread over at beryl's, and I must say I definitely agree with delfick; coral is one of the worst names that I can think of for this project...

mikedee

March 24th, 2007, 08:00 PM

However, I don't see why compiz-extra can't be renamed beryl? Isn't that almost how the case is now? The core is compiz, all extra plugins are beryl. This way end-users install compiz, and if they want they can extend its functionality with additional plugins by using a package called beryl.

Errr.... A lot of the plugins in compiz-extra are not in beryl at all. Mousegestures and winrules are the ones that spring to mind. David will also include some of his core plugins into it.

It also depends on how you class a beryl plugin. Most of the plugins that I ported originally were written for compiz(-quinn) not beryl.

In case nobody noticed, there are plugins (and other software for compiz-extra) being produced over here too.

Oh, I do not think coral is the worst name ever... Beryl was the worst name ever.

imnotpc

March 24th, 2007, 09:10 PM

It seems like we've been discussing the possibility of reuniting since I got here, and probably since the fork itself. There were always serious differences that just couldn't be overcome. As I said earlier, most of those differences are either gone or irrelevant now. We still have a lot of things to work out, but reunification is within our reach. I brought it up here because I think it benefits our community, the Beryl community, and the Linux desktop in general.

Here's a few of my thoughts on this:

- The definition and goals of Compiz-Extra and Beryl are nearly identical. Both projects will be based on the compiz core, have interchangeable plugins, and similar goals. Without reunification there would be a huge amount of effort spent on pointless duplication of infrastructure and effort. With reunification, we eliminate duplication and can use that effort productively.

- Each community has a solid group of active developers. Compiz is stronger with core development, Beryl has lots of skilled plugin developers. Together we have 20-25 dedicated developers working on Compiz related projects. How many open source projects have assembled that much talent together in only one year? It may take a month or two to fully integrate the projects, but once we do the sky is the limit.

- There's been a lot of emphasis put on what name we would use and why. I used the Compiz-Extra name when describing the definition of the project because we were already using that name for a package and the Managing Committee couldn't agree on a name for this division. I think this post describes it best: http://forum.go-compiz.org/viewtopic.php?p=5611#5611

Personally, I think it's important to differentiate between compiz the compositing window manager, and compiz(-extra) the user space package, and I would vote to change the name whether we reunite or not. I like the <shameless plug> Rock3d </shameless plug> name, but I think the (combined) community should select the name.

- We haven't even discussed management structure yet, so let's not make decisions based on that. Compiz is a meritocracy and I think Beryl is too. In other words, those that contribute the most and the best, get to make the decisions. I believe that once we all start working together it will quickly become clear who has the gravitas to merit authority. I'm making a standing offer to step away and let a qualified Beryl member take my place if that serves the greater good. The future of the Compiz community is far more important than my ego.

- Aside from the internal benefits of reuniting, there is a substantial external benefit. The publicity generated by combining the projects will be tremendous. As it is now every statement by Beryl or David makes the news wire. Announcing a reunited project will bring in even more users, more developers, and further the goals of both communities.

And finally, I think we need to look at the future of the Linux desktop. The Linux desktop has had very little success against MS and Mac. Both KDE and Gnome are solid, usable, desktops that are functional, stable, and... boring. I've been using KDE and Gnome desktops for more than 5 years now. Not once have I ever had a Windows user look at my desktop and say "That's really cool. Can I have that?" Until Compiz...

When I first used Compiz, I thought: "That's amazing!". When I first used Beryl, I thought: "That's unbelievable!". Until I closed the session and could never get it back. That's when I knew that somehow we needed to build a project which combined the solid base of Compiz and the effects of Beryl. Thanks to mikedee, compiz has a lot of those effects now. But we can do so much more.

I believe that Compiz/Beryl is the break out technology that will put Linux on your grandmother's desktop. With our combined efforts we have an opportunity to bring Linux to the masses. Am I dreaming? Maybe. Time will tell. But there is one thing I can predict with confidence. That a combined Compiz/Beryl will get us a helluva lot closer than either project on it's own.

Jeff

apoclypse

March 24th, 2007, 10:12 PM

This will also help the distros out as now they don't have to choose or support either compiz or beryl. I think that the Beryl community has done incredible things with their project. My issue with them was based more on politics and how they handle things with the compiz core. I wouldn't mind the projects merging and the possibility of a new name. Th name change will be good. It will show that both sides are united and have compromised to get this unification. Leaving the name as compiz-extra will seem to the community that beryl "lost" and the beryl community might not like that. Beryl has a hardcore following and that is due to the devs being very responsive to users, whether with requests or just general help. The go-compiz forum is very quiet and low key, that may be due to a smaller community. I'm personally for the merge as I didn't agree with the fork in the first place.

delfick

March 25th, 2007, 12:04 AM

This is a software project, not religion or similar

exactly :D

name isn't important :D

also, i say once all merging is done, then we have community "competition" to design better forums

i.e. criteria such as

a) forum software
b) forum organisation
c) forum artwork (and then expand the artwork to cover bug tracker, wiki, blogs, etc :D

but only after everything is sorted out (in meantime we continue using the two forums.....and then when we decide the criteria above, merge both forums into one....makes sense to me :D)

mp3geek

March 25th, 2007, 03:20 AM

With both Beryl and Compiz using different licenses, what license will the new project be using?

RYX

March 25th, 2007, 03:29 AM

Hi mp3geek! I'd say developers are free to choose any license for their work and the project shouldn't dictate them which one that is. I can see no problem with the plugins or additional apps having different licenses than the core. As far as I know compiz itself will stay MIT-licensed like xorg.

:)

lowfi

March 25th, 2007, 04:01 AM

Yes, every patch that goes into compiz core will be MIT and every plugin, weather it'll be included into the fd.o repo or not, will have the license the author chooses.

OpenGLCoder

March 25th, 2007, 04:47 AM

Compiz/Beryl Teams,

First off, I'd like to say that I think both teams have done simply amazing work. I really hope that the merge is pulled off correctly. Since both projects have so much momentum behind them, this may be an opportunity to build something beyond an accelerated window manager. What is an accelerated window manager that doesn't provide a platform for applications to leverage and the 3D acceleration available on the platform? If the code concepts ("3D" control picking and management, etc...) available through this project could be exposed and abstracted for developers, it would really give "3DX11' a huge boost for adoption. For example, instead of having to manually initialize an OpenGL window and manage virtual controls like pinpoints on a map with dragging and selecting like in Google Earth, this project could use it's knowledge and code library to create a reusable PLATFORM to aid in the adoption of such technologies - cause lets be honest, most business developers aren't up to these kinds of programming tasks - and those are the ones who ultimately determine the success of technology X.

A premature thought? Probably.

OpenGLCoder

Amaranth

March 25th, 2007, 04:55 AM

I think you're looking for clutter (http://clutter-project.org). :)

OpenGLCoder

March 25th, 2007, 06:35 AM

Clutter - kind of. Clutter seems to be friends to the GNOME libraries and technologies. It gets back to my point of platforms. Since talks of merging are out and about - why not throw in the possibility of collaborating with the Clutter people to develop some kind of baseline integration or hooks for the window manager and controls integration and theming? If I write a GLSL shader for effect X in Compiz/Beryl, can my clutter application use that shader seamlessly?

When you learn Windows programming, you've learned Windows programming - and you can start solving business/users' problems. There really isn't an end to learning OSS programming - so people tend to spend a lot of time spinning their wheels weighing the cost/benefit of developing for a million different hogde-podges of software configurations and API/language bindings

Don't get me wrong - choice is good... but doesn't bring a single sale for an ISV relative to developing for an industry agreed upon solid standard.

Please - I didn't mean to offend anyone with my observations - so don't take it as such... I just really believe these projects can enhance the X11 standard and do really great things.

Greatness does not need to be defined, and greatness does not need to be explained. That baing said, I think the great work that the Compiz/Beryl projects have done speaks for itself.

RamRod

March 25th, 2007, 08:02 AM

My 2c from a random Compiz and Beryl user:

- Compiz should NOT CHANGE ITS NAME. It just doesn't make logical sense given Beryl wouldn't exist if it wasn't for Compiz.
- Coral/Beryl/Whatever should exist as a tree of Compiz.

All in all, I find it ridiculous how socially inept some programmers can be. Especially a lead programmers from Beryl. There's enough duplication in the OSS world as it is, it's a pity usually the brightest programmers in OSS are usually the most socially retarded, which undermines their efforts in the first place.

Hopefully the merge happens, at least on the code level if nothing else.

Kevin

March 25th, 2007, 08:58 AM

Agreed, it makes no sense to change any names here...

The community here has put tons of work into making the beryl plugins work with compiz, and it shows that everything that beryl does can be done with minimal changed to the core. When changes to the core are needed, which is rare, David is quite helpful and open to discussing how the changes should be made.

If beryl wants to merge back to compiz, that makes a lot of sense, as everything that they do is possible with compiz. They should just take their plugins, make sure they work properly with compiz, and have a beryl package that depends on compiz. It would work beautifully as a program that just extends the functionality of the compiz core program.

Also, then they can have their name, compiz keeps its, and everyone wins. Beryl becomes a place where people can develop plugins to add to the Beryl extension of compiz, and the compiz forums become a place where people can help extend the functionality of compiz, and where people can create plugins that they believe are useful enough to be included in the official compiz-plugins.

I'll outline some of the benefits of this approach1. Everyone keeps their names for their projects
2. Users get compiz installed by default in their distributions, they get a composited desktop, and they don't notice any changes other than that
3. Users can install beryl, they get ALL of the plugins developed by the beryl community, and they get configuration programs to tweak things all they like
4. Users can also take a single plugin that the beryl package includes, and it works fine on their compiz, without having to install all of the beryl plugins that they may not want
5. Both of the great communities, with many dedicated users, get to continue moving in their direction of choice.

Anyways, thats what I'd like to see happen, and I see no reason why anyone could be all that unhappy with it. And if someone does happen to be working on a plugin that needs changes to core, they don't release it as part of the beryl package right away, and they open a branch of the compiz. Then they can work out the kinks of their changes to core, get other developers to look over it, and then hopefully merge it into main compiz, at which point they can include their plugin in the beryl package!

imnotpc

March 25th, 2007, 09:16 AM

@Kevin: I think what you are describing is essentially the situation we would have without merging. Beryl has already decided that they will base the next version of Beryl on the Compiz core. This is itself great news for all involved. The benefit of reuniting is that with one site and one set of packages we can go a step further and eliminate the duplication of effort and confusion that occurs when you have two packages that do essentially the same thing.

Kevin

March 25th, 2007, 10:54 AM

Well if we're talking about merging sites, then I can support that of course. There's no point in putting in all the effort of running two different communities with very similar goals.

As far as merging the projects though, I just don't think we should be changing much at all on the compiz side. The plan, without beryl involved, was merely to start moving some of the less important plugins from official compiz to compiz-extra and vice versa right? If beryl uses compiz as its core, then we could simply introduce another package of plugins called beryl, and move useful plugins into compiz and out of beryl if everyone decides to do it. But I was under the impression that without a merge, beryl would rebase on compiz, but then continue patching it again, like the beryl 2.0.0 cycle. This is not good because then we once again have the plugin compatibility problems we've been dealing with.

Basically, the way I see it, is compiz-core, compiz-plugins (the core plugins essential to compiz), compiz-extra (plugins from compiz-plugins that aren't really all that needed), and then beryl, which consists of current compiz-extra (the ones that came from beryl anyways) and any other plugins that the beryl community produces.

maniac

March 25th, 2007, 11:24 AM

First, I'd like to apologize if parts of this posting may sound harsh or something like that, but I really feel it needs to be expressed that way.

On the whole subject of a merge. I think that I have personally merged most of the useful code already. I have spent the last 6 months porting plugins and working out the differences so that I could commit patches to compiz. Other people are now doing the same with other programs. The hard work of merging beryl is being done by non-beryl people, the main reason given at the time for not merging back was that it would be 'too hard'.

You must be kidding :shock:
You were one of the first who complained that Beryl got credits for porting Compiz core additions/improvements, and you were absolutely right about that. But now you come along and say "Hey, Beryl is obsolete, I ported their plugins". As well as the credits for core code should go to the original developer (David), credits for plugins should go to the original developers, too (Beryl devs) and not to the one who ported it. I realized that while porting group: Porting it needed 2 or 3 hours, writing it needed magnitudes of more time.

The idea of merging was put forward right when the fork was announced, but they were too full of themselves to help with the hard work of merging. Now the hard work is done, what do we have to gain exactly? What is the incentive to throw away everything we have spent the last 6 months rebuilding?

You say all you did in the last 6 months was porting Beryl plugins? If that was true (I know it isn't) - wouldn't that be a little poor?

I think we have already replaced beryl because they were not interested in working together before, I think its strange that they are only interested now.

See above. You haven't replaced Beryl by porting plugins - if Beryl wouldn't have produced any plugins, you wouldn't have had anything to port. BTW - the compiz-extra package only exists for Ubuntu, and there are some Linux users in the world not using Ubuntu.

Errr.... A lot of the plugins in compiz-extra are not in beryl at all. Mousegestures and winrules are the ones that spring to mind. David will also include some of his core plugins into it.

What else besides these two? ;-)

It also depends on how you class a beryl plugin. Most of the plugins that I ported originally were written for compiz(-quinn) not beryl.

Honestly, I never noticed you stopped porting plugins at the point compiz-quinn was renamed to Beryl.

In case nobody noticed, there are plugins (and other software for compiz-extra) being produced over here too.

The perception problem is because the vast majority of compiz-extra are ported Beryl plugins (of course without ever sending back patches). That's why the plugins you wrote don't get the audience they could. But that could be solved with a merge. Everyone would get the audience he deserves.

I want to concentrate on writing code, rather than constantly chasing our tails and redoing work all the time. I think that the forums here are just about right and why would we want to get rid of them?

Yes, writing code is a way better idea than constantly having to port code forth and back. That's one of the main reasons why this merge idea exists. More on that in the next section...

What exactly do we gain from a merge?

- We don't have to merge code back and forth
- The users don't need to decide between multiple composite WMs, they get all to the price of one.
- This silly "person X gets credit that person Y deserves" game would stop

These three items are absolutely sufficient to me to think that a merge would absolutely make sense.

Sorry if this is not 'community' enough for you but I have spend a significant amount of time merging beryl and compiz code (with nothing but abuse from them).

"Abuse from them"? You weren't polite to ALL of the Beryl devs, to say it mildly, even to those who joined Beryl way after the fork (and that's 80% of the developer base, BTW).

Now they want to help, but we must change our name and make them 'leaders' before they will do anything. People need to contribute an awful lot more before I think they can have right to be leaders or dictate what happens here.

Nobody wants to dictate anything. But some of the Beryl people already HAVE contributed a lot more code to Compiz than certain members of the committee. Isn't it fair that these people (namely: onestone - and he never cried for being a 'leader') have something to say in a new project?

All in all, your statement are a clap in the face of the Beryl developers who really want a merge, (especially racarr, me, onestone, iXce) sorry to say that. If you don't want to cooperate, please tell us - but I believe the current situation is a lose-lose situation for everyone involved. And please stop treating Beryl developers as a bunch of brainless idiots just because we happen to be involved in the in your view wrong project - we are just developers like you, too, and I think everyone should get a little respect for what he does, especially as you receive credits for that work. :cry:

Apart for that stuff, my idea of a merge would be the following:
- Have a shared source repo where all stuff would be hosted
- Beryl developers would port their plugins to Compiz core and host it in that repo
- I'd rather not like to see the current compiz-extra ported Beryl plugins there - some of them are outdated, and in general I believe that the plugin writers know best how to port it.
- Additionally, of course all the compiz-extra plgins should be hosted there , too (winrules, mousegestures, ...)
- All the stuff would be maintained by the respective author
- Some categories for packaging could be created (stable and maintained / unstable, but maintained / unmaintained)
- How that stuff would be named does not matter at all to me
- Where it should be hosted is something iXce and imnotpc should agree upon - as administrators, they should know it best

As a last word, I'd like to thank David and Jeff (imnotpc) for their constructive answers and stements which make me think that a merge would work even though there are statements like the ones quoted above. :)

stjepan

March 25th, 2007, 12:13 PM

So much discussing...
I don't want to interrupt, but are there any expectations when will the merging start?

shame

March 25th, 2007, 12:14 PM

I'm in full agreement with maniac.
One of the main things concerning me is that when the projects are merged it may descend into the developer in-fighting that has plagued debian and especially gentoo if there are disagreements on how things should be (and no doubt there will be disagreements).
I use both beryl and compiz and am completely neutral. I have noticed quite a bit of animosity between both communities, particularly compiz against beryl.
The hacking incident springs to mind and mikadee in particular, clearly has a disturbing hatred of all things beryl.
I admit I haven't seen every post he's written but in virtually every post I have seen he is bashing beryl in some way.
All this goes way beyond the usual "kde is better than gnome", "playstation is better than xbox", "my dad can beat-up your dad", "united are better than wednesday" (it's a sheffield thing) rivalry that you get everywhere.

I also hope there will be less emphasis on ubuntu and suse, not everyone uses them.

But to me, the single biggest issue is losing beryl settings manager, unless this is also merged into the new project. If I have to use gconf for configuration, as I have to with compiz currently, I think I'll just go back to a regular boring desktop.

iznogood

March 25th, 2007, 12:25 PM

i say let the developers do what they want.
They have showed a very mature attitute especially when politics (QuinnStorm) stays out of the way(or is forced out of the way maybe ????).
At least this is how is looked to me when i read the discussion on beryl-ML.

It also seems that they do not care too much about the name and such. All that is not important, people who contribute are mentioned on git and authors-file and the rest is just a waste of precious time

Let them work without distructions , they seem to communicate with david pretty well lately

iXce

March 25th, 2007, 12:54 PM

rememo

March 25th, 2007, 01:01 PM

@iznogood:
Well the whole discussion here is about the future of both communities (including forums and such, not compiz-core!!!) so everyone should make his point. It would be nice to see the beryl-devs not caring to much about the name as that would mean we could merge here. I also think that David really doesn't care what name the community chooes, as long as beryl stops the fork of the core and that's what they've already decided to do.

@maniac, shame:
I think mikedees post was a little personally motivated. I've seen the reactions of iXce and other members of compiz-quinn on mikedees posts to correct the mispread information about the reasons of a fork, back in the old forums. They called him a troll and to STFU. And I think everyone agrees that the reasons for a fork of the core were simply not true and a little personally motivated. A community-site could have been build up with providing plugins, instead of touching core (because most plugins worked with compiz-core as the porting shows!). Also I didn't understand why every new developer decided to write plugins for beryl-core instead of compiz-core. So you also must have agreed with the (unneeded) fork and that's why mikedee wasn't polite to all of you new devs. Between Kristian wasn't also very polite, especially to David ;)

Anyways, I wouldn't want to warm up old stories and I'm saying this to everyone here (compiz and beryl devs). It was just to explain some of mikdees reactions to others that don't know the whole story. I also wouldn't want to see any quotes and then personal sights on this in replies, we have to decide on more important things.

So to come back to topic and sum it up we have 3 alternatives to decide on:
Note that a merge only affects community-compiz aka compiz-extra (go-compiz-forum, compiz-extra package, git://go-compiz) official compiz (compiz-repo @ fdo, mailing-list @ fdo, go-compiz wiki) stays compiz as said thousands of times.

1. Merge both communities under a new name and site:
What has to be done?
- decide on name
- decide on leader structure
- decide on scope of project (mostly done)
- build up new site with forum, blog, bug-tracker, wiki
- set up new repos
What could be used that is already there?
- use rock3d infrastructure
- use beryl-project infrastructure: but maybe needed for maintenance

Pros:
- actually the merge will happen (you know the pros)
- better distinction between compiz-fdo (the basic window/compositing manager for all DEs) and apps/plugins/decorators from the community that enhance it
- easier for distribution
- both communities are treated equally
Cons:
- setting up new community takes time
- all efforts put into go-compiz-site/forums will be lost
- all efforts put into beryl-projects-site will be lost

2. Merge bot communities under go-compiz-forums and git://go-compiz as compiz-extra:
What has to be done?
- decide on leader structure
- decide on scope of project (mostly done)
- design new site with forum, blog, bug-tracker, wiki
What could be used that is already there?
- go-compiz infrastructure

Pros:
- new community will be up soon
- easier for distribution
- keep efforts put into go-compiz-site/forums
Cons:
- the risk that a merge won't happen because some beryl-devs insist on new site and name
- all efforts put into beryl-projects-site will be lost
- no clear distinction between compiz-fdo and compiz-extra
- beryl community feels treated unfair

3. Don't merge communities at all. Keep compiz-extra community and beryl-community both basing their enhancements on compiz-fdo:
What has to be done?
- Nothing on our site

Pros:
- no efforts will be lost on both sides
- no new time is needed
- both communities are treated equally
Cons:
- the merge won't happen, leading to doubled efforts, porting, flame-wars, no proper-credits etc.
- not easier for distribution, hindering apps to reach the end-user
- no clear distinction on our site between compiz-fdo and compiz-extra

Any other solution, pros, cons I've missed. I would vote for 2. but I'm also fine with 1. especially to let both communities feel treated fair...
To further a decision in reasonable time, perhaps we should have a poll to get to know which of the above three scenarios most of the compiz users would prefer. Just a thought...

mikedee

March 25th, 2007, 04:41 PM

But to me, the single biggest issue is losing beryl settings manager, unless this is also merged into the new project. If I have to use gconf for configuration, as I have to with compiz currently, I think I'll just go back to a regular boring desktop.

Third party softwares will be merged at one point. beryl-settings will have to be adapted to the future settings handling stuff (currently known as libbs), but it won't get lost

I spent a week writing the ini plugin so that people will not have to use gconf. There is no reason that BSM could not be changed to work without libberylsettings. Instead it could use dbus to change the internal values and you would not need to link compiz to a settings library.

maniac

March 25th, 2007, 04:42 PM

@maniac, shame:
I think mikedees post was a little personally motivated. I've seen the reactions of iXce and other members of compiz-quinn on mikedees posts to correct the mispread information about the reasons of a fork, back in the old forums. They called him a troll and to STFU. And I think everyone agrees that the reasons for a fork of the core were simply not true and a little personally motivated.

Well, I don't want to warm up the old stories, too. Only one thing: Mike's wording is ... err ... aggressive. If you use such wording, you must be prepared to get responses with the same wording, including being named as troll.
About the fork reasons: Of course they were personally motivated to a large degree, but not only. Example: http://lists.freedesktop.org/archives/compiz/2006-June/000281.html (does Compiz now use Xinerama or not?)
That's everything from me regarding old stories.

Also I didn't understand why every new developer decided to write plugins for beryl-core instead of compiz-core. So you also must have agreed with the (unneeded) fork and that's why mikedee wasn't polite to all of you new devs. Between Kristian wasn't also very polite, especially to David ;)

I became Beryl dev because it 1. simply was easier to become one and 2. it simply was more convenient having everything in one single repo. That's all.
I don't consider that a reason to attack ALL Beryl devs personally. The vast majority of the Beryl devs NEVER attacked Mike personally, so I expect it is the same in the other direction - especially as we are supposed to work together.

Anyways, I wouldn't want to warm up old stories and I'm saying this to everyone here (compiz and beryl devs). It was just to explain some of mikdees reactions to others that don't know the whole story. I also wouldn't want to see any quotes and then personal sights on this in replies, we have to decide on more important things.

Well, we should really avoid to warm up old stories, right, but we also should stop personal attacks (see above).

So to come back to topic and sum it up we have 3 alternatives to decide on:
Note that a merge only affects community-compiz aka compiz-extra (go-compiz-forum, compiz-extra package, git://go-compiz) official compiz (compiz-repo @ fdo, mailing-list @ fdo, go-compiz wiki) stays compiz as said thousands of times.

1. Merge both communities under a new name and site:
2. Merge bot communities under go-compiz-forums and git://go-compiz as compiz-extra:
3. Don't merge communities at all. Keep compiz-extra community and beryl-community both basing their enhancements on compiz-fdo:

For completeness, you are missing
4. Merge bother communities under Beryl forums and GIT

You say that's not possible? Then we should scrap 2. as well ;)

Any other solution, pros, cons I've missed. I would vote for 2. but I'm also fine with 1. especially to let both communities feel treated fair...
To further a decision in reasonable time, perhaps we should have a poll to get to know which of the above three scenarios most of the compiz users would prefer. Just a thought...
My preferred scenario would be 1. ... you listed the reasons for yourself - that way both communities would feel treated fair, which I think is important.

mikedee

March 25th, 2007, 04:53 PM

I think we have already replaced beryl because they were not interested in working together before, I think its strange that they are only interested now.

See above. You haven't replaced Beryl by porting plugins - if Beryl wouldn't have produced any plugins, you wouldn't have had anything to port. BTW - the compiz-extra package only exists for Ubuntu, and there are some Linux users in the world not using Ubuntu.

Compiz-extra is released as a tarball - I think beryl people are the ones obsessed by Ubunutu.

It also depends on how you class a beryl plugin. Most of the plugins that I ported originally were written for compiz(-quinn) not beryl.

Honestly, I never noticed you stopped porting plugins at the point compiz-quinn was renamed to Beryl.

I STARTED porting plugins back the day the fork was announced. There was loads of talk from iXce and Quinn about how the plugins would no longer work in Compiz. I decided to prove them wrong by porting them back.

"Abuse from them"? You weren't polite to ALL of the Beryl devs, to say it mildly, even to those who joined Beryl way after the fork (and that's 80% of the developer base, BTW).

Since you were not there at the start, you will not remember me being told to piss off whenever I mentioned merging back to compiz.

The forums were deleted so you will not see all the abuse that we all received at the start. The fact that you joined after means that you have no idea how hard I tried to merge these 2 projects AT THE START. I told iXce that the plan would not work and exactly how I would stop them. Its a shame they were all too full of themselves at the time.

Now it looks like you guys want to merge back because you realise that David severely out classes all of you and even with all your developers, you cannot beat him (remember the competition is good mantra from quinn?).

maniac

March 25th, 2007, 05:06 PM

Compiz-extra is released as a tarball - I think beryl people are the ones obsessed by Ubunutu.

I don't believe that we are "obsessed by Ubuntu". Personally, I even use FC6.
Where can I read about the compiz-extras tarball? Is there a gitweb?

Now it looks like you guys want to merge back because you realise that David severely out classes all of you and even with all your developers, you cannot beat him (remember the competition is good mantra from quinn?).
Mike, honestly, what do you want to achieve here? Do you want to work with us and stop this silly code porting in both directions and concentrate on working on the code base instead, or don't you want to do that?
I don't think any personal insults help here, any I also think that skill comparisons in the way you put them up also don't help at all as every developer has his skills at different things.
And please stop quoting Quinn when you are talking to me - I neither am Quinn nor do I speak for Quinn.

maniac

March 25th, 2007, 05:08 PM

I spent a week writing the ini plugin so that people will not have to use gconf. There is no reason that BSM could not be changed to work without libberylsettings. Instead it could use dbus to change the internal values and you would not need to link compiz to a settings library.
Is there a decent settings manager for Compiz? I doubt many people want to configure their WM by editing text files by hand.
BTW, you would need to link the settings plugin against a settings library, not Compiz.

lupine

March 25th, 2007, 05:25 PM

Mikedee: offline editing of options without dirty hacks, remember... :)

libbs is being reimplemented as a plugin anyway, so the choice goes to the users. Where it should be, of course. Oh, and - erm - beryl released tarballs also. I took up doing the debian and ubuntu repos to make life easier for the users (and myself, of course ;) ). It's probably one of the reasons beryl became more popular than compiz, and IMO it'd be a good thing to keep doing in any new project (vanilla repos aren't unheard of among other projects, either...) - although getting stuff into official distro repos is also important.

I've always done my best to be civil to you, though heavens know it's difficult at times. But asking for a new name isn't unreasonable - claiming that the hard work has all been done is patently untrue. Chill :)

/Nick

iXce

March 25th, 2007, 05:39 PM

The forums were deleted so you will not see all the abuse that we all received at the start. The fact that you joined after means that you have no idea how hard I tried to merge these 2 projects AT THE START. I told iXce that the plan would not work and exactly how I would stop them. Its a shame they were all too full of themselves at the time.

Now it looks like you guys want to merge back because you realise that David severely out classes all of you and even with all your developers, you cannot beat him (remember the competition is good mantra from quinn?).
It worked, because David wasn't working on Compiz anymore. Since the fork he has been working on it fulltime. Anyway I've learnt that you are always right so yeah, Beryl devs are just script kiddies that can only insult others. Yeah. Now let's wait for David's reply and stop _insert appropriate word here_.

imnotpc

March 25th, 2007, 05:40 PM

We should focus on the present and only discuss issues that are relevant now. There's been lots of bad blood in the past. Let's leave it in the past.

Jeff

RYX

March 25th, 2007, 05:57 PM

Concerning the missing settings-manager for compiz: That is a weak argument. There is compiz-settings and gnome-compiz-manager and I am working on another tool for more advanced users ... Honestly - is writing a settings-tool that difficult? Instead of writing pages and pages of nitpicking discussion you all could instead fire up your editors and write a small config-tool in python. One where everyone can take part in its development to make it totally ass-kicking ... not another one written in C (and please dump bsm, libberylsettings and all that or make bsm use dbus - for everyone's favor).

And to make one thing clear: a new name and merging stuff doesn't make us united, unity starts in the heads (I guess germans know the pros and cons of re-uniting pretty well). If everyone wants to act for his own interest we will get nowhere. I personally say: no name change.

:)

rememo

March 25th, 2007, 05:58 PM

@maniac:

Is there a decent settings manager for Compiz?

Hmm, I think compiz-settings-manager is communicating through dbus with compiz. I don't understand why there needs to be a libberylsettings. Write your settings application in any language with dbus-bindings you want. Communicate with compiz through dbus to change settings, the ini backend will write changes to file, compiz loads settings from file on startup. What is the benefit of this library? (This is an honest question)
I knew your fourth suggestion would come, but I didn't include it because beryl stands for a fork of compiz-core (the original project you know). Whereas go-compiz doesn't stand for a fork of beryl.

@mikedee:
We won't have benefits from talking about the same old things over and over again. I think the beryl-devs have proven enough, that they want to unfork and merge the project for the benefit of compiz as a whole. Please read the mail from racarr at beryl-mailinglists, I would say what they have done is open revolution :) against quinn who wanted to keep the fork.

lupine

March 25th, 2007, 06:23 PM

mikedee

March 25th, 2007, 06:31 PM

We won't have benefits from talking about the same old things over and over again. I think the beryl-devs have proven enough, that they want to unfork and merge the project for the benefit of compiz as a whole. Please read the mail from racarr at beryl-mailinglists, I would say what they have done is open revolution :) against quinn who wanted to keep the fork.

To me, looking at the mailing list it seems like they do not want to help us, they are just tired of wasting time and duplicating effort. To say you want to help us is one thing. But to say we will help you, but only if you change your name and make some of us your leaders is another matter. Quinn seems most interested in getting beryl into ubuntu and only worries about how the merge will affect that.

In my opinion people should prove themselves before anything should be done. The whole problem with beryl was that they promised the world at the start but didn't really have a plan on how to achieve that. The same applies here. Lets see something concrete before getting excited.

rememo

March 25th, 2007, 07:11 PM

Alright, thanks for the explanation lupine :D . I see the problem now.

The major drawback I see is to maintain another library and to not have native dbus bindings.
Hmm, but as you mention a daemon for libbs, to get dbus bindings. Wouldn't it be possible to write one that listens to dbus calls for compiz, and when it's not running writes the changes back to the ini and gconf files (I doubt that there should be more settings backends). This way the application could start the deamon, when compiz is not running. But anyway the daemon would also have to be maintained. But it seems less complex to me than a daemon and a library. I'm not that good in the whole settings system, so this might be a stupid suggestion.

And sorry for getting off topic.

@mikedee:

they are just tired of wasting time and duplicating effort.

Aren't we too??

Lets see something concrete before getting excited.

- animation plugin ported to compiz (I know, you know this) by cornelius
- group plugin ported to compiz by maniac
- maniac and onestone sended some patches to core
- sended email to david, they probably wouldn't do that if they weren't honest
- maniac made changes to let emerald work with compiz

I know it's not that much, but it's a start. With a sceptic attitude we will only hinder new patches and help coming from them. For sure I wouldn't like to see a new name and I really don't understand what's it that makes them to insist on this (probably because of the community and personal feelings). But making insults they aren't honest in their intentions is simply counterproductive in this discussion.

imnotpc

March 25th, 2007, 07:23 PM

mikedee

March 25th, 2007, 07:34 PM

rememo: the issue comes when you want to change settings while compiz is turned off. Using dbus, you can get a stripped-down binary (well, it'd need to have a good chunk of the plugin loading architecture currently in compiz, so not /that/ stripped down...) to fire up as needed by dbus, but... yeah. Doesn't that seem less elegant than a dedicated library?

Settings app -> dbus -> compiz -> backend

Settings app -> libbs -> backend

I think the major problem with the libbs method is that (as far as I know) it is actually responsible for loading plugins (maybe just into itself) as well as coping with the actual option values.

This means that you have 2 code paths for loading plugins which will complicate debugging and error reporting.

In my opinion the changing-options-whilst-off problem can be solved by moving just the plugin loading and reading code into a separate library, this library could first be integrated into the core and checked to see it runs well. Once this is done it will be possible to write a very small binary which can be run automatically by dbus if compiz is not running (this is all built into the dbus spec).

I think that libbs is thinking far too close to home. Using dbus is much more friendly for non-compiz related apps because they are using standard protocols and libraries. You do not have to depend on libbs which has a high chance of not being installed. I very rarely see reports from people these days indicating that they do not have dbus installed.

If you really do not want to run dbus-daemon (which 99% of people will be without thinking) then there is an alternative called fs which uses fuse to mount a virtual filesystem which can be read or written with standard file tools. If the plugin loading library was well thought out then this method could also be made available offline.

I think the 'new' libbs method you pointed out only shows one app communicating. If there are internal changes to options or an app does use dbus then there is much more involved for the libbs method. An internal change would look like this.

Other plugin -> compiz -> bs plugin -> libbs -> backend

and a settings change from BSM is actually like this

BSM -> python libbs bindings -> libbs -> backend -> ?some way to update compiz internal state (plugin? reload?)

mikedee

March 25th, 2007, 07:45 PM

Mikedee, they've been actively adding to the compiz core, actively porting plugins, and spending more time on our forum than on their own. What more can they do to show they are serious about contributing?

No I think they are serious about contributing, those that do will gain respect and power (if they want it). All I am saying is why do we need to change any name in order for them to do that? We have changed everything they were unhappy about and listened to their every need. There are more 'beryl devs' with access to compiz than 'compiz devs' at the moment (AFAIK), so what more do they want?

As someone else said, they should not try to ruin good will by trying to make this their own. We have all spent a lot of time and hard work rebuilding compiz, now people seem to want to start discussing names and 'management structures', I find it all a bit strange. Surely the merge must take place with the code and features first. Once they are added then we can see where we stand.

I think certain people have lost a lot of trust and they need to work hard to rebuild that.

Like you said, its a meritocracy. I am just saying lets see where to place merit. Obviously people like onestone, cornelius and maniac get respect, but there seems to be a lot of noise surrounding their good work (as per normal)

imnotpc

March 25th, 2007, 08:58 PM

No I think they are serious about contributing, those that do will gain respect and power (if they want it). All I am saying is why do we need to change any name in order for them to do that?
We expecting to change the name of Compiz-Extra anyway. Wouldn't it be pointless to lose the opportunity to work together over a name we were willing to change before the merger discussion started?
We have changed everything they were unhappy about and listened to their every need. There are more 'beryl devs' with access to compiz than 'compiz devs' at the moment (AFAIK), so what more do they want?
They are obviously happy with that. I think that's one of the reasons many of them are having a change of heart. As far as I know the only thing they've specifically asked for is a new project name. I'm sure they expect to be included in decision making as well, but that's a right we should give to any member whose earned it, regardless of where they came from.
As someone else said, they should not try to ruin good will by trying to make this their own. We have all spent a lot of time and hard work rebuilding compiz, now people seem to want to start discussing names and 'management structures', I find it all a bit strange. Surely the merge must take place with the code and features first. Once they are added then we can see where we stand.
I see your point and I agree to a certain extent. But at some point we have to acknowledge the efforts they are making and continue to make it worthwhile for them. The work we've done won't be wasted. Likewise they have put a lot of effort into their project. The valuable parts of both can be combined and the obsolete or unneeded parts discarded. This is an opportunity to added to what we've done. Not destroy it.
I think certain people have lost a lot of trust and they need to work hard to rebuild that.
I think that refers to a small minority of the Beryl team and it's old issues. Most of the current devs have never done anything to hurt Compiz, and in fact are now being very helpful. That doesn't mean that there hasn't been some confusion and misunderstandings. Only that their intentions are good.
Like you said, its a meritocracy. I am just saying lets see where to place merit. Obviously people like onestone, cornelius and maniac get respect, but there seems to be a lot of noise surrounding their good work (as per normal)
Nobody is asking to get something they didn't earn and the noise isn't from them. They are making an honest effort here to work with us. I don't want to see this progress wasted. I'm willing to give those individuals a say, along with racarr. For that matter we have a bunch of devs here that deserve a say as well. Maybe we should look at ways to allow all the major contributors into the decision making process?

mikedee

March 25th, 2007, 09:24 PM

I think that refers to a small minority of the Beryl team and it's old issues. Most of the current devs have never done anything to hurt Compiz, and in fact are now being very helpful. That doesn't mean that there hasn't been some confusion and misunderstandings. Only that their intentions are good.

I think that contributing to beryl negatively detracts from compiz in very real ways. This is not including the direct mud slinging that was officially supported.

1. The compiz name is diluted (we see this by the Compiz/Beryl confusion)
2. Wasted time making everything compatible.
3. Lots of code and bug fixes are lost. I think this is going to be our biggest loss. Manually pulling out each one is going to be very very hard and I am not sure that anyone really wants to do that. I haven't seen any bug fixes or improvements being sent to the mailing list (things like zoom on rotate etc are easy).
4. Users and developers are confused about the differences so just don't bother.

Just look at the beryl bug tracker for instance. How many of those bugs relate to compiz too? How can we tell other than by asking each reporter to try again with compiz? This alone is an enormous amount of wasted time from a lot of people.

I think if people do not like the compiz-extra PACKAGE name then they should just fork it but with a different name if that makes them happy. I think at the moment there is no consensus (and there probably never will be) compiz-extra describes exactly what it is. A package of extra plugins and software for Compiz. Any name change should be done with proper thought and planning, not rushed into so that we can get a merge done within the week.

I think some people just want to wipe off the compiz name from everything. What is the point since all of it will depend on compiz anyway? We are just producing some extras for compiz, nothing more. I think if the compiz name had not been dragged through the dirt in the first place then people would not be so unhappy about it.

Remember 3 months ago.... The forum (and the package) was called compiz-quinn. The name was only changed in the first place so that binaries could live together on the same system. Calling everything a 'project' is just strange since all it is is a combination of software and a forum supporting compiz.

As you know the name change idea as compiz-extra was put forward to the beryl guys many many many times. Each time they rejected it so eventually compiz-extra was formed instead. The last opportunity was recently so nobody can say we didn't try to merge much earlier. We tried from the day of the fork until the day we were forced to release compiz-extra by ourselves. Its only now that we have actually done the hard work that they seem interested.

mikedee

March 25th, 2007, 09:41 PM

Quotes like this from beryl users really just shows how much bad feeling has been spread and how they have filled peoples minds about what David wants and what he is about.

http://forum.beryl-project.org/viewtopic.php?p=29020#p29020

The only way to put that right is to join WITH David in making the best composite window manager in the world. Rather than trying to fight against him all the time. This is the sort of comment that started the entire fork and I am sad to still see this kind of thinking alive and strong.

Gusar

March 25th, 2007, 09:47 PM

rememo

March 25th, 2007, 09:59 PM

I think at the moment there is no consensus (and there probably never will be) compiz-extra describes exactly what it is. A package of extra plugins and software for Compiz. Any name change should be done with proper thought and planning, not rushed into so that we can get a merge done within the week.

Yes, I agree. This is also my point, at which I don't understand a name change.
After all these are all plugins, settings managers, decorators written for compiz. So why should we give them a name, with no compiz inside. Look at banshee, they've also got unofficial plugins but no one would ever think about putting them into a package named other than banshee-unofficial-plugins. I'm sure there are more examples of this around.

Quotes like this from beryl users really just shows how much bad feeling has been spread and how they have filled peoples minds about what David wants and what he is about.

Yes, seen this too. And I think this is really something the beryl-devs are responsible for, because they haven't given proper credits in blogs for a long time. Anyway, I don't think that all users have this radical attitude. And we shouldn't decide on behalf of such stupid comments.

imnotpc

March 25th, 2007, 10:04 PM

I think that contributing to beryl negatively detracts from compiz in very real ways. This is not including the direct mud slinging that was officially supported.

1. The compiz name is diluted (we see this by the Compiz/Beryl confusion)
2. Wasted time making everything compatible.
3. Lots of code and bug fixes are lost. I think this is going to be our biggest loss. Manually pulling out each one is going to be very very hard and I am not sure that anyone really wants to do that. I haven't seen any bug fixes or improvements being sent to the mailing list (things like zoom on rotate etc are easy).
4. Users and developers are confused about the differences so just don't bother.
In a broad sense the entire fork hurt Compiz, but to hold that against people who joined the project afterwards is a bit like the Catholic concept of "original sin". Let's just baptize them and move on ;-)
Just look at the beryl bug tracker for instance. How many of those bugs relate to compiz too? How can we tell other than by asking each reporter to try again with compiz? This alone is an enormous amount of wasted time from a lot of people.
Another solid benefit we get by reuniting is consolidating bug fixes.
As you know the name change idea as compiz-extra was put forward to the beryl guys many many many times. Each time they rejected it so eventually compiz-extra was formed instead. The last opportunity was recently so nobody can say we didn't try to merge much earlier. We tried from the day of the fork until the day we were forced to release compiz-extra by ourselves. Its only now that we have actually done the hard work that they seem interested.
Actually I don't think we ever discussed the name Compiz-Extra with them but yes there have been many sporadic merger discussions. You'd have to ask them, but I suspect that the release of the definition of Compiz-Extra was a factor since it spelled out a vision very similar to theirs. I have to say that coming up with the project definition was hard work, but there's plenty of hard work left.

RYX

March 25th, 2007, 10:06 PM

The idea of creating a DE out of compiz-extra should be put into the back of our minds!!

First we need these things (all fully tested, rock solid and bug-free):
- compiz 1.0
- lightning-fast window-decorator with _real_ plugin-interface (no engines) and plugins for metacity, kwin, svg, ... (plus a couple of original non-"*ish" themes and styles)
- universal settings-manager with underlying lib which abstracts the backend to allow using dbus, fuse, ini, ...
- a huge set of ass-kicking, bug-free plugins to select from
- a (separate) profile-manager that allows changing the entire look of your system: plugins, settings, window-borders, qt/gtk-theme, gdm/kdm-theme
- a working desklets-environment (maybe you know which one I think of) with at least 20 extremely stylish eyecandy-widgets

If someone can show me these things I will join him and put all my time into making a new DE out of that ... otherwise we should put our time into creating this stuff first - then we approach our DE and finally give it a name.

Until then the name compiz-extra seems like a good solution for placing all we have ...

(I don't want to sound offensive but we all have to come back to constructive things and let this DE-/name-discussion end - beryl didn't work as supposed and we surely don't want to do their faults again ... )

:)

imnotpc

March 25th, 2007, 10:16 PM

Quotes like this from beryl users really just shows how much bad feeling has been spread and how they have filled peoples minds about what David wants and what he is about.
For every comment like that, there are ten like this: http://forum.beryl-project.org/viewtopic.php?p=28924&sid=3cf2b8b2877dbdb694f6015c1f9927e1#p28924

This informal poll currently runs 93% in favor of merging.
http://forum.beryl-project.org/viewtopic.php?f=41&t=5235
It's a pretty small sampling but it's consistent with other posts. In fact, the most common comment seems to be "It's about time". I don't think there'll be any issues with their community.

onestone

March 25th, 2007, 10:30 PM

I would like to give here a little introduction to the libbs system:

Libbs is a rewrite of libberylsettings. We do this to to fix some outstanding issues and to remove the glib dependency.

The library will use a new compiz system (currently in development with david) to readout all settings of all plugins without the need of a running compiz. With this system compiz also will get the ability to create gconf schema files at compile time, with a new gconf dump tool.

Features:
- own settings plugin as ALTERNATIVE (not replacement) for the current setting plugins (gconf,ini)
- at least three different storage backends (ini, kconfig, gconf)
- transparent desktop environment integration in the kconfig/gconf backends. So you can change the settings in you DE config tool like kcontrol and libbs will use them, but you can also change settings in one of the libbs configuration tools and your favourite DE window manager like kwin will also use them too.
- profile support
- import/export of settings
- ability to change settings without a running compiz
- ability to configure plugins before they get loaded
- automatic plugin order calculation
- new system to track changes to avoid the old reload signal of the current beryl system
- python bindings
- fully auto generated settings gui
- command line settings tool
- (IN THE FUTURE) global profile defaults (To help distributions to set their preferred defaults and to give the user the ability to switch back to this defaults)
- (IN THE FUTURE) dbus context server that will not require to change the plugin or the existing configuration tools. Libbs will automatically act as the bindings for the dbus system.

Libbs is currently under heavy development and we hope to get it ready soon.

imnotpc

March 25th, 2007, 10:38 PM

We expecting to change the name of Compiz-Extra anyway.
Let me ask directly: Why?
As mikedee says, it perfectly describes what the package is about - namely, extras for compiz (extra plugins, gui configurators, window decorators etc.) Having a different name would only cause confusion IMO.
http://forum.go-compiz.org/viewtopic.php?p=5611#5611
Is the name change just to satisfy beryl people? If so, which people exactly? Those who matter - those who have written code for compiz and have been porting plugins (racarr, onestone, maniac, cornelius) don't seem to care much, or am I wrong here?
As you can see in that link we intended to use a different name for Compiz-Extra for an unrelated reason. I want to make clear that I'm not advocating changing the name of the Compiz-Core division or the name of the core package. It will remain compiz. What we are considering here is changing the name of the Compiz-Extra community and potentially the compiz-extra package so that there is no confusion between compiz the window manager and compiz-extra the user packages.

imnotpc

March 25th, 2007, 11:55 PM

The idea of creating a DE out of compiz-extra should be put into the back of our minds!!

Ummm... who's talking about creating a DE? I'm not. But we do need to consider that the Compiz-Extra division supports programs such as screenlets that are clearly not part of a window manager. If we reunite with Beryl there will be even more of these kinds of desktop apps.

This division may end up with multiple packages containing many different types of programs. The example that I've used before is apache.org. The main apache project has spawned new related projects just like Compiz and Beryl have spawned screenlets and kiba-dock. These projects add to the usefulness of our code and attract users and developers.

There is no immediate need to change the name of Compiz-Extra, but there is no reason not to either. Especially if it allows us to reunify.

rememo

March 26th, 2007, 02:49 AM

Well, the problem for me is: I don't see the relationship between compiz plugins/decorators/settings-managers and applications that simply use the composite feature of compiz(like screenlets, kiba-dock mostly currently do). Why should they be hosted together under one project identity? They probably want to use different project identities to stay independent. Of course there is a relationship if they should finally build a new DE because they will have to work much more together. In this case a name-change is obviously needed. So what is the real scope of the reunited project?
a) Providing only community written plugins/decorators/settings-managers that enhance compiz? In this case compiz-extra or compiz-community-extra is sufficient as a distinction and shouldn't get renamed only for the sake of a possible merge. This may sound hard, but why using a project-name without compiz inside when the project only enhances compiz? For me this is a question of giving proper credits to the original project.
b) Or second also to provide apps that are heavily related to and based on any possible plugin/decorator that will be written for compiz as in the case of a next-gen Desktop Environment? In this case a name-change is obviously needed because the apps would not only enhance compiz but instead the whole desktop. A merge under a new project-name wouldn't be a problem at all then.

Perhaps a decision on this could clear some points.

FunkyM

March 26th, 2007, 04:20 AM

Seriously, it is really not hard to guess if you know a bit about Linux software deployment or the stuff available in your distro's repository. You can guess that compiz plugins get into a bundled package and individual applications should get their seperate packages.

Yes, most of the applications evolved on top of the new desktop effects "environment", still there is absolutely no need to pack them all together in one single package only because of that.

A central source code repository or project management is a totally different topic and you can host all of these projects (if they want it) without much hazzle.

@onestone: That sounds really nice! One idea: I think it wouldn't hurt to do that "communication with David" on the official ML so other people can contribute to the talks aswell.

@mikedee: I never read anything rude by you and everything seems pretty much of logical nature what you write eventhough one can see your emotional ambitions to get stuff done right in-between the lines. However, you have can't win against the hordes of users who have absolutely no clue what they are talking about nor ever heard about Richard Stallman or really have a clue what GNOME and KDE really defines (loads of new users directly parachute here from Windows these days; We should be glad!). Those are always going to initially spread FUD and just don't get the technical aspects right. As noted before, it's not a religion, we all want to code exciting stuff for the next generation Linux Desktop.

Glad to see faces like iXce and others around and I hope that the merge of the communities will be as straightforward as I see it happening in the technical part in the next months.

imnotpc

March 26th, 2007, 04:49 AM

Very good points rememo. I had hoped we would have had more discussion on this when the description of the new divisions was first posted. I think if we'd gotten into the details then, a lot of this discussion could have been avoided. (I'm not blaming you rememo. You just happen to be the one who's finally asking some good questions.)

As I've posted previously, the vision for Compiz-Core is to "become a universal compositing and window manager layer on top of X Server, which can be integrated into all major DEs and included by default in all major distributions."

The vision for Compiz-Extra is a little more complicated. While discussing the goals of Compiz, we saw that there was tremendous interest in "other programs and libraries", i.e. not a plugin or decorator. These other programs did not fall within the definition of a compositing window manager, and in fact created new functionality or functionality that unnecessarily replaced existing functionality it DEs. They were clearly not within the scope of the original compiz project yet they were extremely popular and important to our users. You may not realize it but the "screenlets" thread represents about 10% of the entire volume of this forum since it's inception. One thread, 10%, and it's not even part of Compiz. Kiba-dock and screenlets also very popular on the Beryl forums.

What this tells us, as leaders, is that our users and developers see the potential of the composited desktop and want to do more with it. These programs and others are clearly not part of Compiz-Core, and in some ways may interfere with the goals of Compiz-Core. This is why we determined that we needed to divide the bare core and plugins from the rest of the code and move them to separate divisions. It was to release Compiz-Extra to become more than a bunch of plugins.

So what is Compiz-Extra? "Compiz-Extra will have a broad focus on plugins, decorators, libraries, and other programs and will include stable, developmental, and experimental code." Doesn't really tell you much, does it? This could be most anything. That is exactly what I intended. Compiz is your project too, not just ours. Compiz-Extra is what the community wants it to be.

Right now Compiz-Extra is some core plugins (which ones is still being decided), the decorators, and compiz-extra. Soon we expect to include some other programs such as screenlets. In the future... this is what we need your help with. Tell us what your vision is. What do you want to see our community create?

Not surprisingly, the five of us have our own visions of what we think Compiz-Extra should be. Those visions range from "just plugins and decorators" to "Create a new composited DE". While we all have different visions of what a future Compiz-Extra may become, the one thing we all agree on is that we aren't going to set a goal that we aren't confident we have the developer resources to reach. This is why the division goal "develop compiz related software and support the use of compiz on all desktops" is non-specific. In other words, we aren't going to announce that we are going to do something until we know that we have your commitment, and developers with the skill to make it happen.

So after all this, what is the answer to your question? The answer is "b" if, and only if, that's what the community wants. While it's not unanimous, many of the developers in both Compiz and Beryl see our projects as more that a package of plugins, decorators, and settings managers. We see the possibility of a fully composited desktop, either ours or those of an existing DE. We see the ability to run run Compiz/Beryl with or without a DE using the programs we develop here. A project that at some point in the future could become something like a DE. We see a project that in my opinion is important enough to deserve it's own name and identity.

Jeff

stalynx

March 26th, 2007, 11:44 AM

The key issue overlooked is that compiz and beryl are not going to merge but rather their respective communities. So the discussion should not be "what should we call the new community?" or "what will the community goals be?". These questions for the most part don't even make sense in the current context.

The real issue at hand is how do you increase community involvement. I think the first step has already happened as more and more community patches are being sent upstream. The next step is a functional and well designed site that allows plugin/decorator/settings-manager/third-party application authors to share code with users.

A extra or "beryl" package should just be the best from the community reflected by this site.

imnotpc

March 26th, 2007, 02:50 PM

The next step is a functional and well designed site that allows plugin/decorator/settings-manager/third-party application authors to share code with users.
We are getting ready to refresh the current site and move it to compiz.org. A that point we can start working on a new user-oriented site for Compiz-Extra that focuses on plugins and other end user programs. There needs to be discussion and decisions made about many things:
- What will be the relationship between the sites.
- Will we move the forum, keep it here, or create another one.
- Does there even need to be a site for the Compiz-Core division or can the core be supported on the Compiz-Extra site.
- What will we call it and what logo will it use.
I could go on, but my point is that within a few weeks we are going to have to make some of these decisions including the name of the new site. I don't think we need to name the site right now, but if we can agree that we're going to change the name, then we can kill two birds with one stone.

Jeff

rememo

March 26th, 2007, 02:58 PM

The real issue at hand is how do you increase community involvement. I think the first step has already happened as more and more community patches are being sent upstream. The next step is a functional and well designed site that allows plugin/decorator/settings-manager/third-party application authors to share code with users.

No. As already said: Why should third-party-apps authors decide to integrate their apps under the identity of a different project? This is simply illogical to me and not conform with FOSS project-management as FunkyM pointed out. What you describe is a central repository for stuff to host that works somehow around the composite features of compiz. But a new repository plus some forums are really not a new project (in the sense of code writing). And why should things like plugins/decorators/settings-managers for compiz be hosted at a repository and not at a compiz-community-site (aka compiz-extra) where they really belong to? Of course such a central repository could redistribute them in an "all-in-one-call-me-what-you-want"-package, but development will not be made there.
I would say only creating really new stuff (like a DE) justifies a new project (the "b" solution). And on this behalf I'm a bit sceptical why users should decide what the scope of the project is. A new software-project is based on the vision of some talented devs and not on the wishes of users from two other projects. So after hearing from imnotpc that there is even difference between the devs (from both sides and project-internal) on the scope of such a new project, I really don't know why we are already having a discussion about a merge. Seems a bit to early for me... There should first be an agreement on what to achieve and why it would justify a new project and not a repository. If there is no justification for this, a merge will only be possible into the direction compiz-extra. Perhaps both teams should clearly state what they want to achieve and why it would justify a new project. If the direction is currently not clear, a possible solution could be to first merge here to compiz-extra and then after a while look at the goodies that came out. If then they aren't enhancements to compiz and different apps that could be hosted at there own site anymore, but play nice together and provide new functionality, bring them to a new project.

For sure we want to bring the community together, but the real question is: Couldn't we first reunite into compiz-extra-community for plugins/decorators/settings-managers for compiz and maybe simply provide a central repository (with whatever name (I would like rock3d :) ) and maybe supporting forums) to host apps that utilize composite features and look what comes out of this in the end? Or is there currently a vision strong enough to justify a new project that combines apps and compiz enhancements inevitably?

maniac

March 26th, 2007, 04:05 PM

If there is no justification for this, a merge will only be possible into the direction compiz-extra. Perhaps both teams should clearly state what they want to achieve and why it would justify a new project. If the direction is currently not clear, a possible solution could be to first merge here to compiz-extra and then after a while look at the goodies that came out. If then they aren't enhancements to compiz and different apps that could be hosted at there own site anymore, but play nice together and provide new functionality, bring them to a new project.

First let me say one thing: It doesn't matter at all what a new project is called. Really.
But there is one thing that honestly bugs me a bit, and this is attidute. You say "The only possible thing is that Beryl developers / code is merged into Compiz-Extra". This, together with Mike's statements, sound to me like the Beryl devs and their code aren't important at all to you. Is that really that case? Imagine a compiz-extra package without ANY plugins ported from Beryl to see what the Beryl part in a merge is.
That's a fear some Beryl developers have: We bring along a large number of plugins and get no respect and no say in a merged project. I don't say I share this fear completely, but having read some of the statements here I must admit that I can understand them to a certain degree. Please keep in mind that you (as a subset of all developers involved) also get a real advantage, so please don't see us as people who demand leadership (noone has demanded ledadership, BTW) or name changes.
Please understand that the only thing we want to see is that people who contribute the same amount to the common code base have equal say (and equal identification with the project) no matter where they came from.

Thank you.

roico

March 26th, 2007, 04:28 PM

IMO, the "compiz" name is very good, it sounds great and it also makes sense with the idea of "_composting_ WM"

however, i think the name should be changed, because a new name is like a clean start, a compromise where *both* projects lose their names, and no-one feels like he "lost".

the way i see it, its not "beryl is merged into compiz" but "beryl and compiz(-extra?) are merged"... keeping the name of compiz will be as dumb as keeping the name of beryl (and actually, i think beryl's code will be the majority in -extra...)...

rememo

March 26th, 2007, 04:32 PM

First let me say one thing: It doesn't matter at all what a new project is called. Really.

Yes, it does matter. It depends on the scope of the new project. I will repeat myself again:

a) Providing only community written plugins/decorators/settings-managers that enhance compiz? In this case compiz-extra or compiz-community-extra is sufficient as a distinction and shouldn't get renamed only for the sake of a possible merge. This may sound hard, but why using a project-name without compiz inside when the project only enhances compiz? For me this is a question of giving proper credits to the original project.

So as you see, my fears are the same as yours. The loss of respect! In this case for the originating project. Compiz has already lost respect among users after the fork, just look at ubuntuforums, heise and google trends ;)

But there is one thing that honestly bugs me a bit, and this is attidute. You say "The only possible thing is that Beryl developers / code is merged into Compiz-Extra". This, together with Mike's statements, sound to me like the Beryl devs and their code aren't important at all to you.

Yes they are to me. And beyond this they are far more important for a new desktop experience too. But why are you so kean on giving your code another name without compiz inside, if what you have done are enhancements to compiz. I don't understand why you don't understand this. I really respect your work you have done, but why can't you respect compiz inside a name for your work.

That's a fear some Beryl developers have: We bring along a large number of plugins and get no respect and no say in a merged project. I don't say I share this fear completely, but having read some of the statements here I must admit that I can understand them to a certain degree. Please keep in mind that you (as a subset of all developers involved) also get a real advantage, so please don't see us as people who demand leadership (noone has demanded ledadership, BTW) or name changes.

As already said, leader structure is something that can be decided on later. I would like to give you all powers in a combined community as you seem to be a very good contributor, but that's beyond my abilities :) . But I'm sure all of you will get the proper respect and powers. That was never the question.

Please understand that the only thing we want to see is that people who contribute the same amount to the common code base have equal say (and
equal identification with the project) no matter where they came from.

see above

I hope no one thinks that I have no respect for the code you write. I'm simply considering that a name-change should be based on the scope of the project. It's really not that hard to understand it, as they are all logical reasons. A name should be based on the original-project as long as you aren't providing seriuosly new functionality.

But in the end I've not written compiz initially, so I really shouldn't bother with the name of enhancements to it. David will be the one who looses... Please, call it whatever you like. I've expressed my thoughts and I will stop now to make anyone feel I wouldn't respect his work :)

mikedee

March 26th, 2007, 05:20 PM

But there is one thing that honestly bugs me a bit, and this is attidute. You say "The only possible thing is that Beryl developers / code is merged into Compiz-Extra". This, together with Mike's statements, sound to me like the Beryl devs and their code aren't important at all to you. Is that really that case? Imagine a compiz-extra package without ANY plugins ported from Beryl to see what the Beryl part in a merge is.

As far as I can see, each 'beryl plugin' has a developer attached, from what I see everybody is treated equally.

My aim from the start has always been to encourage developers by providing everything they need. Of course I want and respect developers and the software they provide, but I believe that people should be respected on merit.

I think that you, onestone and cornelius all deserve a massive pat on the back for your work on compiz and compiz plugins. I love group, animation and the desaturation on blur. But I equally do not think that you should get respect or praise for work done on beryl, there are also lots of developers here who are doing good things but they did not feel they were important enough to drop the compiz name.

As far as I can see you certainly have a say in what goes into compiz, you have access to the fdo repo if I am not mistaken.

Please keep in mind that you (as a subset of all developers involved) also get a real advantage, so please don't see us as people who demand leadership (noone has demanded ledadership, BTW) or name changes.

From what I have seen on your mailing list there is discussion on what you are going to do about the management structure. It may not have reared its ugly head yet, but it will as soon as the non developers start arriving.

Please understand that the only thing we want to see is that people who contribute the same amount to the common code base have equal say (and equal identification with the project) no matter where they came from.

This is how I feel too, everyone should be treated equally, not make 'beryl people' more equal than anyone else. Nobody has contributed more than David to the common codebase, your patches only amount to a tiny amount of what is in compiz.

You guys were given special privilege as far as I can see. Nobody would normally be given access without actually submitting via the mailing list first (I only got access by submitting lots of patches). I have contributed a lot of plugins too, and including some unreleased ones, my LOC contribution to compiz far outweighs all of you.

Many other people have contributed, but I do not see them all detaching from David and then demanding some special respect for coming back.

Beryl was always about pride, lets not go down that road again shall we?