2012/4/9 Julius Baxter <[email protected]> > On Mon, Apr 9, 2012 at 12:02 PM, R. Diez <[email protected]> > wrote: > > Hi all: > > > > I think OpenCores' strategy about OpenRISC is clear: they want full > control > > of what people download and install, and of all user and developer > > communications too. As recently discussed, this goes as far as forcing > the > > usage of their e-mail lists upon developers if necessary. I heard they > tried > > to trademark the term 'OpenRISC' in the past, but I'm not certain about > this > > point. They will only make concessions, like removing the registration > wall > > from one source repository, when forced by external threats. Given that a > > private company is behind the site, this is not surprising. > > Hi Ruben > > I think you're conflating two issues here. Regarding controlling of > communications - I don't see how that can happen considering most of > the development goes on a mailing list and the wiki is free for all > maintainers of the project to edit, but, as you have mentioned > previously, some elements of OpenCores are certainly used for > marketing the products and services of the owners - but this is not > exactly "full control ... of the user and developer communications" - > although it's not perfect, either. Regarding the downloads, AFAICT > it's the development community is who put things up for download and > who put together the things to be installed. I would think anything > that isn't done right is due to ineptitude (say, the precompiled tool > chain stuff, which is my fault for having to install it to a > particular location - I don't know how to ready things for proper > distribution via a package management system.) But I agree, it does > suck that there's things like the registration wall, and it's been > made perfectly clear to the guys at OpenCores that this is something > which turns people off. > > > > > I must admit that OpenCores has't been that bad in the past. However, I > > still believe that it's worth opposing that underlying strategy, for the > > good of the OpenRISC project, which is currently rather stagnated in my > > opinion. This could end up like OpenOffice and LibreOffice, or hopefully > > more like the Linux kernel model. >
> To be honest Ruben I think you're overstating the importance of > getting OpenCores to fix their ways, as far as the OpenRISC project is > concerned. I think the existence of openrisc.net is a perfect example > of what can be contributed to the project outside of the realm of > OpenCores. The most important thing is that we remain a unified force > behind OpenRISC development, and not get too bogged down in worrying > about how much marketing ORSoC jam onto OpenCores. > > Regarding the stagnation of the project - I disagree. It depends on > which part of the project you're referring too, but in almost all > areas we're progressing OK. Your work has been great, so too the > recent stuff by Pete Gavin on the tool chain, Olof has got ORPSoCv3 up > and running, there's been new RTOS ports, U-boot has gone upstream and > we're getting more interest than ever from the wider embedded systems > and open source community. For sure there's things we're not doing > right and things we're falling behind on, but this is largely due to a > lack of hours in the day for some of the core maintainers, and the > lack of maintainers as well. Like most open source projects, though, > this is largely a do-ocracy - you can gain control and influence over > a part of the project by actually getting involved and getting things > done. You may wonder, then, why the desire to keep OpenCores in the > picture, and the reasons are that it is really the largest open source > digital design IP site on the Internet, and there are parts of it > which work perfectly fine at the moment and there's not too many good > reasons to move away from using them (the wiki, the SVN repository - > although messy, can be neatened and mirrors of important things > added.) AFAICT we, as OpenRISC project maintainers, have free reign on > the wiki and SVN repositories there (for this project in particular) > and can do what we think is best for the project and I've not seen any > significant political interference here. > > It makes me a bit sad to hear from someone that the project has stagnated, when it really has been a very successful year. I'm not sure we ever have had this many contributors and users. > > > The MinSoC project has come up with a good solution: Raul Fajardo has a > > script that automatically downloads and installs the necessary components > > from different places, by cherry-picking the versions that work well > > together. > > > > Mirroring source code repositories to a centralised repository means > effort > > and gives up control, so I think that such an automated script is the > way to > > go. > > > What do you mean? Which approach are you critiquing here? The one > where we mirror all the distributed works on a server on OpenCores? > > This is basically what I have done for ORPSoCv3 in order to merge the best parts of ORPSoCv2 and MinSoC. You can take a look at the outline of the project here http://opencores.org/or1k/ORPSoCv3 and some code examples here http://git.opencores.org/?a=summary&p=orpsoc This allows IP cores to be collected from any site, using any version control system. -- Olof Kindgren ______________________________________________ ORSoC Website: www.orsoc.se Email: [email protected] ______________________________________________ FPGA, ASIC, DSP - embedded SoC design
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
