Hi, On Thu, 25 May 2017, Sven Barth via fpc-other wrote:
> nevertheless Charlie's mail was too interesting and constructive not > to respond to it :) Awww, you, stop it... *blushes* :D > 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. :) 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... > 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. Indeed. I think we already have an informal list of "Tier 1" systems anyway, which is more or less Windows, Linux-i386/x86_64 and Darwin. I think (almost?) everyone uses these as development hosts, even if he works on some other system in the end. But breakages in these affect quasi everyone immediately. The rest is "irrelevant". (Disclaimer: I mostly work on other systems, so I can claim this. ;)) > 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 that this could be solved with some engineering if enough > willpower and time (and insight into FPC's development process) is > available. Indeed. Some of these "rules" or process ideas sound like an improvement even if Git is not in the picture. :) Charlie _______________________________________________ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
