On Wed, 2012-02-29 at 09:01 +0100, Jonas Bonn wrote: > On Tue, 2012-02-28 at 18:14 +0000, Jeremy Bennett wrote: > > The master repository is on SVN at openCores.org, so we should get your > > code into there. To date we have mirrored specific FSF releases of each > > tool, but if you are tracking mainline, we should create src-mainline > > and gcc-mainline trees. The build script will then be rather simpler, > > and merging upstream changes must easier. > > > > I'd like to propose that Pete is given SVN write access (has to be > > approved through this mailing list). > > Given that the last five people to work on toolchain bits have all > worked out of the git repositories, I'd like to propose that we ditch > the SVN repository altogether. I'd even go so far as propose that > Pete's repository become the master, if he's willing to take on the task > of merging patches from the rest of us... that's not a lot of work given > the low level of activity on this front. > > If somebody wants to mirror that into SVN, that's their prerogative... > but I don't think we should be punishing people who do good work by > forcing them to bend over backwards to push well-formed patches into the > SVN cesspool.
We have had this discussion in the past, and agreed that we would use SVN where the upstream uses SVN or CVS and git where the upstream uses git. Promoting multiple master repositories for the same tool fragments the project, making it hard for anyone to adopt and should be discouraged by *all* the OpenCores community. Don't forget that with a large user base, OpenCores generates a lot of support email. After a decade of working on the project, my name is in a lot of code, so a lot of that support comes as personal email to me. The commonest problem is people using some out-of-date mirror of the code. Sticking to the one true repository solves this. That is why I have proposed Pete should have SVN write access to commit his code. Since he is mirroring mainline, he is familiar with SVN and CVS anyway. The current tool chain went through extensive testing to ensure it is robust. I am delighted that someone is taking that work forward, and congratulations to Pete for his contribution. But we need to follow our agreed engineering process, ensure the new code is tested to the same standards as the old, reviewing on these mailing lists. It will initially be the development version of the tool chain, and then later will become the stable version. This way, anyone coming new to OpenCores can be confident that they will find good quality software. At the same time, Pete's work will be visible to the widest possible community, and in a way that ensures it gets the best possible support. Pete - could you post the regression results for the new tool chain. If you want help with any particular issues, I suggest posting them here and in Bugzilla, so others can join in. 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
