 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Gilles Tran" <tra### [at] inapg fr> wrote in message
news:457da098$1@news.povray.org...
> news: 457d907f@news.povray.org...
>
>> Ben suggested the following categories as a starting point for a 'type'
>> based categorisation:
>> - Textures
>
> (These threads are long so please ignore the following if already
> discussed)
>
> IMHO it should be possible to add resource materials that are not made of
> POV-Ray SDL.
>
I don't think this has been specifically discussed yet, but it's not
necessarily a problem with the solution that has been discussed. So long as
the files are prefixed with the appropriate contribution ID, then I don't
see a problem with having any variety of files and file types as you need to
make a contribution work. The application code on the server managing the
download would create an archive incorporating the entire contribution.
> Bitmaps textures (simple or HDRI) are the more obvious case - bitmaps are
> often part of packaged scenes or objects -, but other stuff could go there
> too, including non-SDL models (think Wings or Blender models), packaged
> tutorials, BVH files, little software utilities etc. I realise that this
> opens another can of worms, but this is done in other 3D communities, and
> lots of people have non-SDL material to offer.
>
One of the things that was discussed was also the possibility of
incorporating more sophisticated contributions which I've suggested could
enable the contents of the archive to evade some of the file naming
conventions. I'm a bit biased on this as I would like to contribute a
complex set of files which incorporates a variety of BVH files, converter
utilities, model sources and sets of pose files, clothing files etc. and I'd
prefer not to have to rename them all.
> The fact that non-SDL goodies could be used by users of other software may
> be a good thing (more public exposure for POV-Ray and its community) or
> not (extra server load, more potential license troubles since non-SDL
> goodies are likely to have a higher commercial value than SDL ones).
>
> G.
>
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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. There would be no
> visible hard-wired hierarchy of directories within these areas, but there
> would be (potentially multiple) logical categorisations available alongside
> indexing information (Keywords) supplied by the contributor. One form of
> categorisation could potentially cover topics like 'Space Hardware' and
> 'Landscapes' whereas an alternative form of categorisation could cover
> contribution types, such as 'Component', 'Finished Object', 'Texture',
> 'Utility Macro' etc.
>
> The povray.org server may use an internal directory structure to manage
> versioning or other aspects of the collection, but this structure would not
> be visible to users and would not be present on the user's local machine
> once the files have been downloaded.
>
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.
If we want to allow non-similar licensed files in the library, then the
traffic light indicator you mentioned could be useful. Stop for
privately licensed, read the files carefully. Slow/caution for standard
license but not prefixed or checked, and go for checked over and should
work with the current version of POV-Ray.
> Submitting Contributions
> ------------------------
> Contribution Name - To submit a contribution through the povray.org web
> site, you would first enter a name or a unique ID for your contribution.
> Povray.org would search its index for that identifier.
> If it's a new submission and the name is already being used, you will need
> to pick a different one.
> 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.
The solutions I could come up with follow:
1)Server allows uploading over established files. I could see this being
really bad, but it would solve this single issue.
2)Allow only the contributor to over write their file, and make sure
that all patches are sent to them. This could pose a problem if the
contributor doesn't want to update or just can't be found.
3)Only designated people can overwrite files. There could be many ways
of determining this. Only head folks in the Library Team, a specific
patch manager, everyone with a patch that has been downloaded 100 times.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
457dc4d2$1@news.povray.org...
> I don't think this has been specifically discussed yet, but it's not
> necessarily a problem with the solution that has been discussed.
Thanks for the answer. I just wanted to make sure that the option was
mentioned somewhere. Note that the license should also cover these kinds of
materials (not just SDL).
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It all looks good so far, of course I only gave it a quick read :)
There are two things I'd like to further suggest, however:
1) All contributions should be required to submit to a particular
(non-exclusive) license, similar to what the IRTC does. Ie, "I agree to
the standard license, and allow anyone with access to this repository to
use my contribution for any purpose whatsoever, including making changes
and submitting patches to the repository." Or something like that. The
point is, if I access something from the repository, I don't want to
have to read over the license for it to determine whether or not I
should use it.
2) In the vein of "value-added features", I'd recommend allowing users
to rate the individual files according to several criteria, such as
Completeness, Usability, Realism, Uniqueness, etc (those are just
examples), as well as add comments / reviews about them. If a
submission has multiple versions, allow the viewing of aggregate reviews
(for all versions combined), or for a single version.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
First, thanks for all your thought & effort Chris. Supposing this thing
gets off the ground it'll be in no small part thanks your efforts in
getting everybody together in discussing it.
"Chris B" <c_b### [at] btconnectcomnospam> wrote:
> foresee a smaller number of the larger packages, so it might be possible for
> those to be expanded into separate directories on the user's machine without
> hitting the 20 library path limit mentioned in the help (Charles indicated
> 25, is this OS dependant?). This could maybe permit naming conventions
If I'm not mistaken I'm reading this as a standard limit for all platforms:
http://www.povray.org/documentation/view/3.6.1/56/
Where did you find 20?
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Charles C" <nomail@nomail> wrote in message
news:web.457e46ca6bf4081b9926319c0@news.povray.org...
> First, thanks for all your thought & effort Chris. Supposing this thing
> gets off the ground it'll be in no small part thanks your efforts in
> getting everybody together in discussing it.
>
> "Chris B" <c_b### [at] btconnectcomnospam> wrote:
>> foresee a smaller number of the larger packages, so it might be possible
>> for
>> those to be expanded into separate directories on the user's machine
>> without
>> hitting the 20 library path limit mentioned in the help (Charles
>> indicated
>> 25, is this OS dependant?). This could maybe permit naming conventions
>
> If I'm not mistaken I'm reading this as a standard limit for all
> platforms:
>
> http://www.povray.org/documentation/view/3.6.1/56/
>
> Where did you find 20?
>
> Charles
>
Hmm. I see.
I was looking at 2.1.2.5.4 Library Paths where it says "Up to twenty unique
paths may be specified".
http://www.povray.org/documentation/view/3.6.1/220/
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ben Chambers" <ben### [at] pacificwebguycom> wrote in message
news:457e3915$1@news.povray.org...
> It all looks good so far, of course I only gave it a quick read :)
>
> There are two things I'd like to further suggest, however:
>
> 1) All contributions should be required to submit to a particular
> (non-exclusive) license, similar to what the IRTC does. Ie, "I agree to
> the standard license, and allow anyone with access to this repository to
> use my contribution for any purpose whatsoever, including making changes
> and submitting patches to the repository." Or something like that. The
> point is, if I access something from the repository, I don't want to have
> to read over the license for it to determine whether or not I should use
> it.
>
Sabrina made the same point. I can see both sides. One aspect of it that I
don't think was yet discussed is that if someone creates something based on
another Open Source license, then they may not be able to comply with our
license terms without breaking the terms of that other license. I guess the
answer is that they can still publish on their own web site and add a link
into the povray links collection or promote it on these newsgroups.
Two ways forward on this question spring to mind. We could have a vote on it
or we could start by requiring a common license and ease up if it seems to
be causing a problem.
> 2) In the vein of "value-added features", I'd recommend allowing users to
> rate the individual files according to several criteria, such as
> Completeness, Usability, Realism, Uniqueness, etc (those are just
> examples), as well as add comments / reviews about them. If a submission
> has multiple versions, allow the viewing of aggregate reviews (for all
> versions combined), or for a single version.
>
> ...Chambers
I like this idea.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
