Sure, that works fine. The reason I was suggesting a shift to a distributed system (Savannah supports at least Bazaar, Mercurial and Git, as far as I know) was that the local-vs-official repository can be handled more smoothly that way.
However, I do not want to be "that guy". You know, the guy who keeps advocating his favourite version control system. I personally have absolutely no problem with any VCS, as long as the workflow can be smooth. :-) Regards, Elias On 13 April 2014 23:46, Juergen Sauermann <juergen.sauerm...@t-online.de>wrote: > Hi, > > my concern is not the ultimate responsibility because if we get more and > more sub-projects then > I would NOT like to be responsible for the merges. I would prefer if the > responsibilities are agreed > beforehand and then every contributor would have, say, her subdirectory > and with it also the > responsibility in terms of maintenance and documentation for that > subdirectory. > > As a GNU maintainer I would also think that the sources should be hosted > by the GNU project in the > first place, and that the GNU policies should be followed. I would also > like to mention that so far > GNU savannah worked very well for me and that the guys behind it are very > responsive when it > comes to problems. And many current GNU APL users follow the main GNU APL > SVN - why should we > change that? > > That does not prevent a local repository for development. I have my own > local SVN (the 6000+ numbers > on the GNU APL welcome screen are my local SVN numbers). A commit to the > remote GNU APL SVN > repository is only made after a local build, debian packaging, and RPM > packaging has succeeded (see > make EXPO on top-level), I believe we should do something similar for the > sub-projects. > > /// Jürgen > > > > On 04/13/2014 04:56 PM, Elias Mårtenson wrote: > > Another option would be to use a distributed VC like Mercurial or Git. > Then you'd still be ultimately responsible for all merges into mainline, > with contributors being able to work on off-site branches. > > Regards, > Elias > On 13 Apr 2014 22:52, "Juergen Sauermann" <juergen.sauerm...@t-online.de> > wrote: > >> Hi Elias, >> >> yes, you have a point there. My first guess would be GNU savannah where >> GNU APL lives. We would have to figure a few things like how to change >> SVN permissions, >> paperwork for contributors (as per >> http://www.gnu.org/prep/maintain/maintain.html) and so >> on, but that is doable. >> >> Another point is packaging and testing if all works together. Normally I >> test the core GNU APL automatically >> before committing into the SVN at savannah. Something similar should >> happen for those sub-projects that we >> see as essential; we can be a bit more relaxed for demo projects. >> >> /// Jürgen >> >> >> On 04/13/2014 03:55 PM, Elias Mårtenson wrote: >> >> There are now a few separate side-projects that all depend on and >> integrate with GNU APL: >> >> - Emacs mode >> - Thomas' javascript port >> - SQL API >> - Possible Android port? >> >> These ports are spread over different source repositories (I'm not even >> sure where I can find the javascript port) it's getting a bit messy, and I >> can only imagine the pain if Jürgen decides to actually integrate this port >> into the mainline. >> >> As for myself, keeping my github-based repository in sync with the >> mainline is manageable, but not as smooth as it could be. >> >> Because of this, would it make sense to migrate the repository to a >> distributed system? I personally don't care which one, but being able to >> work with the same repository as Jürgen would be very nice. >> >> Regards, >> Elias >> >> >> >
