[Compcomm] Forum Decision

[Danny Baumann]

Hi,

> I am pretty sure that you won't be able to stop the packagers from
> packaging what they can get ;) ... 

Hehe, indeed :-)
But I'm pretty sure those people will also be very fast adapting their
packages to a new name.

> The problem I see is that everything
> in the git repo is named something with "compcomm" - all that stuff
> needs to be changed later and it could have been avoided by simply not
> using compcomm in every folder/file-name and comment. However - I
> appreciate the work of all people involved in setting up the
> developer-infrastructure.

If I didn't understand Guillaume completely wrong, choosing a new name
only names some folder renamings (read: some 'mv' calls), so I don't see
a big deal there.

> > As for the git repo, it's fairly easy to use from a developer point of
> > view. There are a lot of repositories, but users aren't expected to
> > use them directly; developers are.
> With mess I mean that there are personal repos, plugin-repos, app-repos
> and more mixed up in one folder. Maybe I am a little bit pedantic when
> it comes to sane folder organization (I'd propose to at least put the
> personal repos in a subdir).

They are ;-)
The top level directories are compcomm/, compiz/ (the readonly compiz
mirror used for commit mails), inactive/ (old stuff) and users/
(personal repos). Please have a second look ;-)
But I agree that a sane layout is important.

> > I don't really mean to be offensive, but the fact is that the beryl
> > team has done and continues to do far more code-related work than the
> > compiz team (minus david) ever has. This will obviously have an effect
> > on the result, but I wouldn't consider it an alternative to just not
> > do anything.
> I think you underestimate what Mike and I silently did in private
> because we have no shared repo (and are only two people anyway). 
> 
> We (maybe Mike more than me) are heavily working on the python-plugin
> and I think we have at least 10-15 example plugins ready. The
> python-plugins can do virtually anything the C-plugins can and they are
> NOT noticably slower. The loader only works with the git-version so
> there is no stable release yet, otherwise we would have setup a git-repo
> for it ...

We all appreciate your hard work there, but it's hard to see the effort
needed for it if you do all work silently. Why on earth do you not use
one of the two publically available repos? If you really do not like
using git.opencompositing.org (getting commit access to it is a matter
of sending your SSH pubkey to Guillaume and time of way less than a day)
although e.g. Cedric already joined us there, please use at least
git.compiz.org. 
And wanting to set up a git repo _after_ release doesn't really make
sense to me - noone can reproduce how it evolved and what's maybe left.
This does not only apply to the python plugins and the loader, but also
to all the other plugins of Mike - maybe some of us would already have
fixed those for latest git in this case ;-)

> > If you're unable to code, I suggest participating in the new forum,
> > and using the "compcomm" code and making constructive comments on what
> > you are seeing. So far, I've seen very little of that, and it is a
> > good way to influence how the end result will be, specially at a time
> > like this.
> The problem is that we (i.e. the compiz-community devs) generally had
> plans about the settings-system and how to handle the lack of
> settings-tools. The beryl-devs have their own idea of that. I accept
> that we have diverging ideas but both sides are way too stubborn to come
> to an agreement. This leads to the situation that I either drop my work
> and use the (formerly) beryl-code or silently continue with what I did
> before (which leads to more confusion and duplication). I don't know
> what's best in that case ...

In that particular case, there is no former Beryl code ;-)
All the stuff dealing with settings has been thrown away and rewritten
from scratch, with only the idea of a C library + bindings remaining
what we still think is a good idea.
But: CCS is already feature complete and already completely using the
metadata system, with only some bugs (e.g. in the gconf backend)
remaining - libcompizutil is still at the beginning. Why don't you
concentrate on working on the settings manager(s) instead? I mean, you
can of course work on everything you like, but from my point of view it
would be way more effective if you worked on the settings manager
implementation as we still are lacking a decent one. CCSM (in
users/quinn/ccsm) is coming along nicely, but helping hands are still
needed there :-) - on the other hand, a (maintained and current)
simplified settings manager for CCS is still missing.

> I get the point and you are right in some way. But I'd like to see that
> things are discussed first and then implemented well (that doesn't
> really apply to smaller bugfixes or additions) - not implemented and
> re-implemented and re-implemented until they work ...
> 
> I don't want to tell anyone what to do, I sometimes just want to stop
> people from making wrong decisions.

We all are not safe from wrong decisions ;-)

> > We simply don't know the answer to all your question(s), because there
> > isn't an easy one. We'll have to figure it out together, and you're
> > one of the persons I hope will be able to help.
> I never wanted something else, but sometimes someone has to take on the role of 
> the "bad boy". 
> 
> I think if we two finally can talk in peace (which we actually seem to
> do) then everything is possible ;) ...

Amen :-)

Regards,

Danny