Where are we going? It's time to start thinking ahead and really figure out how to make Compiz survive, specially in lieu of Dennis' suggestion.
The reality is that there has been the equivalent of no progress since the merge. We've basically only been in maintenance mode. The reason for this, from my point of view, is a complete lack of direction and leadership. We've constantly been waiting for something that will change everything, and whether we call it an object framework, nomad or Compiz++, the reality is that all these branches are counter-productive, regardless of how fun or flashy they are. If we are to have a healthy development environment, and any hope of bringing Compiz out of a constant alpha-stage, we need to have clear development goals and a way to cooperate. Before somebody puts 6+ months of development into their work then present it as a final solution. Our current situation is rather dark, but not without hope. We have very little development power, and we are risking loosing even more, and unless I'm missing something obvious, we haven't seen a single new core developer that contributes significantly to master, since the merge. We have, however, lost a few. We MUST turn this trend around if Compiz is to survive. So why do we loose developers? I see a few important reasons: - The project has no goals, and essentially all development and design is done as a solo race. There's no way to know whether you can work on something without loosing your work because some obscure branch gets merged. - We have an inconsistent organization. Two bugtrackers, one isn't really cared for. Two places to find code. Some plugins are here, and some other plugins are there. Two development mail lists. Messy. - The code is undocumented, specially core, and not particularly pretty. Even new code is added using this same style of no documentation and functions that do more than C functions should do. This is not something new, but even people who realize the problem are ignoring it. It is my honest belief that we should focus on these three major problems, before we do anything. The first step is to decide what to do with the three branches we have going. And we need to know exactly what benefits and drawbacks each branch have, how compatible they are and how the authors envision that they will be maintained. This is where the authors/owners of those branches should come together and start explaining their thoughts about merging and compatibility and maintainability. If not, we really have no other choice but to consider those branches forks of Compiz, and move ahead based on master. It is my wish that we have clear goals for every major release, and finding those goals should be the top priority after a stable release. For each point-release in a development series, we should also have a clear goal. This will make it easier to predict releases and for developers to help. And it's not that hard to figure out. There is also a fourth point that's causing us problems. - Compiz is a research project. Essentially, there's been very little work to bring Compiz into a state where it can be considered truly stable. We need to stop using Compiz master as an experiment. Examples of this is XCB and objectifying Core and Plugins prior to the object framework being ready. That's if we ignore the branches. I've been very passive since the merge, as I was quite outspoken in my objections, however, it's time we actually talk about Compiz, Compiz Fusion and project management. I am ready to do the boring development work, but not until these management issues have been sorted out. - Kristian
signature.asc
Description: Digital signature
_______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
