"Sabrina Kilian" <ykg### [at] vtedu> wrote in message 
news:457dd079@news.povray.org...
> Two quick issues to pick apart. I just got done with exams so I haven't
> had enough time to go through everything yet.
>
> Chris B wrote:
>> Organisation
>> -------------
>> The site would be split into two main parts with (1) an 'ad-hoc' area for
>> new submissions and (2) a 'standard' area where contributions adhere to
>> certain standards and to a common licensing structure.
>
> Even the ad-hoc should have to be under a compatible license. If it is
> not licensed for redistribution, then someone could complain that the
> server was giving it away with permission. That may sound strange, but
> it would be safer if we knew we had permission to redistribute the
> files. Secondly, it allows others to patch a file to make it standards
> compliant.
>

I think I missed a bit out in my summary. I think the idea proposed by Chris 
Cason was that the contributor would still need a fairly liberal license, 
but they may elect to require 'Attribution', so his suggestion was that they 
would be required to include something like the following trap in their SDL 
to prevent people from using their contribution unwittingly.

 #ifndef (Attributed_Includes_OK)
    #error "This include file requires attribution"
  #end

I'm fairly impartial on this because I can see that it might help encourage 
more contributions, but I think it does add a layer of complexity and I'm 
pretty confident that a lot of people will be happy to contribute without 
requiring attribution, just as a sort of give-back gesture.

>> Submitting Contributions
>> ------------------------
>> If you intend to supersede an existing contribution you will need confirm
>> that and will need to 'version' your contribution - See 'Provenance' 
>> below.
>
> Just for everyone to think about, who's name should go on a file that
> was patched? If I fix a bug, or typo or what ever, in someone elses
> library, the most I'm going to do is add a comment saying I fixed
> something and why, and add one to the patch version level. If the server
> is appending a prefix based on the uploader's name, then we could end up
> with two files doing the exact same thing.
>

I would suggest that we don't routinely delete any version although there 
may be special circumstances where an administrator would go in and make 
deletions (e.g. if one or more contributions is intentionally corrupted or 
if older versions are not downloaded for a year or so and no other 
contributions depend on them).

I see the versioning as being largely internal to the server, so that you 
only get one entry for a contribution coming up on a search, but when you 
look at the entry you can see that multiple versions have existed and can 
select the one you want. Normally you'd go for the latest. I think the files 
you download would not be prefixed with a version number or contributor ID, 
because this would interfere with anything you've written to use them. There 
could be an auto-generated 'version' file containing the version number in 
the name - e.g. 'TennisBall_SK_V2.3.ver' that contains information about the 
provenance of this version.

If you fix a bug, you would upload a new version of the whole contribution 
having tested it as a complete unit. You wouldn't change the name of the 
original author as registered on the server if it's just a little fix, but 
would merely add a comment to say what you'd done. This contribution would 
have your initials or tag against it in the versioning information and 
people would be able to select either your newer version or the original 
version if they prefer. Dependencies in other contributions may still need 
to point to the older version of this contribution.

If the original author subsequently applies the same fix to the same bug, 
then yes, you end up with two virtually identical files on the server, but 
hopefully the comments will cast some light on that.

Regards,
Chris B.

Post a reply to this message