原帖见： http://www.compiz.net/topic-4562-1.html
http://www.compiz.net/topic-4591-beryl- ... nouncement
中文翻译见： http://bbs.lupaworld.com/htm_data/46/0609/22247.html
Beryl 项目正式分离出 compiz 的官方声明（译文）
Tuesday, 19. September 2006, 18:04:32
xgl
原文在 http://www.compiz.net/topic-4591-beryl- ... nouncement ，抽时间翻译了一下。尽管几天前就有消息说 quinnstorm 分支 compiz 将改为单独的项目 Beryl。直到刚才去 compiz.net 才看到正式完整的声明，由法国成员 iXce 发布:
大家好!
Beryl 项目的发布比计划的要早，介绍项目原因和目标的消息也一直不完整、不清楚。我将尽力阐明这些问题。
首先，我们来明确一下这个分支项目产生的原因。
Compiz 于今年年初发布，并且迅速吸引了一些第三方开发者对其进行改善。他们为 compiz 加入新的特性和插件。随着大家兴趣和贡献的增加，建立了一个新的 compiz 分支， compiz-quinnstorm, 并开始与官方的 compiz 分野越来越大。在这个夏天，尤其是最近几周，quinnstorm 加入了一些重大的改变。它有了全新的窗口装饰程序，cgwd，可以全面彻底的更换窗口主题。还有全新的设置后端程序 csm，主要用来解决众多对 gnome 的依赖性问题 - 设计这个后端也有其他的原因，但这里不做赘述，毕竟这不是我们的主题。自然的，以我们现在的形势不能再走回头路了。
很多人建议我们把这些补丁发送到邮件列表。但是首先，把全部改变推入上游的官方 compiz 是不可能的，因为有些变动很大 (csm)，或者牵扯众多的代码/插件(xinerama)的改动。更何况，我们不确定官方 compiz 维护者 David 是否愿意接受这些补丁。我甚至估计大部分补丁会被毙掉。比方说前一段的 Xinerama 事件；David 倾向于加入自己的东西。他在 Xgl 内部加入了一种 Xinerama 支持，但与现在 Xorg 的 Xinerama 支持不兼容。更不用想 csm/gconf 的问题了，我恐怕 Novell 永远不同意放弃 gconf 配置 compiz 的方法。
然后，我们还有沟通问题。你可能已经注意到了，邮件列表没有多少流量。David 从不发布他的想法，也不发布长期的计划。没有官方发展路线，没有官方目标。有人见过 David 在论坛上发贴子或者聊 IRC 么？从来没有。他可能不喜欢论坛和 IRC，但是我们喜欢。这足以说明我们在交流上的看法是不同的。分出单独的一个项目将让我们可以设定自己的发展路线、目标、发布周期……
最后，但不是最不重要的一点，发行版整合问题。目前 Ubuntu Universe (Edgy) 中的 compiz 包是 compiz-quinnstorm，从而引发争论，有人认为那里应该是官方的 compiz ，毕竟它是官方的而且更稳定。至于 Debian，相似的问题阻止了它进入软件源。看上去唯一的解决方案就是我们分离出来成为一个单独的项目，然后官方包和我们的包可以作为两个不同的项目共存。
现在你们知道分离出项目的原因，我们来聚焦一下将要做什么。
直到目前我们组织的很不好，现实的说，杂乱无章。既然我们有了自己的项目，就会立下规矩。代码规定，目标，发展路线，发布周期，所有这些都将明确。我们主要计划发布两类包，一类是稳定版，仅仅有重大 bug 时才进行修改；还有一类非稳定版，有最新特性，但是可能有一些 bug 。
修复 Bug 是现在首要的任务，因为我们将制作“稳定”版本，而不仅仅是“最炫”版本。制作后者是我们曾经的一贯做法。
制作文档也是我们一个主要目标。我们自然会制作一份完善的开发用文档，尽可能多的注释代码。此外，我们也会弄一些完整的教程，进可能的简单，涵盖进可能多的发行版。
添加新特性显然也会一直坚持下去，我们将尽全力而为，倾听社区－你们的意见。如果你有好主意，说出来好了。从现在开始我们会重点注意可用性，但也永远欢迎视觉特效。我们将比以前更稳妥的行事，突然引入 csm 这种事将不会再发生。
请注意，只要可能，我们仍然会尽量与上游的官方 compiz 保持同步。
简单提一下项目的管理。我们将尝试把补丁发移到 bug 追踪系统。这样可以更方便的提交补丁和升级。我们也试图把所有 bug 报告导入 bug 追踪系统，方便“捉虫”。还会增加一些邮件列表，发布声明用，还有一个进行技术讨论。论坛用作用户交流：讨论、评论教程、预览／讨论…… Wiki 用于文档和教程。此外，会建立一个公开 blog 记录变动，供关注者留心变化。总结最主要的变化就是，论坛仅用于讨论， wiki 仅为文档， bug 追踪系统用于技术数据，blog 发布新闻，邮件列表则是更正式的讨论。
最后，请记住这是一次友好的“囗囗”。我们和 David 没有任何矛盾，我们理解他可能为 Novell 工作有些束缚。我们只是需要更多的自由。在此感谢 David。你带给我们的高质量程序，我们将努力维持它的品质。
谢谢你花时间读这份声明。
Beryl 万岁！
提示：先不要急着要 beryl 软件包或者 ebuilds，我们还在修复 bug，目前不想发布一个不稳定版。
Well, as is usual with these things, the cat fell out of the bag before I got a chance to announce it. Anyhow, here it is, the official announcement of the Beryl project.
Beryl is a fork of compiz, and a collection of other tools to go along with it.
CSM has become Beryl Settings Manager (beryl-settings)
CGWD has become Emerald, with its companion emerald-theme-manager.
The entire project is currently hosted in SVN at:
svn://metascape.afraid.org/svnroot/beryl
You can check it out from there, or if you want to develop for it, get in touch with one of us and we'll set you up with an account.
All of the work that had been maintained as the community or 'quinn' tree of compiz has become Beryl. This change is necessitated by the difference in direction and vision of our community as compared with davidr/novell's approach.
The first release of Beryl is not far off, but is still pending some major bugfixes that need to be implemented. We want to close as many bugs as possible with the first release.
Beryl has been announced earlier than planned, and nothing clear and complete has been published, to explain the reasons and the goals of the fork. I'll do my best to perform that.
First and foremost, let's enlighten the reasons of the fork.
Compiz went out in the early weeks of this year, and immediately interested some third-party developers, willing to improve it, by adding their own features and plugins. Quickly the interest grew and the newly founded branch, compiz-quinnstorm, began to become really different from official compiz. During this summer, and during the last few weeks, some major additions were done in compiz-quinnstorm, bringing a whole new decorator, cgwd, which was designed to be fully themable, and a new settings backend, csm, which intended to drop most of the gnome deps - there were other reasons for this, but this is not our current subject. Consequently, we reached a situation where it's quite impossible to come back.
Lots of people suggested to send our patches to the mailing list. Well, first it'd be quite impossible to send all the changes upstream, since some of them are really deep (csm), or are related to a lot of code/plugins (xinerama). Furthermore, it's really unsure that David would happily accept these patchs. I'm even nearly sure that most of them would be rejected. Check the Xinerama issue ; David is willing to implement his own stuff. He added a kind of Xinerama support inside Xgl, which does not look to be compliant with the one that is currently inside Xorg. And don't even think about csm/gconf problem, I fear Novell won't ever accept to drop gconf.
Then, the communication problem. As you may have noticed, the mailing list is not very busy, David has never really published what he was intending to do and implement on a long term plan. No official roadmap, no official goals. Has anyone ever seen David posting on the forums, or on IRC? Never. He maybe does not like forums or IRC, but, well, we all here do, and it sounds to be a sufficiant reason to say that our views about communication are different. Forking gives us the opportunity to introduce our own roadmap, our own goals, our own release cycle...
Last but not least, the problem of distro integration. The current compiz package in Ubuntu Universe (on Edgy) is a compiz-quinnstorm, and that created a debate because some people thought that the official compiz should be in there, since it is official and appeared to be more stable. About debian, similar problems prevent it's inclusion. It appeared that the only solution to get our branch inside distributions was to really fork, so that official compiz and the community tree would be considered as two different projects.
Now that you all know why this happened, let's highlight what we are going to do.
We've been doing pretty bad in terms of organisation until now. To be realistic, we may even say that it was a real mess. Now that we have our own project, we'll be able to set our "rules". Coding style, goals, roadmap, release cycle, all that will be clearly defined. We mainly plan to have two branches, a stable one, that would only be affected by critical bug fixes, and an unstable one, with new features bug, obviously, bugs that would have not yet been catched.
Bug fixing is now a priority, since we'll have to produce "stable" releases, and not only "bleeding edge" releases, that often looks really unpolished, as we used to do.
Documentation will also be one of our main goals. We'll definitely try to build a solid developer documentation, and to comment the code as much as possible. In addition, we'll also try to get some complete howto's, as simple as possible and covering as much distributions as possible.
Feature addition will obviously be done as well, we'll try to do our best with that, listening to the community - you. Just publish your ideas if you feel they're smart. We'll mainly focus on usability from now on, but some clever eye-candy is always welcome. We'll also try to do things smoother than before, and we'll take care that sudden changes such as the csm introduction won't happen again.
Notice that we will still keep synched with upstream as long as it'll be possible.
Just a few words about how the project will be managed. We'll try to move the patch publication to the bug tracker, so that we'll have a clean place to submit patches and keep the updates. We'll also try to move all the bug reports inside the bug tracker so that it'll be much easier to catch them. A mailing list will be open as well, with announcements, and another one for technical discussions. Forums will be used for end user communication : discussions, howtos comments, plugin development previews/discussions... Wiki will be used for documentation and howtos. Additionnaly, a blog will be set up to keep a kind of changelog that will be readable by everyone, so that there will be a place where anyone can stay aware of the changes. The main difference will be that the forums will only feature discussions, the wiki documentation, the bug tracker technical data, the blog for news, and the mailing lists more formal communication.
Finally, please note that this is a friendly fork. We don't have anything against David, and we understand that his hands may be tied due to his work at Novell. We just need more freedom. Thanks David for the wonderful job you did. We'll just try to keep the quality level you introduced.
Thank you for taking time to read this annoucement.
Long live Beryl!
Quick note : please do not ask for beryl packages or ebuilds, we're in the process of fixing many bugs and don't want to release anything broken/unstable at the moment.
