Hi Tomas, Thank you for the response.
--- On fixed schedule vs. quality --- I want to clarify what the fixed schedule actually controls in the model: it governs *when the train departs*, not *what boards it*. The Merge Window determines the content of any given release. If a feature is not ready, it simply waits for the next train. The reason I believe a fixed schedule still helps, even if some releases are lighter than others, is that the alternative is demonstrably not working. v3.2.4 has been "almost ready" for two years. Waiting until a release feels "substantial enough" has no natural stopping condition. A fixed departure time does. That said, I think the cadence needs careful thought for a project of FPC's size and contributor base. Looking at the volume of commits, I believe 6-month or even 12-month cycle will be appropriate. No need to chase a release every two weeks like the Linux kernel - though that proves that a mammoth project has the ability to do that, so FPC should in reality be a walk in the park. --- On the MR count vs. commit activity --- You make a fair empirical point, and I genuinely do not know the answer either. It would be worth someone running that comparison before we treat the MR backlog as the primary symptom. What I would say is this: even if the 130+ MRs represent a small fraction of total changes, the fact that contributors have submitted work and received no signal for years has a cost that does not show up in commit counts — it affects contributor retention and community confidence. The triage process in the proposal is not about merging all 130; it is about giving every one of them a clear, timely answer in either direction. --- On the CI automation and cross-building --- This is the strongest point you have raised, and I will be direct: the proposal as written is maybe a bit thin on details here. You are absolutely right that a green CI run on x86_64/Linux is not a meaningful "release is ready" signal for a compiler that targets DOS, Amiga, embedded ARM, and dozens of other platforms that cannot be tested in a standard CI environment. The automation I described for pinning submodule pointers in fpc/build is still valid as a mechanical step. If the CI can cover where 80-90% of the FPC userbase sit, that should be plenty good enough. The way lesser used platforms will simply trail along. A revision worth considering: rather than the tag being the sole trigger, the RC cycle could include a lightweight sign-off checklist — one entry per supported target — that target maintainers update as they validate their platform. The final release tag would only be applied once all _critical targets_ [the 80-90% of users] have a green tick. GitLab supports this via a checklist in an issue or MR description. This keeps the automation useful while acknowledging the multi-target reality. I would very much welcome input from you or anyone else, what a workable sign-off mechanism would look like in practice, and what is considered the Tier 1 platform (data backed info would be very useful here). --- On roles and volunteering --- "Designate" was poorly chosen — it implies authority I do not have. What I meant was: for the process to function, someone needs to agree to own each area. I cannot assign that; the team has to. You asked whether I volunteer, and which role. I am happy to take on any of triage coordination, process documentation, CI pipeline improvements or even try my hand at release manager. I acknowledge that domain ownership of Compiler, RTL, and FCL has to come from people with far deeper knowledge of the internals than I have. You are also right that "target maintainers" are absent from the proposal. That is a real gap. The model needs a named person responsible for each primary target, both for ongoing review and for the RC sign-off I described above. I will update the proposal to reflect this. --- Summary --- The proposal is a starting point, not a finished plan. The feedback so far — yours, Marco's, and others' — is making it better. I will revise the document to address the cross-building/sign-off gap and add target maintainers as a defined role, then share an updated version here for further review. Thanks again for taking the time to engage with this. Regards, - Graeme - _______________________________________________ fpc-devel maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
