2017-05-25 15:20 GMT+02:00 Karoly Balogh (Charlie/SGR) <char...@scenergy.dfmk.hu>: >> Of course the biggest obstacle is the building and running of the >> testsuite. > > Well. Build breakages are daily occurence with obvious "this could have > never built" mistakes, or new packages get committed which don't build for > any platform, etc. Even large patches, with little care and "worksforme" > excuse. So even in the current system we run the testsuite *AFTER* the > commits are already made. And lot of the experimental development happens > in directly trunk. So this reaction of "omg, what happens to the testsuite > runs" I feel a bit... Yes. :)
I'm aware that the current situation isn't all roses and such (see the typo you fixed a few days ago: that was me removing a "virtual" without its semicolon directly before the commit even though I had already successfully built the compiler previously). So if we had an automated process to catch such things at least on the Tier 1 systems you mentioned below that would go a long way already I'd say and - as you wrote as well - completely independant of SVN or Git. > And I'm guilty as well, make no mistake. :) But actually this leads us to > another problem, that now all commits are equal, even if someone touches > an uncritical/new package or some x86 codegenerator or a critical part of > the RTL. If the later breaks, could cause problems for everyone years down > the line, while a package will almost certainly only affect some people. > Which means different developers work in the same repo with different > quality/criticality standards... Maybe such a hypothesized integration system would be a bit more rigorous depending on what files were changed? E.g. full build with fullcycle plus testsuite run on Tier 1 targets if anything in compiler and rtl was changed and only a full build if merely something in packages was touched. >> 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 > > Indeed. > > To be honest, I don't see a lot of difference to a Pull request or a diff > submitted via Mantis. A core developer has to handle both, and sign it > off. From then on it's his responsibility to handle the patch during its > lifetime, and revert or fix it, if breaks the build and next days' > testsuite runs. It's actually pretty much irrelevant if the change got > into trunk via a manual diff/patch/commit, or someone integrated a pull > request. What I meant is some automatic process, which makes sure you have > a linear history suitable for an SVN upstream commit, etc. I agree. Maybe we could try at least part of it: Step 1: have an official FPC trunk Git mirror on our own server with a mirror/fork of it on GitHub (were those license troubles regarding GPL and Co I mentioned some months ago solved, btw?) and accept Pull Requests on the GitHub mirror (those would of course need to be processed by core devs willing to use Git :P ) Step 2: adjust the Git repo on our own server so that it can react to Pull Requests from authorized developers (aka us Core devs) as well and have it do the integration stuff (which of course would require writing or finding such a system which would be a whole topic in and on itself) all the while the development process can continue with SVN as well (without the integration shenigans) Of course Step 1 would require us to do a conversion from SVN to Git of at least trunk and to make sure that all revisions that need to be there are indeed there (e.g. if Graeme's statement is true that Git ignores commits that only have property changes). This is of course a rather simplified view of all this and many problems along the way would need to be solved. Regards, Sven _______________________________________________ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
