2012/11/12 Jonas Bonn <[email protected]>: > On Mon, 2012-11-12 at 06:06 +0200, Stefan Kristiansson wrote: >> On Sun, Nov 11, 2012 at 10:16:25PM +0100, Franck Jullien wrote: >> > As I told you when we met, the tiny SPI core is a good example. >> > This core as a driver in the Linux mainline (spi-oc-tiny.c). However, >> > on the opencores website, it doesn't have a OCCP stamp. This >> > should not be possible....Plus, the official maintainer should be >> > opencores because the core has to remain very stable. Any change >> > in the core should be acked by opencores gurus and checked against >> > the linux driver. >> > >> >> Although I agree with most of the other things you brought up, >> this example is good. >> Who are those opencores gurus that should maintain it? >> I for ones have never used that core and probably never will, >> so I don't really care much about it. >> It happens to have a driver in Linux mainline since the >> creator of the core submitted a driver that he had written. > > As I recall it, the Linux driver was submitted by one of the NIOS folks > and wasn't the author/maintainer of core himself. > > In my opinion, OC would better serve as a ward of _quality_ > specifications than as another sourceforge/github. As long as there's a > single, complete, and correct spec hosted by a reputable central > organization, then it subsequently matters little how many > implementations of the core/driver there are, where they are, or who > maintains them. The spec's, today, I find a bit too "unfinished"... and > perhaps a bit too fluid; if there's anything a "guru" should be watching > for it's incompatible changes to the specification. >
I used the wrong term when said "guru". Should have said opencores community. That's why we sould have an opencores mailing list and changes be submitted to the list for review. > I worry a bit that the 'compatible' tag on the Linux drivers is so > tightly coupled to implementation today, whereas as it really should > just be coupled to the OC specification revision and, thus, be _mostly_ > implementation independent. > > So my suggestion would be: > > i) make spec management central and do quality control of this > ii) when searching for a project, it leads you to the spec and, > secondarily, points you to a list of available implementations (and > available drivers, if applicable) > iii) "certified" stamps on the site go on the implementations, not the > project as a whole... > That's indeed a very good idea. It would solve a lot a problem. >> If that guy isn't actively maintaining that project anymore, >> and you want to step up and give it some love, that's great. >> If he's not interested in being the maintainer anymore, >> then he'll probably gracefully handover the maintainership >> to you, just like it would happen in any other open source project. > > Just fork the project and do a better job maintaining it than the > original guy and it's yours... if you cannot reach the original > maintainer anyway, then this isn't even considered unethical. But, as > always, be careful what you wish for...! > > /Jonas > _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
