On Tue, Apr 3, 2012 at 8:55 AM, Jeremy Bennett <[email protected]> wrote: > On Tue, 2012-03-27 at 21:44 +0200, Peter Gavin wrote: >> 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. > > Hi Pete, > > Thanks for this post - it is a well thought out analysis of the > situation. I'm surprised there have not been more comments. > > Thank you also for the work you are doing. I look forward to trying out > your tool chain when it is complete. > > I know it is less convenient for you, but for the reasons outlined by > Olof in his email (I'll reply to that as well), I strongly recommend > option 1. > > In addition, while at present you are the only active developer, over > the years there have been quite a number of others. They contribute from > time-to-time as their time permits. Making your change would require > them all to change to a git-based flow, and I would be reluctant to add > that burden to them. > > For binutils/newlib/gdb there is a particular issue that upstream is a > centralised system (CVS). We hold it in a related, but different > centralised system (SVN). To then add a third decentralised system (git) > seems a potential source of chaos. The opportunity for little details > like file modes or line endings to get messed up is immense. We do have > open source developers who work in Windows environments, and some parts > of the GCC test suite do rely on enforcing particular file formats to > allow OS specific testing.
Hi Jeremy, I'd like to chime in here and say I disagree with forcing everyone on the OpenRISC project to have to commit to, and ultimately, deal with SVN in their development flow, whether they do their day-to-day development in git or not. I think each component's master copy should be kept in a VCS of the lead maintainer's choosing. As simple as that. I'd even go as far as to (controversially) say they should be free to host it wherever they like! However, we should insist on a mirror of releases on OpenCores if they choose not to host it there, and a big note on the wiki indicating where people's development area is. So basically, I'm in favour of the decentralisation of the location of the code that is actively developed (because I don't believe you can't say to people "if you want to contribute to OpenRISC you _must_ have your active development branch on OpenCores' servers") but centralisation of the releases and information and discussion (wiki, mailing lists and IRC.) You're far more likely to get people off the ground with the project sooner if they can run with a VCS they know, and thus more likely to see more of the top work that we've seen from all the contributors over the past year. It shouldn't really turn any potential developer/contributor off as releases and the dev branches should be mirrored via other popular VCSes, and it'll be the lead maintainer's role to commit most patches as they come in via the mailing list and they'll be familiar with the master/development copy's VCS as they've chosen it. I think the only issue here is that it's not clear who can make the call in the case of the OpenRISC GNU tool chain as it contains many components and involves you, me, now Pete Gavin and likely others. In the case of everything else, though, it's pretty clear who is calling the shots and I think they should be able to migrate to a different VCS if they so choose, but ensure an SVN mirror is made available for those who want to continue doing an "svn up". One thing I really think needs to happen is the splitting up of the OpenRISC project's repository. As we know, it heaves along; I don't even think we should be getting it all in one SVN checkout. We should have a repository per component (so one each for or1k binutils, gcc, gdb, newlib) and the same goes for our other in-house things like or_debug_proxy (although I'd like to see this deprecated for OpenOCD... but that's for another thread), the OR1200 RTL, ORPSoC and the various RTOS ports we have. Keeping it under one roof was OK when we had a smaller development team but I honestly think we need separate repos to keep it manageable and agile so there is relatively little fuss for new OpenRISC ports of OSes or tools or whatever to be added on. I'm also not certain SVN is the VCS of choice of OpenCores users these days, but if it seems important to make everything available by SVN then I say we set up read-only mirrors of any component where the development occurs in a git repo. > > We should be making more use of git on OpenCores (it has git facilities, > but no one uses them). In particular that is the correct place to hold > Linux, uClibc and BusyBox, since they are git upstream. > I think the sentiment is good, but really, anyone who wants to go and get a git repo isn't going to try and figure out how to sort out one at OpenCores (there are no instructions on the wiki atm) - they will follow the nice and easy instructions on github.com or have Jonas offer them one via IRC for openrisc.net. It could be useful to host the development branch of things close to home, but I'd say it's probably more useful to provide git mirrors of things. In summary, all I am in favour of doing is whatever maximises productivity of the project. I think forcing people to negotiate with that SVN repo as it is now is not in line with this. I reckon we maximise the ability of people to develop in whatever VCS they like and leave it up to the component maintainer to apply patches via the mailing list as they come in. However, we must provide a good website via the wiki on OpenCores to make clear how to get the releases of things, and where to look to get down and dirty with the active development branches. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
