2012/2/29 Jonas Bonn <[email protected]>: > > On Wed, 2012-02-29 at 08:47 +0000, Jeremy Bennett wrote: >> 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. > > That was years ago... cans of worms are meant for opening. Old > arguments don't necessarily apply anymore. > >> 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. > > Mainline publish git repositories, no mirroring skills required... > >> >> 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. > > Two years ago... and since then? And yes, 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. >> > > Why do you refuse to push upstream when it's tested and working? Now > we're two years behind again and essentially back to square one in terms > of needing to catch up. > > /Jonas > > _______________________________________________ > OpenRISC mailing list > [email protected] > http://lists.openrisc.net/listinfo/openrisc
I agree with Jeremy that changing the upstream repository would create much problems and very little gain. There is already a confusion about which repositories to use for some of the things, and this can be clearly seen on both the support forums and on IRC. Regarding Peter's contribution, I'm all for giving him write access, and would suggest we use a branch for this until we are confident enough to put it into mainline. The current tools have had a lot of testing hours, and even though the new tools seem to work fine, I wouldn't recommend anyone running production code to use a toolchain that has been tested for a week or two -- 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
