[Compcomm] Forum Decision

[Mike Dransfield]

Danny Baumann wrote:
> 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. 
>   

You must stop sounding like a cult.  'Cedric has already joined us' can 
sound
scary ;)

> 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 ;-)
>   

I set up a git repo ages ago but its only on my local hard drive, I dont
see any real pressing reason to put it in a public repo yet, but I am sure
I will one day.

For people interested I have just uploaded the recent version here

http://www.anykeysoftware.co.uk/compiz/plugins/python.tar.gz

I have included a log in that tarball so you can see all commits.

For people who want to contribute or branch it then there is an
up to date git archive here.

http://www.anykeysoftware.co.uk/compiz/plugins/python-git.tar.gz

I do not want the extra support hassle of people checking out
broken commits so I like to test things for a few days and then
release a tarball which I know will be good.  The releases are every
few days (sometimes more than once a day) and I normally bump
the python thread when I have done anything major.


>   
>>> 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
>
> _______________________________________________
> CompComm mailing list
> CompComm at Rock3d.org
> http://www.ubaight.com/mailman/listinfo/compcomm
>