[Bf-committers] CVS rights, owners & roles (was Re: CVS commit: blender/release/scripts kmz_ImportWithMesh.py)

[Ton Roosendaal]

Hi JMS,

Of course we can ensure that the header of a file correctly mentions  
your orginal authorship and the changes as added by Campbell.

However, I don't think this is the real issue. There's also a personal  
friction involved... and we can only solve that by making as clear as  
possible agreements in advance. Agreements to define what happens with  
code, and what roles are for people.

For Blender's C code we have loosely organized this, relatively  
informal, but still an important role definition:

-> "module owners" are developers with cvs commit right, who can commit  
in code without the prerequisite to get permission of other developers.  
We expect owners to to do this with common sense of course, like  
respecting release status, scheduled projects, discussing changes with  
team members, and so on.

When issues cannot be solved in consensis, there's the bf-blender  
project administrators who can decide (Willian, Matt, Martin, and me).  
And as bf-blender project lead, I reserve the right to make final  
decisions as well.

Since the Python project is very big, with many developers, there's an  
own mailing list and own internal organization. According to my last  
information (not sure if that was formalized), the current leads and  
"owners" for bf-python are Willian, Campbell and Tom M.

What the bf-python team could do is to formalize what happens with  
external scripts that get included in the default source tree and  
releases. The problem is that such scripts can be well maintained, but  
without the author having cvs write access for it. In that case, an  
author should respect that the responsible project owners then make  
changes in the code.

A possible solution could be to open up a new Bundled Scripts project  
(own cvs, mailing lists, tracker), and give authors of bundled or to-be  
bundled scripts cvs access and thus "ownership" of the scripts. Whether  
or not these scripts get included, and in which shape, then still is a  
discussion... and who will manage this project? Nice discussion for on  
the bf-python list I guess. :)

Further I would advise the python team to respect an author's desire to  
not change his scripts, especially if you want an author to maintain  
the script still. JMS can clearly state this as a condition for making  
his scripts available.
If a script isn't good enough, and an author refuses to change it, then  
just not include it?

Hope these considerations help a bit.

-Ton-



On 3 Feb, 2007, at 10:28, jmsoler at free.fr wrote:

> Selon Tom M <letterrip at gmail.com>:
>
>> JMS,
>>
>> Martin is correct regarding the GPL - once something is release under
>> that license as long as the distributor distributes changes under the
>> GPL the original author doesn't get any say regarding what changes
>> they might make.
>>
>
> Sorry but that is wrong. If you made modifications in the original work
> you  must clearly indicated that the file you distribute is not the  
> original
> one. From the GPL text:
> """
> In french :
> Si le logiciel est modifié par quelqu'un d'autre puis transmis à des  
> tiers,
> nous voulons que les destinataires soient mis au courant que ce qu'ils  
> ont
> reçu n'est pas le logiciel d'origine, de sorte que tout problème  
> introduit
> par d'autres ne puisse entacher la réputation de l'auteur originel.
>
> In english
>  If the software is modified by someone else and passed on, we
> want its recipients to know that what they have is not the original, so
> that any problems introduced by others will not reflect on the original
> authors' reputations.
> """
> Thing I already asked a lot of times. Currently the copy in the CVS
> does not respect this article. All modifs made by Cambo and not clearly
> incicated in every scripts of the the bundle scripts also infringe this
> part of the General Public Licence .
>
>> that said, I don't think that changes to an authors script that is
>> being actively maintained should be made without the authors
>> permission unless there is very good reason.  Thus cambo, it would be
>> appreciated if you would revert your changes to the script for now,
>> since a modest performance gain isn't really worth going against the
>> authors wishes.
>>
>
> My only wishes is that you respect the GPL text and that the functions  
> in my
> script would not be damaged.
>
>> JMS if you would be willing to make the changes if there are in fact
>> performance gains I'd be willing to do a benchmarking comparison - If
>> someone could point out some test files - are you and cambo both using
>> 2.4 or 2.5 for the testing?  Ie you might see different performance if
>> you are using different versions of python for the testing and thus
>> you could 'both be right' regarding performance.
>>
>
> I only use the blender's dll python joined to the Blender archive,  
> nothing
> else. The tests were made  under xppro with a very fast p4 intel proc  
> and
> under win98 with a not so fast AMD proc. Every test made on huge  
> kml/kmz
> models shows that the results was or the same or slower on the modified
> script.
>
> I did not refuse to make changes that speed up the scrip and I lost a  
> lot of
> time to do that but, really, I do not notice any difference with my  
> original
> one. However, a lot of these changes are in my new script to satisfy  
> the wills
> of the python team.
>
> So, please, update the CVS with the current version of the script, the  
> 019g:
> http://jmsoler.free.fr/util/blenderfile/py/kmz_ImportWithMesh_Z019g.py
>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org