[compiz] [FusionDev] [ANNOUNCE] Compiz feature branch compiz++
Sam Spilsbury
smspillaz at gmail.com
Fri Dec 26 06:51:56 PST 2008
On Thu, Dec 25, 2008 at 2:34 PM, CyberOrg <jigish.gohil at gmail.com> wrote:
> On Thu, Dec 25, 2008 at 6:35 AM, Kristian Lyngstol
> <kristian at bohemians.org> wrote:
>
>> I'm really alarmed with how this branch/project evolved, so I'm sceptical.
>> Essentially 6 months of development has been poured into a project we're
>> not supposed to talk about that changes more or less everything that is
>> compiz, and there's been no open discussion along the way. This has been an
>> ongoing problem with Compiz for as long as I've been involved, and it has,
>> in fact, been the single biggest challenge in working with Compiz. I regret
>> to see that you are carrying this tradition on Dennis...
>>
>
> I agree here, putting massive amount of work without involving
> everyone is sure way of losing existing developers and not attracting
> any new developers to the project. I appreciate what is done here by
> putting a concrete proposal with proof of concept code, but if few
> more developers are not involved during the core design it would turn
> up same as compiz core, most people including many plugin devs have no
> idea how it works.
>
> I will also echo concern of maintainability, DavidR has fallen off the
> map and has not worked on compiz head for a very long time,
> effectively retiring from compiz development and responsibilities of
> fixing existing bugs. There is object framework branch that has not
> seen much activity either. Hope compiz++ don't end up like that. This
> would be second time we have something stable/usable we would go back
> to 0.1, effectively keeping compiz in alpha.
>
> Apart from these issues, if compiz++ is going to make compiz better
> quickly and attract more devs to work on core, makes it easy for
> plugin devs to maintain their code, I am all for it.
>
> Ciao
>
> Jigish
Hi,
I can tell you that I've worked on 'secret projects' before (MPXIR)
and it never really worked out, mainly because no-one saw the code and
by the time critique was made, it was really too late to change the
code without breaking everything else. I do think that all the
developers need to be more open, however in Dennis' defense, I would
say that it is much easier to at least get the 'core' of your project
done before it is made open, otherwise you'd have comments flying back
forth and center.
Also, with the issue of openness, I do think that the developers need
to make an effort to check other news channels too and not just expect
all news to come down one channel (blogs, mail, forums etc). In a
perfect world, all three of those would be used at the same time, but
nobody is perfect of course. I check planet and the forums once every
few days, it's really not that hard.
I think that one of the main issues that might be faced with Dennis'
rework is the issue of C++ vs, C. A commenter on my blog (I think it
was Erkin) pointed out some interesting arguments as to why C++ would
work better with compiz, he also gave two links [1] [2]. The reception
of having a C++ based core against a C one has actually been
surprisingly good amongst most of the fusion and core devs I've talked
to, so this may turn out to be a non-issue.
I think one of the main issues we need to consider is what Cyberorg
pointed out. With such a rework, we essentially have to put c-f into
an alpha stage for a while, meaning that the 0.9.x release series is
going to be quite painful for git users. It also means that we have to
have another significant break in the plugin ABI and we may very well
see the same 0.6.x and 0.7.x branch series all over again. Problem is,
do we want to make compiz++ (and compiz-fusion++) our 1.0 release or
not? I say we merge this in after 0.8, considering that two problems
could occur if we don't make this our 0.9.x release series: 1) The
branch will stagnate and become out-of-date 2) We would hopefully want
1.x to be a stable plugin ABI and breaking the plugin ABI after 1.x
really does not sound like a good idea.
That's my 2c anyways.
- Sam
[1] http://www.eventhelix.com/realtimemantra/basics/ComparingCPPAndCPerformance.htm
[2] http://unthought.net/c++/c_vs_c++.html
> _______________________________________________
> Dev mailing list
> Dev at lists.compiz-fusion.org
> http://lists.compiz-fusion.org/mailman/listinfo/dev
>
--
Sam Spilsbury
More information about the compiz
mailing list