On Sun, Apr 8, 2012 at 12:40 PM, Jeremy Bennett <[email protected]> wrote: > On Sun, 2012-04-08 at 07:53 +0100, Julius Baxter wrote: > > <snip> > > Hi Julius, > > Lots of good comments form you - my thoughts below. > >> 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'm not arguing for that. I was making the case for not using a > distributed VCS when the upstream is not distributed.
OK, I misunderstood what you were saying. Yes, the question of whether it's a good decision to change what we host our port of something in if it's different to how it is upstream is a tricky one. But I really don't see the problem with git here. It can be straight forward enough if you need it to be. > >> 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! > > Well that is not unreasonable. I think for most cases it is > uncontroversial where there is a clear single maintainer. Agreed, single maintainer components shouldn't be a big deal here. > >> 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. > > Agree, mirroring is essential. We want a one-stop shop for the OpenCores > projects. > >> 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. > > I guess I see cans of worms here. It gets hard developing a system if > contributors have to register on a host of separate services to > contribute. I think there is a very strong case for it being possible to > always commit via OpenCores.org. I don't understand why a contributor must register on a host of separate services. I'm assuming the vast majority of commits will be done by the maintainer from patches via the mailing list, meaning people's interface with the master OpenRISC port of a component is via the mailing list, not via the VCS server it's hosted in. I think the post-your-patch-to-the-mailing-list-for-discussion-and-eventual-commit-by-the-maintainer is a very good model and then any decisions about adding commit rights for a repository should be made by the maintainer and I'm not sure a policy of "all components should have a committable branch on OpenCores.org" is a useful policy under what I propose. > >> 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. > > That's fine while we have a single lead maintainer. But it isn't > scalable, and it causes real headaches when the lead maintainer changes. > Actually we're seeing that here, because others, with a background in > git are now taking the lead where I (with more of a SVN/VCS background) > have taken the lead in the past. Great that others are taking over, but > we don't want VCS chaos each time that change happens. It shouldn't cause headaches - you take a checkout (with history) of the old repo and and check it in elsewhere, and you update the wiki page to point to the latest development branch and you continue your work. The next release to be mirrored on OpenCores also follows along just like it did. > >> 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". > > I wasn't particularly arguing for SVN mirrors everywhere, although it is > convenient for hardware engineers, to most of whom even SVN is a radical > innovation. For Linux and uClibc a git mirror is more important. > > But you are correct about GNU being the real problem. > >> 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. > > There is a good case for separate repositories for separate projects, > but that won't make much operational difference, since OpenRISC is so > dominant at OpenCores. It also makes sense to split out the hardware > repository. > > However it doesn't make sense to split out individual tools in the tool > chain. Even the FSF doesn't do that with the GNU tool chain. All except > GCC are a single tree in a single CVS repository (the "sourcware" tree) > and then GCC has its own SVN repository. But we aren't trying to > maintain 40 different architectures, so we can use one not two > repositories. And having done that, then there is little point in > keeping small stuff (Or1ksim, debug proxies) in their own little SVN > repository. OK, the GNU components should probably live in one separate repository, but we need to make sure that what we get is only the stuff we will build now, not the 8GB of various copies of old ports. Although, won't we still need to download all of the previous versions because we can potentially roll back to them anyway? > > Linux, uClibc should be in git, not SVN. > >> 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. > > That is a convenience, particularly for hardware engineers, but not one > I was particularly arguing for. I'd rather make sure git was readily > available on opencores.org. I don't know why hardware engineers get such a bad reputation for ability to learn and use VCS!? I admit we're not as steeped in software development flows (although EDA flows are looking more like them except for a lot more of that vile tcl stuff) but it's becoming more common, although I admit we're far more likely to be working in a big, centralised project codebase and flow rather than taking our little chunk and working in our own world until it comes time to combine it all in. But I don't think it'd be too much to get people using git for various bits of the OpenRISC project. I understand the new ORPSoC is looking at using git. > >> > 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. > > Jonas does a great job, but if he is run over by a bus (OK no bus would > dare to), we lose the lot. > > It took us a while to get SVN set up on OpenCores (not always the > fastest moving organization). I was proposing taking the first steps on > that for git. > > Actually since then, I have thought it might be best to move Or1ksim > first. It is small and doesn't have an upstream to worry about. It would > be a good thing to pilot. Part of the pilot is to get the processes in > place to make setting up git repos easy. > > Marcus/Olof - can you help with this. > >> 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. > > I haven't had the same problems as you with SVN - not since Olof fixed > the problems last year. But we could do with better documentation. And > we do need to move all the legacy GNU stuff into its own directory! I dread going into my openrisc/trunkcheckout directory and running an "svn up" because it sits there and checks through the 4 billion files under gnu-src and then all of the new RTOS stuff. Perhaps I could have separate checkouts of those directories as I need them, but it'd be even better if we could make the checkouts as lightweight as possible, even at the risk of excess fragmentation. Good discussion, thanks. Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
