2012/3/27 Peter Gavin <[email protected]> > Hello, > > So after some discussion with a few developers, I feel that its time > that any issues the group has concerning the development repository > need to be resolved, especially since I'm doing a lot of work > coalescing a lot of contributions, and there seems to be some concern > from some members with respect to the current SVN setup. I'm > currently using git for my work, and I'm currently working on two > trees: > > or1k-src: I started this tree by cvs checkout'ing the sourceware.org > src tree (see http://sourceware.org/cgi-bin/cvsweb.cgi/?cvsroot=src), > and doing cvs updates in one branch, while keeping my work in another > branch. The CVS subdirectories are also watched by git. Whenever I do > a cvs update, I rebase my work tree on top of it so my work can always > be made into a diff against the upstream tree. So far, I've completed > the binutils port to use cgen, and I'm currently working on getting > gdb to use cgen (I'd say the gdb part is halfway done). > > or1k-gcc: This is a clone of the gcc read-only git tree. The gcc > read-only git tree is a git-svn clone of the main gcc svn repo. I > periodically rebase my work on top of the upstream, again to make > diffs easier. I started off this tree by cloning Giuseppe's gcc tree. > > So, as I've mentioned, I prefer git, but I understand some devs and > many users prefer svn. Git has the advantage of making tracking an > upstream tree simple (via rebasing), while svn AFAIK does not. > However, git does have decent svn interoperability, so that gives us a > couple of options: > > 1. The central repo can still be svn, and users/devs wishing to use > git can use git-svn to pull/push changes. > > 2. (My preference.) The central repo can use git, and a read-only svn > mirror can be provided by using a cron job to push changes from the > git repo into the svn repo. This keeps it simple for users who don't > care about making changes and are accustomed to SVN, but still want to > keep the most recent version of everything. Devs would be best off > changing to git. I think this would be the best way to handle the > or1k-src repo (which tracks a CVS upstream), because trying to make 3 > different VC tools work together will be a nightmare. > > More complicated things can be done, too: > http://kris.me.uk/2010/10/01/svn-master-with-git-mirrors.html > > There's also subgit which can be used to keep a git repo and svn repo > continuously synced with each other, but it's not OSS. > > Whatever choice is made, I feel we should start fresh. I have a few > reasons to think so, but the primary one is that the current structure > of the SVN repo with everything under trunk/ isn't very good. > > By the way, can we please keep this discussion tame and free from > accusations and flames? My intent is not to start a flame war with all > this. :) > > -Pete > _______________________________________________ > OpenRISC mailing list > [email protected] > http://lists.openrisc.net/listinfo/openrisc >
Hi Peter, I think it's good that someone who who has contributed a lot lately and who isn't as tainted by the last year's discussions gives some input. 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 :)) 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) 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. 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 also hope that I haven't ignited any flames Best Regards, 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
