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. Regarding how this all might end up - I actually don't mind the status quo. By that I mean that it's not too hard to turn up, figure out who maintains which part of the project (the OpenRISC project has many components, all of which were semi-maintained for many years) and contact them via the mailing list or look on the wiki to find out how to get started or submit work. Whether they want to host things on opencores.org or github or openrisc.net shouldn't matter. What is important, and what exists today, is what I consider to be the "go to" place on the net to find out things about the OpenRISC project, and that (currently) is the OpenCores wiki. In my opinion, beyond that you can chop and change where stuff lives all you want, so long it's locatable from the main information source (the wiki.) I think in your case, as you're doing a lot of useful work in trying to collate various components to automate the build, you're coming across the annoying aspect of this set up (made no easier by OpenCores' SVN server, I admit.) You're also coming across the fact that we haven't been maintaining or organising the stuff all that well in the past, despite efforts by people like Jeremy on the part of the tool chain. So from a technical point of view, I agree it's in a bit of disarray but still works if you know how/where to look. On a political level, though, I don't get too excited by what OpenCores do any more because I think how they decide to run their website isn't critical to the project - I see the community and their efforts as what matters most. OK, it's nice to be organised and have a consistent presence and approach but the fact that OpenCores isn't perfect shouldn't stop us from doing what's interesting, which is hacking on embedded systems RTL, software and tools. Maybe I'm wrong - maybe the site is, in all, detrimental to the project, but even if that's the case there's still plenty of things I'm going to spend my hours on before trying to a) get OpenCores to change their policies and then police them or b) fork the project. > > 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? > > I have written a script along that line for the purposes of a nightly build, > but it can easily be repurposed. It's called orbuild and it's here: > > https://github.com/rdiez/orbuild/tree/master/Scripts/Projects/OpenRISC > > By default the build system downloads several repositories from different > sites, builds and installs them together. All in parallel, only what's > needed, and with an HTML report at the end about which components failed to > build (with separate build logs). Support for Peter Gavin's toolchain is > already there. > > The main advantage with that approach is that it's easy to switch to another > version or fork, you just need to adjust the URL the script is downloading a > component from. An alternative provider (like another web site) can 'git > clone' the orbuild system, change a URL inside it and offer a different > flavour of OpenRISC without the costs of mirroring or forking many > components. > > <dream mode on> > > I would love to see some www.librerisc.org wiki, where everything is public > without a registration wall, where there is a mix of people from several > companies and volunteers, without annoying rules for submitting the very few > patches that come in at all. AFAIK the OpenRISC project's wiki (the current main source of information) isn't behind a registration wall. I wish, too, for greater participation. Regarding rules for submitting patches - I believe it's fair for the maintainers of a component to insist that patches are submitted a certain way, as is fairly standard practice for anyone maintaining an open source project. > > Individual projects would retain their upstream status without a single > entity deciding which one is allowed to be part of "OpenRISC" or not. If an > upstream maintainer no longer has time to properly look after a component, > it could easily be replaced with a fork at the press of a button, without > any wrangling of backstage interests. So too the contents of a wiki can be changed with the press of a button to indicate which is the "upstream" version. Although, good point about who decides which of several could be the "upstream" version - but how often do you think this will happen? At present our tool chain is in multiple states in multiple locations - mostly on openrisc.net but I have repositories on github I'm hacking on too which might be of interest to people. I say it's fair to have a list of repositories for different releases of the tool chains if multiple people are maintaining them. > > <dream mode off> > > An automated download and build script could help realise that goal. It > doesn't have to be me or my script; in fact, I don't have the time myself > for a greater involvement, so other people would need to step in. We used to have such a script but it's really a pain to maintain, and you're not really hitting your target audiences anyway. I think what is better (and is what we do now, although arguably poorly) is provide pre-built binaries for those who don't want to stuff around downloading source and building it, and instructions on the wiki how to do that if they choose. At present the build instructions on the OpenCores wiki or the openrisc.net site are perfect for that (outlining how to source and build a tool chain.) We moved to this set up for two reasons: it's easier on the few of us there are to maintain this stuff and, as mentioned, we're giving the two main audiences (those who just want the stuff pre-built and those who want to develop the tool chain) exactly what they want - not something in between. A nightly build system, however, I think is a great idea and would be something very useful for the project. No doubt that must be an automated script and is far easier to maintain as you're only ever running it on a machine or two and so don't need to cater for every corner case of a user's install and OS. Good discussion point, as usual. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
