[PD-dev] cvs admin question ...

Hans-Christoph Steiner hans at eds.org
Wed Mar 2 18:54:28 CET 2005


Well, the last thing that I wanted to do was start a flame war...  my  
only point is that the CVS is a group environment, and we need to  
respect and communicate with each other.  It sounds like Thomas Musil  
is going to maintain iemlib in the SourceForge CVS, that is great, that  
makes me happy and its less work for me.  The problem is that there was  
zero communication about the change with pd-dev or me, who imported  
those sources.

Now that this is clear, I think there is no problem changing the CVS  
ACLs.  I just committed the change.  A little bit of communication  
beforehand would have saved us this storm of email.  Communication is  
key to making collaboration work.

I would like to add my two bits about working in CVS. I think locking  
everyone out of iemlib is bad idea if that code is indeed going to be  
maintained in the SourceForge CVS.  The code that does have access  
restrictions has them because that code is just imported from somewhere  
else, so directly modifying the code in the SourceForge CVS doesn't  
make sense.

But if iemlib commit access is not restricted, then people can fix  
minor bugs, typos, etc. without a whole patch process, and therefore  
will be much more likely to do so.  For example, I probably wouldn't  
bother to make a patch to fix a typo, but I would make the change and  
commit it, if I could.  _All_ changes in CVS are easily tracked, easily  
reversible and announced to the pd-cvs list, so recovering from  
disasterous commits is quite easy.

And lastly, I must say, being an admin means that you need to take the  
extra effort to communicate, especially when editing CVSROOT files,  
which affect everyone.  Personally, this episode makes me a bit  
concerned that Tim is a bit too quick to act without considering the  
repercussions, so I would rather wait a bit before granting him full  
access.  That's just my two bits, it is, of course, a community  
decision.

.hc


On Mar 2, 2005, at 8:01 AM, Winfried Ritsch wrote:

> Hello,
>
>>>>
>>>> I think there is no reason for thomas to fear (man cvs). The CVS is  
>>>> a
>>>
>>> i do not know a way to explain fear.
>>> but i don't think "man cvs" will help. (nor does "man freedom")
>>>
>>>> place for collaboration, not a marketplace for externals. If Thomas
>>>
>>> aren't there projects there that are already read-only for other  
>>> devs ?
>>> why ?
>>> what makes tom schouten's approach better (sorry ts that i keep  
>>> abusing
>>> your way of usage: no criticism intended): overwriting any changes  
>>> made
>>> to the CVS via a daily cron-job ?
>>
>> I think there is nothing better with tom shouten's approach.
>> It is a great achievment having Thomas' code directly in CVS,
>> but the way it is done could have been better.
>>
>> Anyhow, who cares,
>>
> we care ;-)))
>
> Anyway, there was a solution that there is a main branch in PD, where  
> miller
> checks in his version and there is a dev tree as a branch. So Thomas  
> thinks
> the same modell is good for his iemlib.
>
> I think its good to have iemlib not just as a forgotten copy in cvs  
> but the
> main branch lively patched and growing. And anybody can make branches  
> and
> they can be merged in, if it makes sense. If there is another main  
> developer
> of iemlib he also get the rights for the main branch. I always thought  
> that
> is the way it works on sourceforge. I dont think it makes sense we set  
> up a
> own sourceforge project page since everyone is sharing source here.
>
> mfg winfried ritsch
>
> PS: Beside I suspect OpenSource is already a marketing modell and  
> sourceforge
> is a marketingplace for that.
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev
>

________________________________________________________________________ 
____

                     There is no way to peace, peace is the way.
										-A.J. Muste





More information about the Pd-dev mailing list