2017-05-24 14:12 GMT+02:00 Karoly Balogh (Charlie/SGR) <char...@scenergy.dfmk.hu>: > > Hi, > > On Wed, 24 May 2017, Graeme Geldenhuys wrote: > > > If the Free Pascal team is ever serious about migrating to Git, I'll > > happily help out with the migration process. > > Well, I think the resistance is too big for the migration. The SVN people > go full berserk bloodbath mode when Git is mentioned, and Git people > usually go "whatever" and just use git-svn. :)
Disclaimer for the remainder of the mail: I've seen Florian's mail that he currently sees no need to move FPC development to Git, nevertheless Charlie's mail was too interesting and constructive not to respond to it :) > But. If we could come up with a way, which allows accepting pull requests > with Git somehow (thinking about Github, specifically, but in general), > then have them seamlessly integrated into upstream SVN as they're > accepted, that would maybe move things forward. (Remember, we even have an > FPC organization on Github, which we can utilize.) The integration of Pull Requests into upstream SVN would indeed need to be automated as much as possible (I see where Marco is coming from). In essence those people that currently are allowed to commit to SVN trunk would be allowed to send a Pull Request to the integration system (which would automatically do the merge, build and run the testsuite and commit it to master if successful). If an external developer would want to see something committed she'd need to send a Pull Request to one of the Core developers or there would be some general catch all mechanism in place and some Core developer could just pick up any pending external Pull Requests and sent it on to the integration system if deemed worthy of inclusion. Of course the biggest obstacle is the building and running of the testsuite. As Florian wrote in one of his other mails we're partially/primarily relying on build farms that are shared with other users and on some systems the testsuite run takes long (e.g. on my PowerBook it takes around an hour). So maybe the Pull Requests for the integration system could be designed in such a way that only a subset of the supported targets can be requested for build and testsuite runs or maybe only a fullcycle is done together with a full build of only one target all depending on whatever the Pull Request specifies. There would of course be the possibility that this would break some target that isn't in the test subset, but let's be honest: that currently happens as well :P > With the more automated verifications regarding the integrity of the SVN > the better. But Marco was right on the point, that this needs a very very > carefully designed plan and process, to not screw up the upstream SVN. > Maybe what LLVM and GCC has in place can serve as a starting point. Qt for example has a similar process (even though they don't have a SVN master repository anymore like LLVM and GCC do), see here: http://wiki.qt.io/Qt_Contribution_Guidelines > And to be honest, I wouldn't even have the full SVN mirror "published" in > Git, only trunk, and branches fixes_3_0 and newer, with the later being > read only, as merges would happen by the maintainer, in SVN. > > So yeah, TL;DR: instead of trying to fix people we could use engineering > to make the technology just serve us all. :) I agree that this could be solved with some engineering if enough willpower and time (and insight into FPC's development process) is available. Regards, Sven _______________________________________________ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
