Op 16-4-2026 om 11:29 schreef Michael Van Canneyt via fpc-devel:
Every time the build or release is discussed, all I hear practically
amounts to "the problems are insurmountable". That is why I term it
negativity.
To my best knowledge something like that has never been said. You might
interpret failure to embrace your proposals as such, but that is not the
same thing.
I have reiterated my main points for nearly 6 years now:
1. the building is currently not the bottleneck. Yes, it can be brought
back from a couple of weeks for the first RC for a fixes releases, and
roughly two months for a major release, but even if you could automatise
that to zero (which you can't), it does not fix the current _AND_ past
release gaps. You also do not need CI infrastructure for that,
quarterly attempting to build relevant targets. The problem will always
be the human factor, ALSO to investigate and take action on those CI
builds. And a fact of life is that if the infrastructure gets more
complicated, less people are prepared to deep dive into it to actually
do that.
2a. The major bottleneck is chiefly branching and releasing major
releases. Waiting on features to stabilise takes ages. Those ages are
waiting for people to fix it. You can try to avoid to merge unstable ,
but as I hope you have found out with the loadppu branch that is not
always an easy thing.
2b. Fixes have their own problems, but those are all actually getting
people to move. If there is the shared consensus to release a fixes
release, and continuous merge process have occurred (as the current
fixes branch , it could be done in 6-12 weeks, depending on the number
of needed RCs, and the nature of the feedback on them. That is a full
minor release cycle, checking all the boxes, no shortcuts. Even with
many targets beyond Tier 1 in the mix. We currently have a 5 years
minor release gap., 6-12 weeks is nothing on that scale.
3. Do changes gradually as you get experience. No big bang, no drama, no
longer delays while infrastructure and policies get worked out. Start
some CI work if you want on the side, follow up with high frequency, and
see if it works, and people actually use it. Pace changes.
Keep in mind that in the release sense we haven't fully managed the
svn/mantis to gitlab transition, 5 years after the fact. And you want to
toss in more infrastructural work ?
My sincere hope is that by putting some different structure in place,
things
will go smoother. If we need to let go of some practices from the
past, then
that should be possible.
The only past practice that you could let go that saves a real
bottleneck, is actually caring about what goes into a release. But then
you get back to the snapshots vs release point that I made.
Automating building and branching is all fine and dandy, but the problem
is to actually get content (read: merged revisions) in those branches,
and your proposals are awfully quiet about that. It sets a few schedules
and rules (that basically are an toothless appeal to developers "to
think about the releases and do the merges", but all developers could
have merged all their commits in the current situation already, so what
effectively changes).
You are trying to fix a basic problem (no people actually doing
something) with lots of high level rules and infrastructure that is
copied from large scale projects that allows managers to track progress
of the grunts. IMHO it simply doesn't make sense in a FPC volunteer context.
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
