[fpc-devel] Forwarded message about FPC status

[Marco van de Voort]

In our previous episode, Graeme Geldenhuys said:
> OK, so once again it is proven that Unicode is just not "sexy" enough
> for the core team, so it will stay stagnant for a few more years.

No. Simply getting older.

> That's unless a member ignores all discussions and does his own thing [or
> gets paid for the job].  As Florian likes to says so often, whoever
> implements it decides.  Unfortunately that courtesy is not extended to
> non-members, because what good is a patch [of such magnitude and effort]
> with no chance of ever being committed.  So we are at the mercy of the FPC
> gods.

No. Core members have some freedom in doing their own thing because of a
proven track record, and the knowledge they will generally see a feature or
a development to the end.

And indeed, external patches and committers first need to prove themselves.

But there are many precedents (like Giuliano doing the resource strings),
and committers are being added all the time. There probably near an
handful of committers who are newer to the project than you. More if you
count db-core.

But then you have to work within the team, and respect some traditions and
sentiments. And if there is one thing I hope others get from this discussion
is that you and Martin never got that. But at least Martin _tried_ during the
2.2.2 tcomponent rewrite.

Same goes for Mr. Schnell. 
 
> Many of use non-core developers have given our input with multiple
> solutions, to try and help the private discussions along.

I haven't seen actual input. Mostly I only have seen some simplistic
outlines of radical new solutions that weren't fleshed out enough to fill
the backside of a beercoaster. And most of them were thrown in together with
some anti-Delphi sentiment.

I have never even seen serious attempts from each one of you (like
categorizing the objections, adapting to it, keeping documentation or points
lists).  (for the unicode part at least.  The 2.2.2 work by Martin was
certainly valued)

> But I guess all of us are not knowledgeable enough people.

I wouldn't say that. But the two of you have the problem you always choose
radical solutions, don't have a history of working on core, never done major
projects inside 

>  What a nice F*** Y** to the community.

So basically you just go on bullying in the maillists till you get a carte
blanche up front. Well, IT WON'T HAPPEN.

I dare you to bring up one piece of proposal that is detailed, consistent,
and mustn't be extracted from some maillist discussion, and that shows some
signs that criticism on it was processed. 
 
> Well, let me just say that the idea of two RTL's is rather ridiculous
> too!!

It was my idea actually, to repair the worst problem with delphi
compatibility; the fact that Delphi broke backwards compatibility.

But I abandonned it, because there seemed to be little support, and people
kept believing an overload here and there would solve the problem. IOW there
is no acceptance of the fact that the default stringtype is much more a
global change than a per unit change.

So in spring I gave up, and am now in favour of a 100% delphi compatible
utf16 solution, compatibility break included.  (maintain 2.6.x a bit longer
though, if people care)

> You guys keep bitching about not having enough developers, so how
> on earth do you think you are going to be able to maintain developing
> two RTL's, patching too RTL's when bugs are reported

Again you show your lack of knowledge. It _was_ about two releases built for
every target from a single codebase.  One 1-byte as default, one 2-byte.

I/we hoped we could polish away the different 1-byte codepages away in the
RTL initialization. (so the 1-byte RTL could be used for both the old Delphi
1-byte as one where it is hard utf8. There are some problems with stdio
there though)

But that means one codebase compiled twice (once for 1-byte, one for
twobyte), only with different default types, so that inheriting methods with
string types keep working.

> inform the public to remember to mention which RTL they are using when
> reporting bugs, keeps those two RTL's in sync over time etc. 

It is that, or rewrite it. Note that originally the two RTL solution was a
temporary solution, to allow Lazarus to gradually change from manual to
compiler supported unicode types. (and thus not stick to an old release for
an extended period of time).

I then still assumed that over time on windows the 1-byte one would
disappear and on *nix the two byte one. Only when protests came, it became
somewhat permanent.

> Yeah, it seams you guys are sometimes not to knowledgeable either.  All
> you are going to do is create more work for yourselves.  But hey, who are
> we to state the obvious.

This message is a perfect example how you let yourself guide by sentiment. 
You seem to have started to believe your own advocatism, and think it is
evil core that is holding you back, rather than the fact that doing a few
minor bugs and spelling corrections in the docs will not give you carte
blanche up front to outline major compiler features that will haunt the
project for ten+ years.

And everytime that is pointed out to you, and are advised to start working,
you mumble something non committal about the great (but irrelevant) work you
say you do outside the FPC/Lazarus project, and keep numb for a while.

Of course after a while you restart with your usual arrogance. I've been
timing it, and usually the period is about 4 months.
 
> Anyway, I can see where this thread is heading... just another waist of
> time. So I'll stop here.

For 4 months.