On 2026-04-15 15:18, Graeme Geldenhuys via fpc-devel wrote:
Hi Graeme,
First of all - I understand that you try to move things forward and I
appreciate your interest. In addition, I understand that you prefer
start working on something than participating in potentially endless
discussions. However, I believe that you should read at least some parts
of that discussion. One of those parts is the question (very correctly
raised by Marco!) how does having a fixed schedule ensure that the fixed
releases contain considerable advances against each other while still
ensuring reasonable quality / stability for patch releases. Please, see
below for other two comments.
Regarding the number of merge requests - have you tried comparing the
amount of changes waiting in the merge requests to the amount of changes
pushed to the repository within the last 5 years? I didn't try to
compare it myself, thus I don't know the answer, but I believe that such
a comparison might be beneficial in order to find out whether the
waiting merge requests (some of them probably useful, some other
possibly bad and not appropriate for merging in any case) are
substantial part of the problem, or whether there are other possibly
much more important obstacles.
A few weeks ago I raised concerns about the 130+ open merge requests
sitting unactioned in the GitLab instance. That thread drew a lot of
responses, and it was clear the frustration is widely shared. What it
did not produce was a concrete path forward.
.
.
* Automation for the fpc/build repository: when fpcsrc is tagged
with a release or RC tag, a GitLab CI pipeline automatically
pins the submodule pointers in fpc/build and applies the same
tag there, eliminating the manual submodule update step.
Please, read the discussion (especially our communication with Martin
F.) to get better understanding why this particular part doesn't fit the
needs. I don't say that nothing might ever change in this area compared
to the current state, but please note that cross-building is _not_
applicable for all FPC supported targets and thus building for all
targets cannot be tested / checked by a single person or anything like
that - which is why testing the release build against once created tag
is not enough.
.
.
2. Designate roles: one Release Master, and at least one
Subsystem Maintainer per area (Compiler, RTL, FCL, Packages).
.
.
What do you mean by the word "designate" here - do you have particular
candidates in mind? Do you volunteer for one of these roles (which one)?
Don't you miss target maintainers in your picture (see my comment above
in this context)?
Tomas
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
