Why beryl by default?

[Guest]

Reading the beryl roadmap - http://bugs.beryl-project.org/trac/wiki/Development%20Roadmap , It seems that ubuntu is going to include beryl by default when it has made a few improvements...

gconf support - Compiz has this already, I seem to remember beryl didn't want to use it. Wasn't this the biggest reason for the compiz/beryl split?

Heliodor will be default (I think), which is a compiz project. Would it not help to have the developer of the window decorator on the project?

"New frontends to configure and control Beryl while presenting the user with as few options as possible need to be designed and implemented."
Beryl has gnome-compiz-manager (exactly for this purpose) and then soon another configuration tool for advanced settings (http://zootreeves.googlepages.com/Screenshot.png - unfinished), all using gconf.

Stability improvements - Compiz is a lot more stable than beryl.

Obviously there are still things that compiz needs to do in order to meet ubuntu's requirements, but it seems to me there is much less than beryl needs? Has David R (or anyone else) talked to ubuntu about getting compiz installed by defailt?

[RYX]

I followed the "rumours" about beryl being included in Ubuntu and afaik it is either compiz or beryl - it isn't decided yet. And I think if the distributors look behind the "shiny bling", they may notice that compiz and beryl are still the same ... everyone knows where all the ideas come from. One problem could be that David is maybe not interested in including compiz in Ubuntu (why? because he is a Novell employee ...) ... but maybe it is true that compiz is no Novell-project anymore ... (can someone shed any light on this?)

Concerning the decorator and settings: I wanted to keep it as a surprise but I am working on a new decorator (as discussed in Ideas-forum) which offers a lot more flexibility than heliodor, g-w-d, emerald and whatever ... It is a plugin-based modification of gtk-window-decorator that includes a plugin-based user-definable menu, plugin-drawn decorations and other nice improvements. What I have in mind is to offer a configuration-system for compiz and the decorator - which is entirely "hidden" in the titlebar-menu (which is also shown on border-click with my version) ... I am no big fan of the gnome-idea to hide anything that a total noob might not understand within gconf-settings. In that certain case I prefer the OSX-way, where the window's right-click menu holds a lot more settings and options ... If we could user-define that menu and connect it to shell commands and simple gtk-dialogs, we have a complete settings-frontend - extensible to the extreme and included within the window (where those settings logically belong).

I think the compiz-roadmap is focusing more on fixing the real problems, beryl only tries to fix the results of the real problems (and the re-implementation of gconf is really ridiculous ... why did they move to their own system first?).

Just my thoughts on this ...

Edit: After reading the whole story on ubuntu.com, I want to add that I hope we can get both (compz/beryl) to be included by default. I would like to see a more or less peaceful co-existence. Competition is good, but a race to the goal "boecome-ubuntu-default" can cause bad side-effects and the end-user could be the real loser of the fight ...

:)

[apokryphos]

Yeah, it hasn't been decided just yet. See the spec here:
https://features.launchpad.net/distros/ubuntu/+spec/composite-by-default

[mikedee]

I think you are totally right, like RYX says though, it isn't decided yet which if any will be included by default.

As far as I can see the whole Beryl project has been based on pride right from the start, it was always their intention to try to become the default for every distro. Now everyone has produced their official roadmap, I am very happy that I supported Compiz.

They are free to take their project and do whatever to make it included by default. My opinion is that David (and us) should work towards providing the best software. His roadmap shows that he really is interested in third party plugins and that he is interested more in the features than the politics.

Beryl will suffer in my opinion because they have decided to freeze their development for Ubuntu, I think that most of Davids roadmap will be completed after they have frozen. Users unfortunatly suffer in the end which is what makes me unhappy.

[stalynx]

I wouldn't be too surprised if beryl is included by default into Ubuntu for political reasons. I don't use ubuntu so it doesn't mean much to me. In the long run tho compiz will be the better product mainly because DavidR is so much more experienced with X11/Xlib and programming in general. I can see Beryl becoming overwhelmed with silly bugs that could have been avoided if they had more experienced programmers. Not to say the beryl dev team are bad programmers but they are surely lacking in real X development. Plus anyone who has done any Xlib knows how obfuscated it is and how many of the new extensions lack any real documentation. Not only that it's real easy to make errors and adopt bad programming practices.

Currently the compiz community is lacking though. I hope more people get on board.

[Guest]

Sorry I thought that beryl had already been chosen as default, thats why i posted. I just find the whole thing so Ironic that the main modifications of beryl (beryl-settings and emerald) are going to be removed, it just makes the whole fork thing pointless.

I am working on a new decorator (as discussed in Ideas-forum) which offers a lot more flexibility than heliodor, g-w-d, emerald and whatever ... It is a plugin-based modification of gtk-window-decorator that includes a plugin-based user-definable menu, plugin-drawn decorations and other nice improvements. What I have in mind is to offer a configuration-system for compiz and the decorator

Sounds good, If you want something initial to built on I still have yawd (yet-another-window-decorator) floating round somewhere. It already has a small frontend and themeing support.

Edit: After reading the whole story on ubuntu.com, I want to add that I hope we can get both (compz/beryl) to be included by default. I would like to see a more or less peaceful co-existence.

I can't see that happening, I think it's pretty much got to be one or the other, but I agree it's a shame that they cannot work together.

Currently the compiz community is lacking though. I hope more people get on board.

Give it a chance, the forum hasn't been open for very long. :)

[amgeex]

Currently the compiz community is lacking though. I hope more people get on board.

Yeah, give it a while. And really, a lot of people will prefer using compiz instead of beryl, because beryl has too much useless stuff. I know its nice to see your windows burn, but its really not great from a usability standpoint. I prefer something that makes me more productive to something that eats up my performance. :roll:

[mikedee]

http://lists.beryl-project.org/pipermail/beryl-dev/2006-November/000023.html

This is what she said about gconf and we all know where that got us...

Also love the 'inherited' code bit. They are now off to 'inherit' some kwin and metacity code.

[profoX]

And really, a lot of people will prefer using compiz instead of beryl, because beryl has too much useless stuff. I know its nice to see your windows burn, but its really not great from a usability standpoint. I prefer something that makes me more productive to something that eats up my performance. :roll:
This is a dumb reason to choose compiz over beryl, because in a cleaned up release most effects will be disabled by default. And you can always enable/disable effects yourself and change the settings of those effects.

[iznogood]

Hi profoX,
its nice to see people from beryl posting here too...

However i would like to ask you (or any beryl developer) a simple question:

What is the difference of compiz over beryl??

Surely its not the configuration clients or the theme engines. I mean the internal diffs, to the core, that provide enhanced functionality and the ability to explore new areas of UI effects through plugins that the previous releases did not make that possible.
Now most plugins are ported to compiz thanks to the great job of mikedee and some others.I can not see much difference in any of these from a user perspective, maybe there are differences to the code but i haven't done any kind of search for that...
Also i am sure that enhancing an existing theme engine is better than fully rewriting it, unless ofcourse someone is doing it as a learning experience.

Anyway, since people from compiz are going to continue port plugins from beryl and people from beryl are still going to merge code from davidr and others, why keep up the current status???
I mean that obviously beryl devs would like to continue their work on the fork but maybe some communication channels could be found that all can benefit and reduce incompatibilities.If that is already in progress please say so, i may not be informed of it...

Finally i DO NOT want to start a new flame war.
If anyone wants to post anything that might provoke this please don't.
I just would like to know where people from beryl stand right now. There are people there that do a good job and it would be nice if they could cooperate with people from compiz.For me the actual reason of the fork was that people wanted many UI effects in a hury so that they could impress users,also some distros like ubuntu might be behind that which is actually a good thing.
However this has been accompliced in a great degree, so what are the actual reasons ???

[FunkyM]

iznogood: Afaik. it boils down to people having different attitudes.

The compiz "people" prefer clean fundamental development (slow, modular code) while beryl "people" hurry to inefficiently implement eyecandy (fast, dirty code).

[cole]

I saw this today, its interesting because QuinnStorm talks about X.org at the Ubuntu Developer Summit. Well I presume its the same Beryl QuinnStorm?

http://community.linux.com/article.pl?sid=06/11/13/2112259&tid=53

[mikedee]

Quinn is talking about Beryl, not sure why it is marked up as x.org...

It is the same Quinn and I suppose this is the best that we can hope for as far as a response as to exactly why beryl is necessary.

I think it boils down to doing whatever the community wants (windows that wobble to the beat of your music and more bling) and getting included in Ubuntu.

This is the only other quote about what Beryl provides

The one thing beryl can provide is effects which were previously far too cpu intensive .... things like accessibility features... full and partial screen magnification (David)... various kinds of overlays.. err.. color inversion (neg - Moppsy)...errr.. coloured overlays...errr... ..... desaturation (eh?), those kinds of things....

Me thinks that Quinn should probably write notes before giving interviews in front of the camera.

I do notice a slight change in the tone of the fork, it is now described as "based on compiz like ubuntu is based on debian". I am glad to see this since there is no way beryl is a true fork since they take all of Davids changes, forks are where codebases totally diverge.

There is nothing new in the interview which is a shame because they had enough time to prepare a good speech on their goals and views.

Whilst we are in the question asking mood, could I ask what happened to the effort to port improvements and bug fixes back to compiz? DBO talked about them on the forums but I havent seen anything yet.

To me it looks like the real innovation in the future will come once we have proper input redirection and David has worked his magic with it.

Dont take this as a flame, its more dissappointment in mankind :cry: I do not personally think there is a rational answer to the question because Beryl is some sort of paradox whereby it only exists because it exists. That is why there is not a flood of rational answers from the beryl devs (please please beryl devs prove me wrong - I know at least some of you are reading this).

[Guest]

Whilst we are in the question asking mood, could I ask what happened to the effort to port improvements and bug fixes back to compiz? DBO talked about them on the forums but I havent seen anything yet.

Beryl are now GPL'ing all their code, so beryl can take compiz code (MIT to GPL) but compiz can't take any beryl code (GPL to MIT). So i wouldn't expect to see any improvements coming back any time soon... Maybe it's just me, but I think if beryl has no plans to give anything back to compiz then they should stop taking compiz code. Simple.

[mikedee]

Whilst we are in the question asking mood, could I ask what happened to the effort to port improvements and bug fixes back to compiz? DBO talked about them on the forums but I havent seen anything yet.

Beryl are now GPL'ing all their code, so beryl can take compiz code (MIT to GPL) but compiz can't take any beryl code (GPL to MIT). So i wouldn't expect to see any improvements coming back any time soon...

That is what I am referring to, DBO pointed this out and said we cannot submit code at the moment until the licence is sorted, he them promised they were going to sort this issue.

I personally think its a bit of a red herring since David is the majority copyright holder he would never be taken to court for taking beryl code back, as far as I can tell the licence would have to be enforced by someone and there just isnt anyone who would do that. I am not a rah-rah type with a wig but I am fairly sure that any sort of case against David for incorporating beryl code would be thrown out of court within 5 minutes. Also the SCO-like titlewave of hate would really not help their public image.

Their licence change just shows how short sighted they are, the real side effect for them as far as they will see is that it is impossible to write closed source plugins, people may have their own opinions on that, but David decided to allow it by using the MIT licence not solely GPL. Plugins can be GPL but the core must remain MIT or a less restrictive licence. All the open source software that allows plugins (or some sort of code 'linking') etc has a non-GPL licence for this reason (Mozilla, Apache, PHP to name a few).

[nzjrs]

After looking at the beryl roadmap and knowing that Ubuntu had a google SOC project on a compisite screen magnifier i think the most interesting thing that beryl is going to be working on is their improved zoom plugin

So this is probbably the most useful thing to port back to compiz when it is complete?

Comments?

[stalynx]

As far as the GPL -> MIT issue, if there are important bug fixes or improvements going into beryl that can still be applied to compiz just submit a bug report or send an email to the mailing list describing the bug fix/improvement in plain language. Sure you may not copy the code cut-n-paste style but there is nothing stopping you from taking the basic idea and communicating it to DavidR. There is however a protection for this, it's called patents and I doubt Beryl developers are going to start submitting patents.

[mikedee]

I am not sure what (if anything) is improved in their zoom plugin, if you mean the izoom plugin then it could easilly be ported (probably) but it would have a very short shelf life because it is just a quick hack until we have input redirection, this will hopefully be released soon.

David mentioned an improvement to the standard zoom which would be to have the zoom region selectable rather than a standard zoom. The output cloning plugin could come in useful here because we could have a zoom plugin which has a live thumbnail of the whole screen in the corner, this could be active and move the screen zoom area around (like photoshop does).

Individual window zooming might be a nice addition too. Scaling individual windows will be much easier for plugin writers once we have items 2-4 on Davids roadmap are done (and of course input redirection)

So, short answer is no really :) but then I haven't looked at it yet, I might have a look at moving it over though. Check my beryl-plugin porting guide if you fancy having a go yourself ;)

[mikedee]

There is however a protection for this, it's called patents and I doubt Beryl developers are going to start submitting patents.

To be honest, I doubt beryl developers have anything to submit, unless 'coloured overlays' are patentable... Thanks for the laugh anyway :lol:

[FunkyM]

I think the noted zoom work is another perfect example of how different the "road" for beryl and compiz really is.

Now quickly hack a pseudo-input zoom plugin, then throw it away once David does it right when input redirection goes upstream and merge it into beryl somehow...

[QuinnStorm]

To comment on the licensing issue.

At this point we at Beryl have no desire to change licenses, the GPL-only approach was chosen intentionally.

As for closed-source plugins: that is exactly the point of going GPL-only. I am not a believer in enabling the enemies of FLOSS.

As for inheriting code, is that not the point of FLOSS? Without the right to fork and inherit code, FLOSS would rapidly stagnate.

I have to admit, I don't understand the animosity I see here. I hope that it comes mostly or completely from misunderstandings, as Beryl has no intention of doing anything to harm Compiz, and in fact wants to work with Compiz as much as we can, though it is well known that we do have different development styles and goals.

[RYX]

First to say - hi, QuinnStorm. I want to note that the "anti-beryl attitude" is not the general opinion around here and it is quite obvious that compiz and beryl have a symbiotic relationship.

I hope we can try to improve communication between the two projects and I really welcome that you (as the so called "leader" of the beryl-project) registered here.

:)

[QuinnStorm]

It would not be in keeping with my ethics to not register here. I value open discourse and hope that indeed the projects can work symbiotically. As for me being the leader of the project, at least in a management role that can indeed be said to be true, though I don't keep an iron grip on the reins (of course this is all the better when I DO have to make an important decision)

Anyhow, thanks for the cordial welcome. I agree that communication needs some improvement here.

[nzjrs]

It would not be in keeping with my ethics to not register here. I value open discourse and hope that indeed the projects can work symbiotically. As for me being the leader of the project, at least in a management role that can indeed be said to be true, though I don't keep an iron grip on the reins (of course this is all the better when I DO have to make an important decision)

Anyhow, thanks for the cordial welcome. I agree that communication needs some improvement here.

Yes welcome! It is good to see your voice present in the technical discussions over here.

To be honest I wish that you had of spoken up against some of the children on the Beryl forums when they were railroading the discussions me and mike raised into total flamefests,

But hey, the past is the past right. I look forward and hope we can work together to once again inherit any improvements in beryl, perhaps acting as a proxy to help get stuff upstream

That should definately be possible and easier once we can maintain a community git branch

[mikedee]

As for closed-source plugins: that is exactly the point of going GPL-only. I am not a believer in enabling the enemies of FLOSS.

If the point of the beryl fork is to make it a totally free version of compiz, following Stallman style rules then why do you allow it to run on top of and require closed source binary drivers?

Surely people using closed source drivers is against your morals and people upgrading their cards to run beryl are only fuelling the enemies of FLOSS (I have put money in their pockets, I am sure others have). In fact, if it wasnt for the enemies of FLOSS, blurfx would not work at all. You have the ideal opportunity to spread the use of open source drivers, but you choose not to.

How do you rationalize this aparent hypocricy?

[delphinen]

I just hope GPL v3 will stop this kind of people from sucking popularity like Beryl did : http://www.google.com/trends?q=beryl%2C+compiz&ctab=0&geo=all&date=2006

I hope youre enjoying your donations and popularity Quinn and Beryl team, but keep in mind, that you guys will never be liked by the community, and im not talking about Ubuntu users, im talking about developers, that after all, are the main persons who fuel this whole thing called open source.

[Amaranth]

The ability to fork is a key thing in free software, I doubt GPLv3 is going to break that. Of course, the idea is supposed to be that everyone benefits from the fork due to the ability to merge things back and forth...

[RYX]

I don't like this kind of discussion because it leads to nothing and is totally pointless. However - I cannot simply watch it without adding something...

I don't understand why certain people around here still just can't stop attacking the beryl-project. It is nothing more but ridiculous to, on the one hand be porting all new plugins from beryl to compiz and on the other hand be complaining and whining about the "bad beryl guys" who "stole" poor David's beloved project, I see no use, benefit or reason in forbidding other people to fork GPL'ed software. As Amaranth says, "The ability to fork is a key thing in free software" and everyone who is questioning this is an even bigger enemy of FOSS than everyone he maybe sees as the real enemies. Nobody in the beryl-project ever disallowed to port code back to compiz - we shouldn't be the ones starting such an egotrip-behavior ...

These are my thoughts on this - feel free to have your own opinion ...

[watkin5]

I don't like this kind of discussion because it leads to nothing and is totally pointless. However - I cannot simply watch it without adding something...


Try harder to not add to the totally pointless.

[RYX]

I don't like this kind of discussion because it leads to nothing and is totally pointless. However - I cannot simply watch it without adding something...


Try harder to not add to the totally pointless.
You're right, I should have kept quiet on that. I only want to point out that the critical feelings concerning beryl and its developers are not soooo interesting to pollute every single thread with it ...

[mikedee]

I seem to remember it was the beryl devs who came here seeking some sort of acceptance. We were doing fine until they all started sniffing around.

What do they want anyway?

[RYX]

I think we were and still are doing fine. The idea behind an open community is to let all people in - even (and maybe especially) if you don't like (i.e. simply don't understand) those people's opinions and feelings. Free communication is the biggest value of the internet and such a "cold-war"-attitude is bad for everybody's freedom.

I respect what you do for compiz and the community, but I strongly disagree with your way too offensive anti-beryl-attitude and ask you to stop posting such provocations. Nobody is "sniffing around" - this is a free forum and everybody is welcome here! Being the one always talking about David's opinion on everything you should ask yourself what David thinks about those silly, open attacks against beryl. You are old enough to keep a certain level of politeness and respect and as an "official" Developer you have a certain responsibility.

[delphinen]

mikedee has stated many times why he act and think like he does, he never lied and always presented proof of his words. I prefer him talking openly about his ideas than a fake Beryl developer not telling the truth.
And by the way, im pretty sure David thinks the same way mike does.

[iznogood]

RYX,

you are wrong, there are much more at stake here than the obvious. I can say a few things but i choose to remain quiet.

Mikedee is right, you only have to check the beryl development model to see it. Compiz is extremely important to the Linux community, but the fact is that someone who is not qualified (Quinn) is in charge of it. What this creates can be seen just by looking at the code.I have no problem with the other developers but i believe that someone with more skills should be in charge there, someone who can provide assistance about the internals of X, someone who would care more about the status of the code...
He says that he has 20 developers, but i don't see any breakthough changes. I do not see even proper code maintenance or refactoring.The API of compiz is rapidly changing and if their community is so active they should care about updating the plugins to the new API, not just writing new code-effects. Every developer wants to impress by implementing new features but its up to the PM of the project to accept it or not, and to set a roadmap. I do not see that happening. Many plugins need maintenance and also some libraries need to be created to wrap functonality but usually this means many hours of hard work and people often find this unpleasand or useless especially if you do not get paid for it

Anyway i can say more but i would prefer if this whole subject is closed and also there is not need for bad comments from either side. We are not 15 years old, we can see whats happening, but it is not up to us to fix it

[mikedee]

Nobody is "sniffing around" - this is a free forum and everybody is welcome here!

Yes you are correct, they are all welcome if they want to contribute :)

Let me explain something which is going on at the moment though, you might not be aware.

Amaranth is looking at the dbus bindings because he is obviously a python wizard and he wants to write a python settings manager. He spent weeks and weeks writing python bindings for libberyl settings. Once he was finished all of his work was tossed in the bin because of Quinns GPL only attitude.

If I was him, I would be a bit upset that the GPL only policy wasnt made more clear earlier. Maybe he doesnt have a problem with it, but it all seems like a huge waste of time to me.

I think if these people made their intentions clear from the outset them people could agree or disagree, unfortunatly the reasoning was all nonsense like 'we will do what the community wants' 'we have a special way of developing that David does not understand'. As a logical coder type person, this type of argument is very offensive because it treats us like idiots.

I think it is easy to say that people dont agree with the fork just because they do not understand, but I think it is treating us with a lot of disrespect to not even give a good reason for forking. Forking is a very last-resort in the open source world (just look how long it took to fork XFree -> xorg). Quinn rushed to fork with no good reason, now she is facing the backlash. They thought they had everybodys support, but unfortunatly they never asked anyones opinion.

[iznogood]

I think it is easy to say that people dont agree with the fork just because they do not understand, but I think it is treating us with a lot of disrespect to not even give a good reason for forking. Forking is a very last-resort in the open source world (just look how long it took to fork XFree -> xorg). Quinn rushed to fork with no good reason, now she is facing the backlash. They thought they had everybodys support, but unfortunatly they never asked anyones opinion.


I agree 100%. Since last week i try to implement a few things (hacking state plugin) and i can see that the core of the project is pretty small. This makes it an ideal project for people to start working on, and actually trying to make a name for themselves. If someone has the time its not too hard to start implementing things. Try that on X and things are quite different ...

Or maybe ubuntu people are behind this who knows... and who cares ...

[RYX]

Mikedee, you should still remember my opinion from back when the fork was done. I expressed my feelings about all that on the old beryl-forums.

Only for those who don't know - I have exactly the same opinion as mikedee and all you others about this (that's why I use compiz and not beryl). As far as I remember I was the first person who very directly criticized the beryl-devs for the fork and especially the way it happened (being announced, not discussed, name chosen on IRC, ...).

However - what I would like to see is a more friendly manner of discussing these things. Mikedee can have his opinion but it is not acceptable if he is trying to influence new users with his very negative view and pollutes any posts where the word "beryl" is used with his statements about the beryl-devs/roadmap/code/....

If everybody is so sure that beryl's development/roadmap are bad and lead to chaos - why do you not lay back and watch it dying? Stop commenting on that topic and let the users decide which one they choose.

Concernig the licensing issues I have no further knowledge why GPL'ed software forbids to release python-bindings for it. Maybe you can explain a little further?

:)

[RYX]

And, sorry to say (I don't want to criticize anyone), as far as I can remember the switch to GPL was said to be one of the major reasons for the beryl-fork back when it was done. It should be well-known since the very first day of the beryl-project that they use the GPL. That GPL'ed software can not work together with MIT/LGPL/... is very new to me (though as I said I have no clue about licensing issues).

[mikedee]

However - what I would like to see is a more friendly manner of discussing these things. Mikedee can have his opinion but it is not acceptable if he is trying to influence new users with his very negative view and pollutes any posts where the word "beryl" is used with his statements about the beryl-devs/roadmap/code/....

It isnt just me :) - the code speaks for itself. What I want to do is make sure that the users have both sides.

http://www.ubuntuforums.org/showthread.php?t=308606&highlight=compiz

BTW - what things are we discussing again? I thought Quinn was just here to try to educate us as to why she is right.

If everybody is so sure that beryl's development/roadmap are bad and lead to chaos - why do you not lay back and watch it dying? Stop commenting on that topic and let the users decide which one they choose.

Call it some sort of wierd morality. I feel compelled to at least mention these things. I find it hard to just watch as their code gets buggier and slower (taking the reputation of linux with it).

Concernig the licensing issues I have no further knowledge why GPL'ed software forbids to release python-bindings for it. Maybe you can explain a little further?

The GPL licence does not forbid anything, normally if you are writing a binding library like the beryl -> python bindings you would need to write the library as LGPL so that people who write programs using it are not forced to adopt GPL. Most languages are released under this sort of licence. If PHP was GPL then every PHP script would also be GPL too (or it could be argued anyway - GPL is untested)

I suspect that Amaranth wanted to release under LGPL.

Dbus is actually a better solution because there is no direct linking so you could write the settings manager under any licence, it does not have to be GPL.

[RYX]

OK, thanks for the explanation of the license-problem. Maybe it is intentional, maybe it is not - I don't want to judge about that..

I don't want you (or anyone else) to entirely stop showing "both sides of the medal". It is important to do that. But if you always point out how professional compiz is (compared to beryl), we should behave like professionals. And professionals (try to) stay neutral, respectful and objective in what they say about others - that's all I wanted to say. (nobody always does, but let's try our best)

So don't get me wrong ... I'm on your side, guys!

:)

[imnotpc]

I think we are all exerting a lot of time and energy on this thread that could be put to better use. Everyone's had their say, now let's move on and re-direct that passion and energy back to the project.

[mikedee]

Yep +10

[iznogood]

ok

oh one final thing... We need the git and we need it NOW. I read the ubuntu post from mikedee and if people start sending more patches then we will have a hard time managing them. How is this going on??

[PaK]

Git Hostings:

Public Git hosting site, maintained by Petr Baudis
http://repo.or.cz/

Savannah git hosting
http://git.sv.gnu.org/gitweb/

[mikedee]

David was arranging for an official unofficial repository, we are waiting for that at the moment, hopefully it will not be too much longer.

[imnotpc]

I have nothing to do with the official git repo but I have a server with decent bandwidth which I use for my "hobbies". I would be willing to host a temporary git site if that is helpful.

[nzjrs]

Well I will just throw my hat into the ring on this...

I feel no real ill-feeling towards the beryl devs. I mean FOSS is an education, and without seeming condescending I think that mistakes like the fork are all part of that education. No-one is above learning, we all saw how David, to his word, has become more open with Compiz development.

But I am worried about all the FUD spreading. I am worried that the couple of hundred tweenagers that frequent the compiz forumns will leave with this impression that "forking === FOSS" because that is very untrue. I raised the point on the previous beryl forum that the key tennant of FOSS is the FREEDOM/ABILITY to fork, to create derivitive works, it is neither an all-encompassing excuse for forking, nor is it a replacement for critical thought.

Indeed, one of the ways in which FOSS excels is through technical excellence, open discussion, critical thought, and a democratic-like-process where "code is king".

Now we have this weird situation where Beryl was created due to a lack of openness on the part of David, which I agree with. But the baby was thrown out with the bathwater - so to speak.

The Beryl devs seemed determined to NOT engage in any open discussion about the necessity of a fork, they show very little evidence of critical thought in their development model. The democratic-like-model where "code is king" has been replaced by some reverse system where the number of feature requests a foumn poster makes is proportional to their standing in the community (judging by some of the mudslining on the beryl forums anyway). Furthurmore the main contributor to Compiz is given 0 input in future directions, how often doesn Quinn or co. speak to david for example?

Finally the Beryl community seem intent on presenting this false dichotomy where it is "community vs stable" or "experimentation vs stability" or some other variation where they imply that seperation from upstream is the only way in which they can achieve their goals, or that David and Quinn have some conflicting vision on the linux desktop. Furthur to my point of critical thought and technical supperiority I suggest that the problem of developing two parallel branches of software with different goals at the same time has been solved x times using y different version control systems; look at the kernel, the parallel development of KDE3+4, etcetera to infinity

In conclusion, when I got excited by the rapid progress of Compiz a year ago I hoped that its rapid development pace, stability and rocking feature set could be the poster child for the efficiency of FOSS. Now I look to 6 months time and I fear that the Compiz+Beryl fork will be the new iconic representation how "Linux is still so close, but so far from the desktop" - Users will be confused between the two, there will be subtle inconsistencies in how application behave in them, and neither will have achieved its full potential.

[iznogood]

In conclusion, when I got excited by the rapid progress of Compiz a year ago I hoped that its rapid development pace, stability and rocking feature set could be the poster child for the efficiency of FOSS. Now I look to 6 months time and I fear that the Compiz+Beryl fork will be the new iconic representation how "Linux is still so close, but so far from the desktop" - Users will be confused between the two, there will be subtle inconsistencies in how application behave in them, and neither will have achieved its full potential.


A very nice way to express everyone's feelings