Discussion:
unknown
1970-01-01 00:00:00 UTC
Permalink
Are you going to keep them in sync?
On a best effort basis. The idea here is more to make a stand, and
that voices in the community has asked for it. It was also evident
that this is needed, a lot of data from OpenCores SVN is not
accessible, either due to configuration errors (timeouts) or plain
data corruption (CRC errors). With this effort at least we have a
backup.
Did you ask the project managers of
those 800+ cores if they thought this was a good idea.
I think you know the answer to that question. Obviously I did not, and
as free software tends to be "the one with community support survives"
I'm not troubled by this. Time will tell if this was a good move.
I know many of
them are dead projects (as are many on GitHub, and on SourceForge), but
there are also some that are not, even if they are not projects you use.
I count on that. My some-what educated guess is that the clear
majority are dead or very seldom updated.
In this case it allows the community to actually patch the projects on
FreeCores through pull requests on github - instead of staching
.patch-files somewhere like orpsoc-cores does today for example.
What about the discussion forums (including the non-OpenRISC ones). Are
you migrating those as well? That is often where the beginners first
come in.
I have no objection on leaving this on OpenCores. I'm not asking about
a blind abandonment, just moving whatever is critical and making the
initial user experience better.
I don't want to submit a pull request that relies on someone else to
decide. I want a wiki which I can edit. If you don't like the current
wiki, just edit it.
I was a bit non-clear here. The goal with the website repository is
not to replace the Wiki, but replace the current http://openrisc.net
and gather information that is stable enough on a more friendly,
structured and reviewed site.
The wiki serves a purpose (scratchpad for ORconf, writedown of a
tutorial) which I only think another Wiki would solve, so for now I
don't propose replacing it.
In essence, I want to move http://opencores.org/or1k/Main_Page,
http://opencores.org/or1k/OR1K:Community_Portal and a few other pages
to a more stable format, while having links to the Wiki for other more
"exotic" stuff like workshop results / orconf things.
We have now just given up.
I generally propose just doing it if talking fails. I don't think
people care, they just want a simple interface.
I can easily see this becoming a *third* mailing list.
The only thread that was not sent to both lists during 2014 was
'deprecated compiler name?'. Probably because OpenRISC is one of the
few projects that has two mailing lists, and that is confusing.
Shutting down one mailing list and making it bounce with a message
telling to use the other will work just fine.
Don't underestimate the work required for a community of this size. Just
looking at the OpenCores OpenRISC mailing list since last October, there
have been around 450 posts, with 42 different contributors, most of whom
are multiple contributors. At the same time there have been 220 forum
posts, from another set of contributors.
I don't see how this is a problem. I've requested an extraction of the
mailing list member list, if I get an answer for that - I'll simply
add them to the other mailing list. That happens all the time, at
least in my experience.
The big problem here is that OpenCores admins are unresponsive, which
I address last in this email - and ironically is one of the reasons
why I want to move critical stuff off the platform.
It seems that we currently have OpenRISC hosted on GitHub, which gives
the version control the community desires. Do we really need to split
everything else off and do it for every project. GitHub for hosting
repos is good.
This is a big point, but as I see it we've already done this. All the
major engineering doesn't go through OpenCores.
Its website/wiki stuff is so-so.
Agreed, it is however free, community trusted and very robust.
A stable website like what I'm proposing would survive hosting moves,
if the current Wiki dies we only have the occasional backup.
Its issue tracking is a nightmare for any project with more than 100 lines of code.
Agreed. But I cannot say that Bugzilla is any better. In this case the
issues are at least categorized into the component that is relevant
(which admittedly can be a problem).
We're already using github issues for some stuff, so it's more going
with the path of least resistance here.
And is this really what you want to do? Surely your interest is in
engineering.
Clearly you underestimate my passion for tidyness :-).
This endeavor is fueled by the same energy that I use for upstreaming.
I guess having been through this twice before, I really don't want to
face the pain. Could I suggest you at least hold fire until ORConf when
you can talk to all the main OpenRISC contributors.
With all due respect, no. I don't think having IRL meetings will solve
this. IRL meetings have the added overhead that everybody that took
his/her time to come there has the psychological pressure to add
his/her opinion to shape the decision and might not have the full
picture. The awesomeness of open source and the Internet is that it
should be preferred to make decisions online, and respond quickly to
winds turning.
That gives time to discuss what the solution to the obsessive desire of
OpenRISC to implode on a regular basis is. I am not convinced that
another individual splitting off a fork is going to be any happier
experience than the last two efforts.
To be clear: I'm not proposing moving much. I'm proposing de-coupling,
removing dependency on OpenCores. As I already said I don't see any
point in removing the Wiki for now, the forums will stay, and the
development workflows we have today are unchanged.
With this I'm trying to set a standard for the project to not use
whatever is best for whatever we're trying to do. Sadly, OpenCores
fails for that when it comes to source code and information portals.
It may be time to go down the route I have long advocated, which is a
proper community organization, not controlled by any one individual.
Given ORSoC AB have changed their CEO in the last year or so, you might
even find they would back this now. The advantage of a properly
constituted community organization is that you are much more likely to
persuade corporate sponsors to support you.
The OpenRISC organisation is "owned" by a couple of active
maintainers. I think that's the best solution. Having a real corporate
entity "own" stuff just makes it harder. It might be useful if it
comes to actually seek funding, but I would vote for always have the
control in the community, never a formal organisation in a single
country. That is however I think a separate topic.

Now for ORSoC.
Is this still the name of the company? orsoc.se just redirects to
kncminer.com. All older orsoc.se links I find are gone, including
documentation that was once available. Any attempt I've made to
contact the maintainers of OpenCores (which I assume is ORSoC) has
remain unanswered. Someone is probably still moderating the forum, but
that's as far as it goes for life signs. I feel very uneasy about
this.

For what it's worth, I've been contacted by numerous people off-list
that think this is a great idea but asked to be anonymous.

I appreciate your input as always Jeremy, and you have much more
experience with the community in these matters - but I think the
current approach is trying too hard to please everyone and ends up
going nowhere.

Regards,
Christian

Loading...