[fpc-pascal] Some features for FPC 3.0?

[Marco van de Voort]

In our previous episode, Lukasz Sokol said:
> > I don't think this needs to be done formally. Any users can package
> > snapshots cq pseudo releases and mark them as test, and release them for
> > feedback. Then process the feedback, triage it, and communicate that back
> > upstream.
> 
> Which sometimes takes so long, that the downstream tester bypasses the distro
> maintainers and submits patches directly upstream...
> ... only to find out that his patches are not going to be present in /this/
> incarnation of the distro release and he'll be lucky  if they actually hit the next one.

True. This happens with FPC too, if some feature is postponed to the next
major version that can be a long time.  But that some projects take even
more time doesn't mean the principle is flawed.
 
> > That's how the really big projects (like distros) work too. Similarly with
> > the various branches of the Linux kernel, where there are often third party
> > builders that track a certain target.
> 
> Linux approach changed around 2.6.12 somewhere (or later) with/after the upcome of git...
> now they have 6-9 rc releases, merging new features AND bugfixes, one per week or 1.5 average, 
> then branch the head off and the stable branch is strongly advised to be sent bugfixes /only/.

And they have a staging branch before that. I meant with the example that the stable, head
and staging groups are managed by different people and teams.
 
> (Truth be said, I /do/ see resemblance of LK to FPC approach, only FPC has a slower 
> pace and uses different numbering scheme, (which can be (mildly) confusing when 
> one switches contexts often;) also you call it feature-freeze, they call it stable branch... 
> but it's the same idea in its essence)

Linux is big business. FPC not.  The core point of the analogy is that not
every detail of all work within a project needs to go through /one/ central
point. (like the FPC core team in our case or Ueberpenguin Linus in the
Linux kernel)
 
> > So the question should be, when do you think you can release your first
> > pseudo stable snapshot? Throwing it all back to core is useless, since that
> > increasing tasks will only slow development more.
> 
> I for one think, that just encouraging /anybody/ to release pseudo-stable snapshots,
> is not going to help, rather end up with some of them being forks, fragmenting the ecosystem...
> (remember the times of linux 2.4.x-ac or -mm versions?)

They served a purpose, even if the purpose is no longer needed later.
Moreover it has no point to compare with an ideal scenario (new version of
fpc every quarter major branch per year or so) that is never going to
happen.

What FPC needs is longterm committed people on both development and
maintenance topics.

 
> You might end up with some people that are less patient instantiating their own git repos, 
> and adopting faster pace, and the main repos becoming outdated... because their downstream 
> patches won't apply to upstream without considerable amount of work.

That simply can't be stopped. It is of course annoying since usually the
support burden for such projects still falls on the original project (even
if only 2nd line).

But anyone can suddenly imagine he can do a better job and start an
independent branch, I don't think it is wise to let that fact influence how
to setup the process too much.

> I'm actually with Silvio on this 

Silvio sets goals but doesn't provide the resources to do so. That is the
crucial flaw in such rants.

> (maybe by altering the criteria, of how much of a change is considered fit for a next major release, 
>   /considerably/ down; 
>  even if it means, if tracking the features of Delphi compiler is any factor, 
>  that for 1 Delphi release, FPC releases 5 or 6 major releases before it catches up)

That is another fundamental flaw, trying to plan something in a project that
survives on voluntarily work of volunteers.  There is nothing that CAN be
steered top down in projects like this.