On Tue, 2012-03-27 at 23:27 +0200, Olof Kindgren wrote: <snip>
> I also hope we all can agree on some basic details. > 1. We shouldn't make it harder than necessary to contribute to the > project. If this is ignored, we might lose the interest of the > developers. This is basically what happened when a few developers > copied the code base last year and started other openrisc-related > repositories. > 2. We shouldn't confuse the users by moving around the master > repository. If this ignored, we might lose the interest of the users. > I still see people on the forums who try to do CVS checkouts based on > old documents that turn up in google searches. History and habit are > hard to get rid of. > > For the openrisc tree I see that you have identified two problems. > 1. It is too large > 2. It uses a VCS that doesn't fit everyone's needs. > > For the first problem, I would suggest that we put some efforts into > moving the outdated parts out of the main tree, and come up with > better branching strategies. There is an ongoing effort for this > already. Linux can be fetched from kernel.org nowadays. The next > generation of ORPSoC will be hosted in a separate repository. > or_debug_proxy and orpmon will be replaced by openocd and u-boot, also > from their separate locations. Hopefully, one day the toolchains will > be accepted upstream (but that's not the situation right now, I > know :)) One obvious problem is that we have one directory, gnu-src, with all versions of the tool chain, past and present. 8GB to check out. For Pete's work, I have already created a new tree gnu-dev, in which there is or1k-gcc and or1k-src to track the upstream GCC and SourceWare SVN/CVS heads. We should split gnu-src into gnu-stable and gnu-legacy. I suggest retaining gnu-src with a README explaining the change. As you have noted, with a huge user base, it takes a long time for changes to permeate everywhere. If there is no objection, I shall go ahead and make this change. > The second problem probably need more attention. From what I have > seen, the workflow works nicely for individual patches. (to remind > everyone, all patches for common components currently has to go > through the mailing list and be acked by someone other than the > contributor who has write-access) Agreed - this works. Worth clarifying that this is for trunk and release branches. Users working on new stuff on other branches don't need approval until they want to merge into trunk or release. > There is a difference however for large infrastructural changes, such > as a new tool chain port, which is the problem at hand. > > For these kinds of work, I absolutely think that the VCS should be the > developer's own choice, so that it doesn't become a burden, but I also > think that there should be a requirement to have peer-approval before > the master repository is updated, whatever VCS is used. Basically all > projects require the approval of some core developer(s) before > important changes are checked in, but everyone is free to keep their > development trees in whatever format they prefer. As an example, Linux > uses git and newlib uses CVS, but the mailing list is still where the > decisions are made and where people send their patches. Most, if not > all, VCS have some feature to create diffs from their original copy, > which can be used to give others a chance to comment on changes. I'm not sure a new tool chain port is any different - at least not when it is an update of existing work like the GNU tool chain. This mechanism only matters if you want to change something radically. Like switching version control system. As you noted, the switch to SVN 2 or 3 years ago caused immense disruption and anger, and we still see the ramifications today. > With all this said, I think that we could start using git trees at > opencores for the parts that already use git for their developments, > but still use the current tree as the master copy. I'm a bit worried > that automated imports (as the cron job suggestion) would lose the > peer consensus, and make the tree move too quickly. Since this is a > hw/sw cooperation, there's a lot of things to consider, and I would > not like us to have a reputation of being too carefree with the > architecture. I fully agree. It makes no sense to hold Linux, BusyBox or uClibc in SVN. These are central to the OpenRISC project, but they are not even held on OpenCores any more. That has to be wrong. You are right that managing git projects is a challenge. The distributed nature that makes git so powerful is also what makes it so hard to manage. It is worth noting that Linux works because it is controlled centrally by one guy (Linux Torvalds) with immense authority. We don't have anything like that in OpenCores. I suggest that for each Git component (e.g. uClibc) we need a master branch that is mirrored and updated automatically from upstream, an OpenRisc "mainline" branch from the master which is the main development branch, a series of release branches from that "mainline", and then as many other branches for development projects as people wish to create. Commits to the "mainline" or release branches would need to follow the existing mailing list approval mechanism. If this is to work, it needs an OpenCores employee (you?) to organize it. Automatic updating requires a cron job to run git fetch periodically. It also needs git write access granted to people as necessary. Longer term the standard git approach of allowing universal write access won't scale. OpenCores will need to use something like gitosis to manage large numbers of users and provide some access control. I suggest we start with something that is reasonably stable, uClibc. If you are willing to set this up (the master mirror and write permissions to the relevant people) on OpenCores, I am quite happy to add the OpenRISC specific mainline branch and a user guide section to the Wiki. > I also hope that I haven't ignited any flames A measured post. Looks like fire extinguishers won't be needed. Jeremy -- Tel: +44 (1590) 610184 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: [email protected] Web: www.embecosm.com _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
