Guy Hutchison wrote:


But wouldn't it be nice for the developer if s(he) has some more control
about who can access the code?

Like have a possibility that someone has to first send an email to the
developer. I wonder how many people actually violate licenses of cores
and use them in a design without contributing their part of the design
-- provided the core is under such a license -- .

That would allow a developer to have control over what happens to the
code and what comes out of it, rather than have the mailing list
moderator have to do that.

Cheers,

Guenter

Günter Dannoritzer wrote:

That would seem to pretty much defeat the purpose of calling it "Open
Cores". I have tinkered around with a number of the cores out there,
from implementing them in toy designs (I am not a professional VHDL
developer), to just learning how a particular function is done. To have
to email an unresponsive author just to browse the code is not just a
bad idea, it's insane.

--jc
-------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20060415/b87fb62e/attachment.htm

I'll preface this with the statement that I am more of an OpenCores user than I am an OpenCores contributor. I'd be in favor of having moderated lists. There have been entirely too many posts from people who are simply looking for a free ride. Not that this is always a bad thing (OpenCores needs users as well as contributors), but when these folk decide to criticize in a non-constructive fashion, we have a problem. Users of OpenCores need to understand that the core contributors here are not being paid to work on OpenCores (in almost all cases I suspect). On 4/14/06, Guy Hutchison ghutchis at gmail.com> wrote: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20060415/e5b52305/attachment.htm

* G?nter Dannoritzer (dannoritzer at web.de) wrote:

basicaly you get an email about held post, to which you then respond (either
through email or web interface)...

regards,
p.

J.C. Wren wrote:



The question is where you put the emphasis on. Do you focus on the taker
or the giver? OpenCores only works if you have giver, than you can have
taker. I don't think it is insane if the giver has a right to chose.

But let me clarify something. My idea is to have additional features
that allow a developer to chose what happens with its code. This does
not rule out that the developer says everyone can access it as it is
now. Probably most people would do that anyway.

There are cores hosted that other companies charge thousands of dollar
for. Why not give those developers a choice?

I don't think that a community like this can afford to have potential
contributors like Rudi walk away without caring about it.

This email feature was only an idea. I am just trying to think about a
way to encourage more contribution and keep contributors happy. One
would be to give a developer more options to chose from.

What are your ideas about getting more contributors to this community
and how to make them stay?

Cheers,

Guenter

My opinion on this. I also feel a developer should have some amount of control over his sources. Actually, I have myself been wary of posting my projects on opencores for the fear of copyright infringement. I have downloaded sources from opencores but only to enhance my knowledge of VHDL and digital design. I respect peoples intellectual property and refrain from using their sources but I can not speak for other takers. With no system to check a source's use, the chances of exploitation and infringement are more. There are too many e-mails requesting for "free rides" already. What I propose is this : 1) Ability to restrict access to selected files. 2) Implementation of a concrete licensing policy. 3) Verifying and Accepting a designers ownership of a source. For instance, if I write a core for a vocoder, I would like only select files to be available "openly". Like say, an FFT module or a blockram module. The main vocoder module will be available only through a license. If a person wants to see the whole vocoder source, he applies for a license, which is free of course. Now, this licensing should provide some information about the "taker" like if it is meant for commercial use, whether the source is working for a govt agency or at a uni, etc.. If I am not satisfied I can refuse the license. Lastly, when I claim the source is mine, it should be checked with other opencores, and my ownership be accepted only if it does not trespass any copyright limitaions. Once approved, it is placed in the OC repo. If another person builds upon my code or uses a part of my core then I should be referenced for that part of the code, like the BSD license. What do you feel about this. Regads, Abhijit On 4/15/06, Günter Dannoritzer dannoritzer at web.de> wrote:

On 4/14/06, Abhijit Krishna abhijit.krishna at gmail.com> wrote: Quite simply, what problem are you solving? The problem that was raised was, in my mind, that developers will be unwilling to release code for fear of negative communication received on the mailing list. If we restrict access to the cores, then it is true -- no one can see the code, so no one can complain. But then what's the point of the site? The idea of open source is to freely disseminate information. Loading up code downloads with a bunch of restrictions would defeat that idea. The problem you appear to be solving is misuse of code and license violations by people who access the code. I haven't heard that this has been a problem to date. - Guy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20060415/2973a901/attachment.htm

Guy, I am not offering a solution to any problem. All I am presenting is an idea, that allows the developer to control who accesses parts of their codes. Let me clarify, I am NOT for denying access to codes, what I have in mind is a system where a developer can restric access to a PART of his codes and show it to only those individuals he chooses to. These people can be fellow contributors on OC, who could possibly provide more help on the code and less negative communication. People willing to work on verification etc can mail the author, who gives them access to some files. Such restrictions could be applied on 'works in progress' and beta releases. Once a stable copy is complete, the developer releases it to the community, in its entirety. In the end, it is upto the developer on how much access he chooses to provide in the early stages. Regards, Abhijit On 4/15/06, Guy Hutchison ghutchis at gmail.com> wrote:

* Jai Dhar (jai.dhar at gmail.com) wrote:

svn looks very nice, but there is one big problem we would have if we
migrate. (if somebody has a solution, please let me know).

for example in or1k project the following files (in different tools):


or1k/or1ksim/cpu/or32/or32.c
or1k/binutils/binutils-2.16.1/opcodes/or32-opc.c
or1k/gen_or1k_isa/sources/or32.c

(and perhaps some other places i don't remember) should always be in synch
(ie. have identical content). so everytime someone commits changes to any of
these files the changes should automaticaly propagate to all others.

now, with cvs it is easy, these are just hard links. with svn it seams that
something like this is not possible, so a developer would need to always
think to commit in all the different places. if someone has a solution for
this (that would be automaticly) that would really be a big + for svn. there
is a possibility to create a symbolic link, but then you couldn't checkout
just one project (for example or1ksim) but all other depending ones, which
is again a nightmare to remember (there are also other problems with
sym. links)...

the same can be made with whole directories in cvs, so idealy one would
want the same for svn.

best regards,
p.

On Saturday 15 April 2006 02:01, Matjaz Breskvar wrote:
SVN supports versioning symlinks just like files--which you explained you didn't prefer for this scenerio. But, it also supports "externals" which is intended for this kind of thing, and more: http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html> -- Wesley J. Landaker wjl at icecavern.net> wjl at icecavern.net> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20060415/91c34526/attachment.pgp

On Friday 14 April 2006 10:30, Richard Tierney wrote:


I've been using subversion for years, and CVS for many *many* years. Here's
some comments:



Actually, having support for directory moves helps people who do occasional
commits and updates *a lot*. In CVS, if you move files, you either lose all
the history behind them (because you did an delete+add), or you break all
checked out working copies (because you moved a ,v file). In SVN, this
doesn't happen: you just move the file or directory, then when people
update or commit, everything is handled automatically.



There are actually a number of wonderful things you can do with properties,
but let's focus on keyword expansion. You can set up a SVN
with 'auto-props' and it will automatically add your preferred set of
keyword expansion parameters to e.g. VHDL and Verilog files. Also, SVN
handles binary files automatically because of properties. Have you ever
been bitten by forgetting CVS's -kb on a binary file? Not a concern in SVN.



I'm not sure why you think this is bad; this makes working with tags and
branches *so* much easier than it is in CVS.

Also, this isn't really true: you can set up a simple commit hook (an
example is included with the distribution) to prevent modifications to tag
directories, or you can use simple per-directory authorization that is
supported in both servers architectures to stop anyone but users you choose
from making or modifying a tag. Both of these are very simple to do.



No true. svn diff has a --diff-cmd argument, that lets you use an external
diff program, e.g. GNU diff or a graphical diff program. I do this all the
time to get a whitespace-ignoring diff. You can set these up as defaults in
your SVN client, so if it's something you do all the time, you don't have
to type it. =)

I use xemacs almost exclusively as an editor, but I don't use the CVS or SVN
integration, so I can't comment on how good or bad it is.

I believe this is a good thing, it's just not what you're used to from CVS: To quote from: http://svnbook.red-bean.com/nightly/en/svn.forcvs.html> "In CVS, revision numbers are per-file. This is because CVS stores its data in RCS files; each file has a corresponding RCS file in the repository, and the repository is roughly laid out according to the structure of your project tree. In Subversion, the repository looks like a single filesystem. Each commit results in an entirely new filesystem tree; in essence, the repository is an array of trees. Each of these trees is labeled with a single revision number. When someone talks about “revision 54”, they're talking about a particular tree (and indirectly, the way the filesystem looked after the 54th commit)."

They may be features that you don't use or care about, but they aren't just
bells and whistles. SVN was architected specifically to get around
limitations of CVS. This applies to limitations CVS has when used in a
large development environment with many concurrent users. CVS lack of
atomic commits can be a nightmare in some situations.



I've had exactly the oppposite experience.

This is not true, SVN supports locking as of version 1.2 (been out for quite a while). -- Wesley J. Landaker wjl at icecavern.net> wjl at icecavern.net> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20060415/860a894a/attachment.pgp

I have to agree with Wesley's points on Subversion here, I can only add to the section about locking. I understand that we are walking on thin ice with this discussion, and that everyone has their preferred work flow. Concurrent development is not a flaw. Version control tools are not a substitute for communicating with your peers. Locking people out of files on a consistent basis is problematic (I remember the RCS days and I'm not anxious for them again). I've found that locking is rarely "required" and I've worked on fairly large projects with dozens of engineers and programmers poking around in the same code. Only communication can "save" you from the "merge" problem. Locking people out of working on a particular file simply puts the merge burden on the person that commits last. Screw them, they were too slow, right?. Why should I talk to someone else, I've got the file locked?. These are things that I've actually heard form developers. The right answer in this situation is to speak with your team about the changes and to work together to find an agreeable solution. Merge early, merge often. Incremental pain is preferable to finding out that significant effort is going to waste because I or my peers are unwilling/unable to communicate. On 4/15/06, Wesley J. Landaker wjl at icecavern.net> wrote:
--
Wesley J. Landaker wjl at icecavern.net> wjl at icecavern.net> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20060415/40459fcd/attachment.htm

Wesley J. Landaker wrote:




Actually, having support for directory moves helps people who do occasional
commits and updates *a lot*. In CVS, if you move files, you either lose all
the history behind them (because you did an delete+add), or you break all
checked out working copies (because you moved a ,v file). In SVN, this
doesn't happen: you just move the file or directory, then when people
update or commit, everything is handled automatically.

Jeremy Fillingim wrote:


Indeed. :)

I've been having this argument for years. I won't repeat your points,
but, briefly:

1 - Why are commercial tools lock-modify-unlock, rather than
copy-modify-merge? Can you name a proper commercial tool that uses
copy-modify-merge? Why is this?

2 - Imagine you're a project manager with say, 20 developers, each of
greatly differing experience and ability, and each working on 100 source
files. How do you set this up? I'll tell you how I would set it up: each
developer owns their own source files. They're responsible for those
files. The other developers cannot get arbitrary access to those files.
A developer carries out the requried changes to their own files, except
in exceptional circumstances, such as code reviews, holidays, and so on.

3 - the whole concept of merging different changes into a software
source file is just bizarre. The whole file should ideally be about 400
lines long, and certainly no longer than 1000 lines. One person needs to
understand the entire file intimately. How could you, as the project
manager, possibly allow two different developers to simultaneously
modify two different parts (or, in the worst case, the *same* part) of
the same file?

I've worked in one commercial environment where we used CVS. This worked
because we agreed on the rules above, so merging was not an issue. This
is fine, so long as everyone knows their place. I've worked in another
environment with a commercial RCS-based tool (in other words,
lock-modify-unlock). This worked because it couldn't fail. Take your pick.

As I said, I'm talking about real-world commercial development; web
development of free software could be seen as being different.

RT

On Tuesday 18 April 2006 02:32, Richard Tierney wrote:


This is great for me as a developer, and I use it all the time, but what
use is it to an Opencores user? Users aren't going to be allowed to move
files and directories.