Am 24.05.2017 um 08:57 schrieb Graeme Geldenhuys: > > Once again, read how the Git project deals with it. That workflow could suite > FPC quite well.
You never developed a real world compiler and you have no real insight into fpc development so you cannot know about this. > In > summary, feature are in separate branch. There is a public "testing stablish > changes" and a public > "testing unstable" branches. Everything stays in branches until they are > signed off and merged into > "master" (aka Trunk). Then less than 5 minutes is spend doing a "octopus > merge" of all branches that > have been well tested and signed. Who tests and signs? Our testing facilities cannot test more than a few (1, 2 maybe 3) branches nightly as we use build farms used also by other people. Further we test also on slow system, where one run takes >1h. We have already >150 regression test runs per night with different parameters, on difference architectures etc. This cannot be extended. Everything not in trunk (or master/) fixes is not seriously tested and cannot seriously be tested, due to lacking resources. So feature branches make only sense for big changes (as we do already with svn). Or tests the "crowd" which makes OSS so powerful and everything is reviewed by dozens of people? Looking at the problems FPC 3.0.2 has, people even didn't test release candidates seriously. And some branch for a single feature? May I laugh? _______________________________________________ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
