First of all, I would like to apologize if I am wrong, as I am not normally involved in compiler development/maintenance, especially with a compiler like fpc, which has to perform truly “incredible” tasks (platform, CPU, etc.).
Yes, and that leads to sheer scale, and it is a nearly 100% volunteer effort. (which results in an inability to direct much centrally)
Compared to other projects I have participated in, the number of open tickets would “overwhelm” me. Especially since the tickets affect many different developers, which always raises the questions: “How serious is the problem?”, “Does it affect me?”, “Should/must I take care of it?”
The current bugtracker is a step back from the mantis that we had, certainly. E.g. it seems to be not possible to store some filter as default. Also the policy to leave far out feature requests lingering forever is IMHO not healthy.
In addition, ticket management is also deceptive. Although the problems are recorded in tickets for processing, in reality they are lying somewhere in a basement, and the motto is “out of sight, out of mind” – to put it bluntly.
One suggestion for the topics discussed earlier would be to make these tickets “visible.” FPC already has a functioning and configurable test system. There should be at least one test case for each ticket (associated with the ticket number). These tests should not be blockers under any circumstances. But test runs of these tests would show which problems still exist or which problems have been resolved “by chance” (by fixing other problems).
For that they first need to triaged, narrowed down etc. If you have a good test for it, it might already be pretty close to resolving. I don't think this will change anything. The principle is already there, but the practice is simply more complex.
The respective tickets can be “marked” accordingly, which would be necessary for a ‘stable’ version. And as soon as all currently (!) affected tickets are resolved, a new “stable” version can be defined.
If you have hypothetical perfect test coverage. But the problem is getting to the hypothetical stage.
In practice if you tag a branch/revision for release (and basically freeze it for deeper compiler work), it will take up to six months of wide usage to get a somewhat complete overview of how usable it is.
FPC is currently still trying to maintain semantic versioning, but as we can see, this is not working. In reality, semantic versioning no longer exists in FPC in my opinion, but they are sticking to this concept.
I don't understand this at all. Yes, many agile organisations move on from semantic versioning to a quarterly or semi annual scheme, but they are usually not 100% volunteer driven. It would be pointless.
Even if some FPC users would like old compiler versions to receive bug fixes for a certain period of time, I believe that this is unrealistic for a project like FPC.
The FPC developers should be realistic enough to face this fact, act/change accordingly, and communicate this appropriately.
The stable versions typically have a few compiler bugs fixes (more in the x.y.2, less in the x.y.4), and the rest are mostly library fixes that are mostly compiler independent, and thus merged. At least in the old situation with a release every 18 months meant that at least that part was somewhat continuously released.
Recent
