Merge with Beryl?

[Amaranth]

http://lists.beryl-project.org/pipermail/beryl-dev/2007-February/000237.html

Make sure you read the whole thread.

[wfarr]

That thread was full of a number of inaccuracies and general cat-iness.


I agree with most of Robert Carr's comments, and found some items (bringing up zoot's name) HIGHLY inappropriate.

IMO, some Beryl developers need to grow up, get some skin, and actually evaluate things for what they are.

The Beryl kids have a right to do their own thing - I think it's entirely a wasted effort and I do think in the future Compiz will prevail, either through "winning" or from Beryl merging back in.

[maniac]

That thread was full of a number of inaccuracies and general cat-iness.

Can you be a bit more specific, please?


IMO, some Beryl developers need to grow up, get some skin, and actually evaluate things for what they are.

Do you think insulting anyone - even if they don't share your opinion - is a good thing? I agree with Robert, too, BTW.


The Beryl kids have a right to do their own thing

Which Beryl "kids"? We have only _one_ developer aged under 18 years - and this is Robert.


I think it's entirely a wasted effort and I do think in the future Compiz will prevail, either through "winning" or from Beryl merging back in.
I think this "winning" / "losing" scheme makes no sense at all. Especially I don't see Beryl "losing" if a merge really would happen. If it would happen, it would be for everyones advantage.

[delfick]

agreed....winning/losing are the wrong terms here :D

[arvid]

According to the posts there, David agreed not to bring the matter up on the Compiz mailing list. Out of respect for that, can we please drop the matter here as well? Even though David does not frequent or follow these forums, they are part of the official face of Compiz, and we should respect the word David gave on behalf of Compiz.

[RYX]

Surprise, surprise - I fully agreee with maniac and delfick (though arvid is right, too). :)

I think the whole losing/winning-thing is child's play - nobody loses his/her face, instead people have the great chance to do the "right thing" (in sense of a united community).

We should all agree that a united community would be best for all of us (with "us" I mean all - compiz AND beryl users). Wouldn't you like to have a situation where everyone does what he is best at?

Imagine where we would be today if the fork wouldn't have happened.

:)

[delphinen]

please...

[Amaranth]

arvid: They also agreed to not bring it up on their mailing list. :) Since it's out there might as well talk about it.

[stalynx]

It's hard for me to believe a "merge" could happen with terms that would fully satisfy the majority of Beryl developers. Of course I have no idea what DavidR would agree too but I doubt being in full control of the main git repo is one thing he would give up.

It appears to me the majority of work in Beryl has gone into things that are separate from the core. So the new window managers/decorators and setting managers could all be just ported over to work with Compiz. Of course I'm not really sure about this. It might be a lot harder than it looks at first glance.

[amgeex]

This all wasn't supposed to be public. These were internal talks between David and the Beryl devs. He wanted to wait and see if something was really going to happen before making anything public. Now Beryl has published it and created more flamewars where they are not needed. :roll:

[racarr]

Please do not say "Beryl" published it. An individual affiliated with Beryl made a mailing list post on a personal basis.

[RYX]

I think it doesn't matter who published what - it is a fact that there is an interest to merge on both sides and (at least) I like open discussions. All this hidden "behind-closed-doors"-behavior caused us all this trouble so we (the communities) should try to talk in public about this.

(Edit: The following is my personal opinion)

It should be clear and out of discussion that David maintains the core and keeps full control over what goes into the core and what doesn't. It is his work, he knows it best and he should have the power. Whoever wants to contribute to the core can do it (I can assure you that David will accept useful additions or give you tips what can be improved) - nothing will stop you from sending patches to the list.

Everything outside the core (plugins, decorator, settings-manager, ...) is "free" - i.e. can be written and worked on by anyone. David is gladly accepting any useful patch and addition for the standard plugins. For third-party plugins and extras it will be no problem to setup a community-repo (it already exists, anyway).

The licensing-issues are more or less ridiculous (and one could see them as a weak excuse) because the licenses really don't differ that much.

So where are the actual problems? I'd like to hear some honest opinions - just let it out :D ...

:)

[racarr]

It should be clear and out of discussion that David maintains the core and keeps full control over what goes into the core and what doesn't. It is his work, he knows it best and he should have the power. Whoever wants to contribute to the core can do it (I can assure you that David will accept useful additions or give you tips what can be improved) - nothing will stop you from sending patches to the list.


I can go ahead and say Beryl devs will not have any desire to go ahead with a merge with this as an axiom.

Not speaking officially for Beryl, but merely aggregating commonly voiced opinions, we in general feel something like the following would work.

1. Before changing the code someone else has written, ask them. If they say no and are unable to provide a reason acceptable to you, bring it up for discussion among other developers. If a large majority support your position, go ahead and commit it.

2. When seeking to add something to core do the following:
a. Document a need, and the implementation for the addition.
b. Commit to a branch first.
c. Obtain a majority of support among individuals qualified to comment before moving to master.

It is certainly Davids right to exercise more control than this over a project, but I know no Beryl developers interested in working on such a project, and frankly it's more or less impossible to actively develop under a model like that.

[RYX]

I am not the voice of anyone so (most of) the above was just my personal view of the things. David surely has his own point of view.

I don't really understand why you think development is impossible the way it is (obviously compiz exists, so the model seems to work :D). The need for changes to the core will rapidly decrease in the near future. David wants to keep the core as small as possible so the main focus for everyone will be the plugins, anyway ... If things in the core should be changed for good reason, David would be the last one to not accept such a patch.

Where is the difference between discussing changes to the core with David and/or someone else?

:)

[racarr]

I don't really understand why you think development is impossible the way it is (obviously compiz exists, so the model seems to work :D).

:)

Only one person (David) actively develops Compiz (Yes, we can argue that other people contribute, and yes they do, but the LARGE majority of commits to anything in master are made by and written by David), so of course the model works for one person.

My implication was it is impossible to have multiple active developers with such a model.

We all agree core needs to be kept small, but alot of us feel a lot of things in core could be done very differently and it sounds like under your model if 4 developers wanted to do things one way, and David wanted to do it another way, then it would be done Davids way.

I think it's understandable why we don't really want to develop under a model like that.

Under Beryl, Quinn technically has final say on design decisions, etc, but this is nearly never (ever?) exercised, and changes any one person (including Quinn) disagrees with as long as a larger number of other developers are able to provide coherent and reasonable arguments as to why such a change would be implemented, will be implemented and merged.

This is something we would want to preserve under any new project.

[wfarr]

That thread was full of a number of inaccuracies and general cat-iness.

Can you be a bit more specific, please?

Mostly in respects to David - they were quite demeaning.


IMO, some Beryl developers need to grow up, get some skin, and actually evaluate things for what they are.

Do you think insulting anyone - even if they don't share your opinion - is a good thing? I agree with Robert, too, BTW.

There's a difference between being demeaning and being honest. Some of the opinions presented were sophomoric at best.


The Beryl kids have a right to do their own thing

Which Beryl "kids"? We have only _one_ developer aged under 18 years - and this is Robert.

I use "kids" and "kiddos" colloquially.


I think it's entirely a wasted effort and I do think in the future Compiz will prevail, either through "winning" or from Beryl merging back in.
I think this "winning" / "losing" scheme makes no sense at all. Especially I don't see Beryl "losing" if a merge really would happen. If it would happen, it would be for everyones advantage.[/quote]

Hence my use of quotation marks - there can't really be a winner or a loser in this, but it's the closest one can describe it.

[imnotpc]

1. Before changing the code someone else has written, ask them. If they say no and are unable to provide a reason acceptable to you, bring it up for discussion among other developers. If a large majority support your position, go ahead and commit it.

2. When seeking to add something to core do the following:
a. Document a need, and the implementation for the addition.
b. Commit to a branch first.
c. Obtain a majority of support among individuals qualified to comment before moving to master.

It is certainly Davids right to exercise more control than this over a project, but I know no Beryl developers interested in working on such a project, and frankly it's more or less impossible to actively develop under a model like that.

In the past David has offered to create branches and merge changes as you suggest. I'm pretty sure that's still true. While David most likely will (and should) maintain the compiz name for the core and final say on commits, he is willing to consider a different name for the community and "optional" plugins and window decorators (I am as well). If you look at the mailing list archives you can see that David readily accepts patches and listens to the opinions of other devs on the the list just as you describe. Are we really that far apart?

I think the benefit of initially discussing these sort of things in private is that it allows people to speak freely about personal issues which may a problem, and to discuss "what if?" scenarios without raising expectations and disrupting the community. IMHO, once personal issues and false starts have been weeded out, the ideas should then be shared with the community for discussion and approval/disapproval.

At this point I'm willing to:

a) Create a mailing list for leaders of each community to discuss this issue in private (irc is difficult for some of us).

b) Draft a proposal that we can discuss either privately or publicly.

c) Stay the hell out of this discussion altogether since things seem to be going just fine without me.

As side note, even if nothing comes of these discussions, it's nice to see that at least we can work together on code and discuss things rationally without all the nasty BS we've always had. That alone is progress.

[RYX]

My implication was it is impossible to have multiple active developers with such a model.
I understand your point, but it is maybe not as you think. If you follow the mailing-list you will realize that there are more developers than only David - he is just the one who has "invented" the whole thing, written about 90% of the code and outranks us all when it comes to knowledge about X-programming. I think the most "professional approach" would be to keep him as the lead-developer and the man in control ... (actually exactly this thought caused me to "leave" beryl).

But imnotpc is absolutely right - we should further try to discuss these things in a friendly manner (as we already do :)), maybe on a separated mailing-list (but on the other hand - the community-members shouldn't be totally excluded from this discussion). I still have the feeling that our positions are not too diverse for a compromise. There is an increased will on both sides to re-unite, maybe under a totally different name ... that alone is a reason to cheer :D :D ...

:)

[maniac]

I understand your point, but it is maybe not as you think. If you follow the mailing-list you will realize that there are more developers than only David - he is just the one who has "invented" the whole thing, written about 90% of the code and outranks us all when it comes to knowledge about X-programming.

Well, I think you miss the differentiation between a "developer" and a "contributor". While both are important, they differentiate by the interval of code changes they submit. Contributors don't change code that often, and if they do, these are small code snippets, so it's fine for them to send patches around mailing lists. For developers (those people who change code on a daily basis), this form of code change communication becomes terribly annoying in a short amount of time. That's what we mean by "Compiz' current development model doesn't work with multiple active developers".


I think the most "professional approach" would be to keep him as the lead-developer and the man in control ... (actually exactly this thought caused me to "leave" beryl).

Maybe nitpicking, but I can't resist ("Steilvorlage" would be the German term for that): Can you name a software development company where there are a couple of coders and only one person commiting to the version control system? :P
IMO, a "one-man-development" model (explanation see above) is not necessarily needed for creating high quality code :)
But besides that, there never was any doubt about keeping David's position as lead developer for any new project involving Compiz and Beryl.

[RYX]

I don't want to be nitpicking either, but why are you all so keen on hacking around in the core? David wants the core to be lightweight and clean and encourages everyone to implement additional functionality by plugins. If your plugins need functionality that is not in the core, write a patch and contribute to the core. Why does everyone want to be a core-developer if he can just heavily contribute to the core (where I personally see no difference - but that's up to everyone's defintion)?

(Edit: And besides that I am sure that if someone proves that he obeys the coding-rules and continuously contributes good patches could talk to David about an account. But I think its understandable that he doesn't give main-git-accounts to everyone ...)

:)

[mikedee]

Only one person (David) actively develops Compiz (Yes, we can argue that other people contribute, and yes they do, but the LARGE majority of commits to anything in master are made by and written by David), so of course the model works for one person.

The only way to change this situation would be

1. Other people contribute more to Compiz
2. David contributes less

I vote for 1

My implication was it is impossible to have multiple active developers with such a model.

Whys that? It works for all other open source projects.

Under Beryl, Quinn technically has final say on design decisions, etc, but this is nearly never (ever?) exercised, and changes any one person (including Quinn) disagrees with as long as a larger number of other developers are able to provide coherent and reasonable arguments as to why such a change would be implemented, will be implemented and merged.

The same thing happens with Compiz, if David disagreed with something and 10 people agreed (people who have shown they know enough to make a judgement), then David would surely change his mind. So far this has not happened, so it cannot be proven one way or the other.

Maybe you can point out a feature or something which we need but David has not or will not agree to?

[maniac]

I don't want to be nitpicking either, but why are you all so keen on hacking around in the core?

Noone is "keen on hacking around in the core". The development model is a fundamental question...if the (hypothetical) core commit privileges are really exercised is a completely different question.


David wants the core to be lightweight and clean and encourages everyone to implement additional functionality by plugins. If your plugins need functionality that is not in the core, write a patch and contribute to the core. Why does everyone want to be a core-developer if he can just heavily contribute to the core (where I personally see no difference - but that's up to everyone's defintion)?

Sending around patches is a PITA. They depend on each other, you have to (manually!) create and apply them and so on. I give the question back to you: What's the problem with the branch model (core changes in branch and get applied by a "certified person")? Why are you so keen on doing core changes by patches only? ;)


(Edit: And besides that I am sure that if someone proves that he obeys the coding-rules and continuously contributes good patches could talk to David about an account.

Well, sorry, but I don't think THAT model would work...at least I have problems with begging other people (such as David) to do things.
That's a question of attitude: Should this be a shared project or shouldn't it? If the former is the case, there should be no problem giving every developer an account and assure the code quality by policy. At least the Beryl devs of course would respect such policies ;)

[RYX]

There is no problem with the branch-model - that's what mikedee proposed over and over again. A community-branch like in the old times of compiz-quinnstorm. If things are working good, they get applied to the head branch (as patch, sent to the mailing list, to enforce thinking before commitiing ;)) ...

(And you won't have to beg anyone - but you won't get invited to something only because you think you should ...)

:)

[mikedee]

Well, I think you miss the differentiation between a "developer" and a "contributor". While both are important, they differentiate by the interval of code changes they submit. Contributors don't change code that often, and if they do, these are small code snippets, so it's fine for them to send patches around mailing lists. For developers (those people who change code on a daily basis), this form of code change communication becomes terribly annoying in a short amount of time. That's what we mean by "Compiz' current development model doesn't work with multiple active developers".

You start by sending small code snippets, and work your way up from being a contributer to being a developer. Once you have shown that you can be trusted not to mess everything up you can be handed the keys to the castle.

So far not many people have access to the main repo. I say not many because it is not 1 it is >1 (I know that for a fact). If people have enough to offer to core and core plugins maintained by David then you will be elevated from contributer to developer.

I suspect that code that is changing on a daily basis is plugin code, which is normally not maintained in the fdo repo. You could maintain compiz plugins in beryls svn if you like, so you can maintain them however you want.

[mikedee]

Sending around patches is a PITA. They depend on each other, you have to (manually!) create and apply them and so on. I give the question back to you: What's the problem with the branch model (core changes in branch and get applied by a "certified person")? Why are you so keen on doing core changes by patches only? ;)

The main benefit is that everyone who is interested in development can see what is being contributed and why. They then all get to comment on them and add any feedback before its committed and its too late.

This also has the small side effect that people check their patches individually before sending to the list. It makes for a more stable development and means that head it not broken and we avoid 'oops' style commits. Keeping commits atomic and clean is very important to a sustainable development model. We do it for everyones sake, not just Davids.

EDIT: If you plan on doing major or very long term work, then creating a branch is a good idea. git makes this very easy and means that it will always be possible to merge your changes back into the fdo repo if they add benefits.

[mangar]

here's my 0.02 local currency:

draft for merging plan, main points:

1. appoint a sabdfl. if david wants to to concentrate on the technical side,
let him appoint a community-second-in-command.
--reason: David is perceived as unwilling to cooperative with external developers; this may be due to valid technical reasons, as laying the infrastructure first, bling later, but the contributers finds it frustrating.
if david isn't willing, or sees this as a low priority, let him appoint someone else (compiz+beryl's andrew morton - how about quinn?).

2. clear roadmap - with well defined tasks and tasklets -
reason:
if someone wants to contribute to the core, he can know what is necessary to do, and it will reduce friction with the people of point #1.

2.1. decide (as part of the roadmap) about a plugin interface,
derived from the needs of the plugins developers - let them decide on
the needs, and the sabdfl + design committee to decide how and when to
implement those. patchy solutions will be kept as external libraries, and removed/ merged when the api will mature.


3. documentation: style guidelines, comments in the code, design
documents, code guides, etc.
--reason:
frees developers time needed to answer newcomers questions, allows for better code, reduce learning curve. healthier for the longer run of the project. ( i have seen the code.. and it was scary!)

4. allow contributers and community developers to have some say on the
future direction of compiz+beryl, have open discussions on the roadmap.

5. delegation of responsibility: plugins for the beryl guys, core for david + experienced guys (plugin guys after some initiations?)

[iznogood]

I can not understand all this stuff...

I few months ago people went their own way and forked compiz, now they want to rejoin (which is good) and have these demands about coding at the core, been second-in-command and such...

Well people if you want all that you have to prove it first. Who is skilled enough to stand next to David ?? None. Who can bring evolution on the desktop besides him and has proven it even a little?? Hmm Keith Packard i guess and a few others...Ok so lets make Keith a second in command and let him code at the core. Everyone might have good intentions but it takes more than that.

Also i find it extremely insulting even to suggest for someone to have the same status as the founder and main contributor of a project. I am sure that if someone did that on a project i have started i would have been very angry about it and i believe that most of us feel the same. This kind of status comes after contributing for a long time and proving that you a worthy of such a honor, not only because you can code great but also because you care for the project (any project) and you help it advance, not try to hurt it.

If someone ever arises to such a status it wll be because he has proven it and the community and the project owner accepts him, not because a few people voted this decision.

If people do not agree with this, then i guess (as beryl devs said a few months ago), its still open source, right??? You do it your way, and we do it our way. Otherwise you MUST accept who is the sole owner of this project and who has the final word on things.

Finally i find it extremely disturbing that people are going after David like that, frankly i can not undestand it (been not cooperative and such). Have you posted on lkml ever and got a response from Linus ??? How about Xorg ?? At least he answers most posts, so stop it because its unfair to everyone and it does not help right now

[mangar]

iznogood:
allow me to clarify point #1:
if David cannot, or doesn't want to manage a community (which is a pretty large overhead, for various reasons), let him appoint a second in command, that will be in charge of community relations.

one of the main benefits of making a project open-source, is the possibility
to recruit helping hands, and it is especially the case with a high visibility project like compiz. one one hand it is a management overhead, on the second hand, it can be a great boon to the project, if the volunteer developers are allowed contribute in a meaningful way.

about respect for David: suggesting delegation of responsibility is in no way
disrespectful- having one uber-expert is excellent, but the time available to a single man or to a limited group of people is finite. making use of available resources (such as community volunteers), can only improve the quality of the product.

[gnumdk]

Lets clarify some things...

If you come with good ideas, good code and send it to David, be sure it will be accepted in core.

If you continue to send good code, maybe you will be able to have access to compiz git, why not? But who here can say he is able to work on core? I can't... I can contribute (at my level), but i have no idea where compiz should go... David know...

Maybe David prefer to be the only man having access to core modifications... It's not a problem for me, many opensource project work like this...

The best example is postfix, Wietse Venema control the project, he accepts some patchs, reject a lot...

Today, David reject some patchs, accept a lot...

[iznogood]

iznogood:
allow me to clarify point #1:
if David cannot, or doesn't want to manage a community (which is a pretty large overhead, for various reasons), let him appoint a second in command, that will be in charge of community relations.

one of the main benefits of making a project open-source, is the possibility
to recruit helping hands, and it is especially the case with a high visibility project like compiz. one one hand it is a management overhead, on the second hand, it can be a great boon to the project, if the volunteer developers are allowed contribute in a meaningful way.

about respect for David: suggesting delegation of responsibility is in no way
disrespectful- having one uber-expert is excellent, but the time available to a single man or to a limited group of people is finite. making use of available resources (such as community volunteers), can only improve the quality of the product.


Very good post, thanks :wink:

I hope however that if a merge do happen, things won't go the same way as before in the future.

[RAOF]

...
So far not many people have access to the main repo. I say not many because it is not 1 it is >1 (I know that for a fact). If people have enough to offer to core and core plugins maintained by David then you will be elevated from contributer to developer.
...

Just to support this, the last three commits in my output from "git log" are from 3 different people, none of which was David.

[Amaranth]

From all the project's I've worked on I've seen two ways to get commit access (which makes you a 'developer' instead of a 'contributor').

Create the project
Provide sustained contributions of good code

Aside from this, there are a few projects where only one person has commit access. Examples of these are the linux kernel and WINE. They both use git, too. :) People are free to create branches and etc but all code has to go through one person before it gets into the main branch.

Those two models and two ways of getting commit access cover most of the projects that last longer than a few months.

[Amaranth]

Just to support this, the last three commits in my output from "git log" are from 3 different people, none of which was David.

That's deceiving, git shows someone else as the author of a commit when you merge their branch or (I think) apply a patch made with git.

[mikedee]

Just to support this, the last three commits in my output from "git log" are from 3 different people, none of which was David.

That's deceiving, git shows someone else as the author of a commit when you merge their branch or (I think) apply a patch made with git.

David manually enters each contributer name on their patches (based on the name and email on the list), in fact I think part of the reason for moving to git from cvs was that it made it easy to commit under different names. I think for this reason a lot of the contributers are not mentioned in the git log. If they contributed when Compiz was in cvs then the patch appeared to be written by David.

I am a bit confused by the whole 'one developer' argument. Wikipedia shows FIVE people as developers. David Reveman, Matthias Hopf, Dave Arlie, Adam Jackson, Jon Smirl, I am sure all these people have git access or could get it if they want.

David is the main developer and the lead developer, but thats only because nobody else contributes any where near as much as he has and does.

[racarr]

I would like to point out
http://lists.beryl-project.org/pipermail/beryl-dev/2007-March/000277.html

[imnotpc]

I would like to point out
http://lists.beryl-project.org/pipermail/beryl-dev/2007-March/000277.html

I've suspected those were goals of beryl although I'd never actually seen or heard it stated before. We've been working a long time trying to define compiz and last night I sent out a draft announcement/policy statement which will be reviewed and posted shortly. Among other things it will include our goals and proposed direction of compiz and will be posted for the compiz community to discuss. All Beryl members are welcome to participate in a constructive manner. I've believed for months that our differences are more cultural/personal than substantive and your post only strengthens that belief.

[cornelius]

Just to let you know that this discussion is not over yet:
http://lists.beryl-project.org/pipermail/beryl-dev/2007-March/thread.html

[lowfi]

We do indeed need to choose a third, new name in a merge, and of course
(again) rename the beryl-named components, for the obvious reasons.
What exactly does that mean?
There will be a new name for third party apps and extra-plugins? Or does this mean compiz core should drop its name? I really hope it's the first one.
Btw, CORAL = Composited Opportunity to Raise Awareness about Linux :p
Is that a joke? I'm not sure if a semi-political slogan is the best way to go. Maybe it'll sound just awkward one year from now. (or make that two :D )

[rememo]

First:Great news to see the merge making progress at least :)

But I don't see any reason why David should rename compiz to CORAL. You agreed on using his codebase to code around it and even if you're going to submit many patches during a merge, I think most of the core code will be from David. That's why there is really no valid reason to change the name of compiz-core.

The "compiz-extra" name is afaik not settled and for sure the compiz community-leaders will happily discuss with you about a new name that satisfies both communities, to finally merge them. But I agree with lowfi that CORAL and it's meaning seems strange to me. Compiz and "compiz-extra" should speak for itself not through their name. Anyways, I would vote for a name with compiz inside, to avoid user confusion. I would also like to see a poll about the name, but I think it will be distorted by different user-base size.

[imnotpc]

I think both projects decided independently to create composited desktops based on the compiz core. The Beryl devs already are contributing to the core and it is their's now too. We won't make a decision about the name until all of us agree reunification is the right thing to do.

[imnotpc]

I probably ought to share some thoughts on the name issue. The Managing Committee discussed this at length. We intentionally decided that it was important to differentiate between Compiz, the universal X Server compositing window manager, and Compiz-Extra, the community distribution. We hope that Compiz will become the standard WM across all DEs and X Server platforms. But that can't happen if Compiz also refers to screenlets and kiba-dock and other DE type programs.

With a distinct name and identity our devs are free to turn Compiz-Extra/Beryl into anything they want it to be including DE type programs if that's what the community wants. I don't think what we call it is a huge issue. The important thing is that it has it's own identity independent of Compiz.

[delfick]

i say scrap "CORAL" (it's meaning is too nerdy :D)

keep the name compiz for the thing as a whole and name compiz-extra as the compiz-beryl package.........

move the troubleshooting part of the beryl forums to this forum and change the beryl forums to be completely noob-user orientated (and rename it compiz-beryl forums)

so that compiz becomes the name associated with the main parts of the compositing manager, and beryl becomes associated with the community created parts (plugins) :D

if that makes sense, it does to me :D

(of course to scrap the name beryl as well would be better :P, never did like that name)

but as long as we keep compiz

[lupine]

Coral was a serious name suggestion. CORAL was a joke ;)

It's a merge of the names 'compiz' and 'beryl' (through some now-forgotten intermediate) that I thought of when the subject of a merge was first brought up. It also happens to have huge likeability, amazing artwork opportunity and an organisational (polyp<->plugin) tie-in.

IMO, it's fairly obvious that compiz-core keeps the compiz name, for good or ill. As for compiz-extra... whether beryl and that merge under a new name (Coral or whatever, it's just a suggestion by Yours Truly after all ;) ), or if beryl becomes whatever and "competes" with compiz-extra (which also becomes whatever), is one of the details that has to be hammered out, I guess. Since the flavour of the month is merging, I'd imagine the former is what most people on both sides will be angling for.

/Nick

[delfick]

Coral was a serious name suggestion. CORAL was a joke ;)

lol... :oops:

i still don't like "coral" :D

(even before the CORAL "joke")

[RYX]

We should try to get everything together first instead of creating another wannabe-DE.

Most important tasks are to move additonal tools (settings, decorator, ...) and other "homeless" apps into compiz-extra and continue developing cool plugins and apps for compiz and the composited desktop. Developers should focus on porting their code/plugins to compiz - as long as it makes sense and doesn't introduce any beryl-bugs to compiz.

I also have some quite nice ideas for a new name (and I'd really like to tell you) but I think we should first get everything to a state where it deserves a name different than compiz-extra.

(So mikedee is right in what he says)

:)

[Alejandro Nova]

I have another name for the naming brainstorm: Moonstone. It's another beautiful stone (http://en.wikipedia.org/wiki/Orthoclase), and, if you watch Sailor Moon, you'll see another reason (http://en.wikipedia.org/wiki/Queen_Beryl#Queen_Beryl) for this name ;)


...joking...

[lupine]

OMG, teh animes! In that case, I suggest "Chi"!

Ahem. Yes - the name is essentially unimportant anyway, and should probably be community voted or, erm, something.

In case anyone's wondering, my position is one of interested trepidation. I certainly hope it's going to work out well, anyway :D.

So, um, I'll be around if, you know, anyone wants me for anything ;). Still willing to help with packaging and hosting whatever we end up with at the end of all this organisational rejigging.

/Nick

[imnotpc]

The name is for public use. We know who we are. Great to see you here lupine! BTW, where did your nick come from?

[lupine]

My nick came to me in a dream. No, really, it did ;). Life-changing experience and all that. I've had it since 2001, anyway, so I'm firmly attached to it these days!

(For those who don't know, lupine is latin for "from, or having the character of, a wolf" - like bovine is to cow).

/Nick