There seems to exist some interest in FPC modifications that are incompatible with the official FPC code (SVN trunk). If so, we should find means to open one or more public alternative repositories, and possibly a dedicated mailing list, chat room... Graeme, you seem to be the git expert, what would you suggest for the repository topic?

Next we'll have to agree about the topics, which are subject to a redesign, extension or whatsoever. Clearly everybody can tweak the existing code in any way, but perhaps we want to integrate various changes into one new compiler, what deserves some considerations. IMO at least the back-ends (target systems and CPUs) should be inherited from the FPC trunk, because these require detailed knowledge about both the targets and the related FPC infrastructure (code generation...). The same for the compiler and RTS build process, at least we should have a chance to get a fully working environment (including Lazarus) for any non-standard compiler.

My own interests concentrate on the compiler infrastructure, where I feel a need for a more abstract (parser oriented) API. Next comes the consolidation of the layer beyond that API, as covered partially in my NoGlobals branch. The result should be a more readable and extensible compiler, best along with according documentation.

Unfortunately some restrictions apply to the possible changes to the original code, when we want to stay in sync with the SVN trunk. I've already tried out several ways, with questionable results. At least we have to understand and respect the way, how SVN or Git merge updates into an common branch. IMO large changes should be avoided, they can be moved into include files or into subroutines in a different location. If nothing helps, the original subroutine can be renamed, so that it is not used further, and a new subroutine of the old name can be located somewhere else, e.g. at the end of the unit. Perhaps somebody has more experience with the compatibility and merging of modified code, possibly from multiple branches?

So much for now, from my part. Please specify your own interests, if you want to participate in an FPC fork, and want your work being noticed and used by the community.

The same considerations apply to Lazarus forks, but that's quite a different story. As a general note, I'd like to publish a user-oriented Lazarus version, with only approved (documented) features, and easy installation. Every Lazarus (LCL...) component or feature should be added to that version only iff documented (online help available) and implemented without major flaws. My favorites for exclusion/replacement are AutoSize, AnchorDocking and the management of IDE form positions...

DoDi

Op 2010-10-20 03:30, Hans-Peter Diettrich het geskryf:

possibly a dedicated mailing list, chat room... Graeme, you seem to be the git expert, what would you suggest for the repository topic?

SourceForge has good project management tools, from bug reporting, mailing lists (though I prefer newsgroups), to project website, to repository. Git is clearly my choice due to the distributed development model, huge features set, and it simply fits my way of working better.

As for what I think is a very good workflow and management of a project is the following (taken from the git project itself):

http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

I think the graduation of features is the important part. Promoting the idea of pulling branch directly from somebody else should be common practice, but so too is the "development branch" where various features branches get merged together giving everybody a easy place to test something new.

Anyway, the URL above describes all I have to say on this topic.

Regards,
- Graeme -

I don't have the top post (
http://lists.freepascal.org/lists/FPC-other/2010-October/000468.html ) in this thread to comment on in a more conversation fashion, as a result I reverting to bulleted listing of my views on the subject.

1) In the fpc-devel I have read quite a few arguments that FPC is production quality and no significant changes can be afforded to that code.

While I sympathize with what that implies, it also means that, structurally, FPC is more or less frozen --except for very small incremental alterations, there isn't much that can be done with/to it.

That brings me to this remark by DoDi: "Unfortunately some restrictions apply to the possible changes to the original code, when we want to stay in sync with the SVN trunk."

I am not at all sure that this is the way to go about it. It is very likely that the needed changes will soon amount to a shape that will make it impossible to stay in sync with the FPC trunk.

So, I think it would be more sensible/rational to remove this artificial/unsustainable restriction/desire and decide to call this a proper fork for a new version which may or may not be source-mergeable with the FPC trunk.

2) As it is, FPC codebase represents a very high barrier of entry for the uninitiated, drastically reducing any chances of outsiders coming in and contributing.

To help with that, I'd like to see the new FPC to be functionally as modularized as possible with sufficiently clear boundaries between each so that people can work on parts without having to know and worry about the whole thing all the time.

I can hear the 'speed arguments' (that, doing this would lower the speed of compilation etc.) but I am yet to be convinced; plus, if I had to choose between sacrificing a few percent on raw performance and the ease of maintainability, I'll always go for the ease of maintainability.

3) Alternative parsers. I have read all the objections about this. Yes, it may not solve every single problem. Yes, it will not mean FPC will take over GCC. Yes, not everyone need this functionality. Etc. Etc.

But, all these seem to ignore one simple fact: Object Pascal (OP) is not a widely used language. A lot of code that is out there is in some other language. Which means, OP developers have either to reinvent most wheels by rewriting the code they need (even though it is readily available in some other language) or try to convert that code into OP.

All this is not only a major waste of time, sometimes it requires extensive knowledge of that language.

So, IMO, anything that helps using that large amount of code base can only be GOOD THING even if it isn't perfect all the time.

This is wrong. If a big change promises significant advantages for FPC users, it will be done. Things like turning the parser upside down simply don't have an significant advantage for users.

Graeme Geldenhuys wrote

Op 2010-10-20 03:30, Hans-Peter Diettrich het geskryf: SourceForge has good project management tools, from bug reporting, mailing lists (though I prefer newsgroups),

I also prefer newsgroups.

I could try to set one up, but INN simply scares me. Even if I could get it working, there's also the issue of authentication (to prevent spammers).

Further, a server I set up at home is never going to be as robust as one that runs in a professional environment by professionals --see what happened to forums.talkto.net

But, all my googling couldn't locate a single ISV/ISP that provides private NNTP service with authentication --much like CodeGear's.

Could someone suggest a couple of leads.

Florian Klämpfl wrote

This is wrong. If a big change promises significant advantages for FPC users, it will be done.

The qualifier 'significant' (above and below) is far too subjective sometimes to even have a hope of arriving at a common ground.

But, I'll take my chaces and point at DoDi's alternative parsers proposal.

To me, it does sound like quite a significant advantage.

But, apparently, not so for you...

Things like turning the parser upside down simply don't have an significant advantage for users.

About the 'significant advantage' bit, see above.

If with the new parser design we can produce exactly the same binaries and it handles all the source code that the current compiler does, why does it matter which way up the parser stands?

2010/10/21 Adem :

Oh wow, so you want to change the parser because it "sounds" nice to you?

Seriously, if this work was done more co-operatively with the fpc team, it may have made it. But I think it is too ambitious in the first place. Some people maintain patch quilts for ages before it makes it into the kernel, for example.

Henry

You didn't read Florian's post; did you?

Let me copy&paste the relevant bit here:

"If a big change *promises* significant advantages for FPC users, it will be done."

Did you notice the word 'promises'?

Seriously, if this work was done more co-operatively with the fpc team, it may have made it. But I think it is too ambitious in the first place. Some people maintain patch quilts for ages before it makes it into the kernel, for example.

You make it sound like some of those religious orders where you have to spend years of your life... just to prove your piety.

Meritocracy out, monasticism in? :)

2010/10/21 Adem :

Somehow you have to prove these "promises".

I don't care what it "sounds" like to you, I'm pointing you to valid examples of real features that are complicated and that need to mature and to evolve, but most of all, need a lot of work before they can prove that they are worth anything.

To implement a complicated feature, you need to break down the implementation into a lot of patches to make it easy for review. People aren't going to start accepting your refactoring patches because you promise them that it'll be worth it in the long run.

Meritocracy out, monasticism in? :)

Whatever works for you.

Henry

And, how exactly do you expect them to be proved? On paper?

OK. Let me take a step back.

You did say, above, "/Seriously, if this work was done more co-operatively with the fpc team, it may have made it./" which implies the approach was less than co-operative.

Fine, lest's look at that: Did you notice the response from the core that --/to the effect, that is/-- the code is 15 years mature and those who are familiar with it aren't prepared to see things shifted around.

Would you consider this as anything more than an invitation to do --at best-- cosmetic changes?

Or, let me ask it another way: How would you achieve co-operativetiveness --other than staying out?

You also said, above, "/But I think it is too ambitious in the first place./"

Interesting. Unless I am reading this completely wrong, you're not saying the direction/aim is wrong; just that it is 'too ambitious'.

I would have no qualms with that.

But, expect you to follow it up with something like "among that list, do this first and let's see how it works, then you could move on to this", but, definitely not (I hope) something sounding like "don't touch any of this in more than a couple of lines at a time".

Maybe you thought I sniped back, and hence didn't let you get to that point --if so, I am sorry--, but I personally would appreciate if you could do it now.

To implement a complicated feature, you need to break down the implementation into a lot of patches to make it easy for review. People aren't going to start accepting your refactoring patches because you promise them that it'll be worth it in the long run.

What you said is of course true for incremental changes; but not so much for architectural ones that by necessity result in large changes.

Please take a look at the roadmap for FPC v3.0 here: http://mantis.freepascal.org/roadmap_page.php where it says "22 of 27 issue(s) resolved. Progress (81%).".

Great. A lot of hardwork is being done and all those doing it are busy.

But, where and how do you discuss things about the general direction, i.e. architecture questions?

And the reason is, everyone is too busy to spend time discussing things that are not immediately relevant to a bug or a certain ancillary feature.

I'm probably not the best person to comment here, since I've already been blasted in the past for telling things like they are, but me personally, if I wanted to do something major with fpc, I'd not bother trying to get it integrated to the main branch, I'd spawn my own project, call it something else, and make it clear that it comes from the fpc main trunk. That would satisfy the open source requirements, and give me the ability to make whatever changes I thought would be worthwhile.
Probably not the best approach, but it sure would make things easier on me. :)
Of course, compilers aren't my strong suit, so in my case, the above doesn't apply, but just saying, if it were me, and I wanted to do what you're suggestin, that would be my approach.

Features. Examples why it fixes this or that bug. I didn't see a simple example why splitting the parser into syntactic and semantic parts gives any advantage: the parser in FPC is simply something which works as desired, it has few open bugs (if any at all) and bugs in it are easy to fix.

Typical example for a major rewrite might be unit compilation/loading: the remaining bugs cannot be fixed with the current apporach (well, at least the current developers don't see how to do it, currently, it is stuck at fix one break one), it requires a major redesign. It will also turn upsidedown of the module handling which might break a lot of stuff in short term, however, there might be hope that a better design (we are aware of the flaws of the current design and no, they aren't childish things like shortstring usage) allows to fix the remaining bugs of unit handling in the long term.

Further example: register allocator. The current register allocator is nice but for compilations without optimizations it is too slow. So making the register allocator interface pluggable (it is already to a big regard) and add a new simple and fast register allocator is something which has a benefit.

You make it sound like some of those religious orders where you have to spend years of your life... just to prove your piety.

Other people spent years of their life into getting something working and now suddenly somebody pops up and thinks he can do better? Well, I know these people, they create a big mess and disappear after a few months and leaving a mess behind.

Meritocracy out, monasticism in? :)

The main merit counter in FPC is the bug tracker.

Op 2010-10-22 03:41, Travis Siegel het geskryf:

personally, if I wanted to do something major with fpc, I'd not bother trying to get it integrated to the main branch, I'd spawn my own project, call it something else, and make it clear that it comes from

It seems more and more people are thinking like that. This seems to be true in the Lazarus project as well. This should raise some alarm bells for the FPC and Lazarus project members, but they seem to be purposely oblivious to this fact. There seems to be something majorly wrong with how these projects are managed. I blame it on the "god complex" factor, but that's just me speculating.

Regards,
- Graeme -

It would be great to have some forks, then some people only creating mailing list traffic could finally start coding.

There seems to be something majorly wrong with how these projects are managed. I blame it on the "god complex" factor, but that's just me speculating.

Don't worry, we know this for years.
- "If the FPC team doesn't do what I want I use software XY"
- FPC team: "Fine, do so"
- "Then I fork FPC"
- FPC team: "Fine, do so"
- *silence*

Op 2010-10-22 09:12, Florian Klaempfl het geskryf:

Then I must be the exception to the rule. I didn't like LCL, so I started fpGUI. I didn't like fpcunit, I forked DUnit (to circumvent issues in fpcunit, but did take some fpcunit ideas with me) and started my own testing framework. I'm starting to dislike Lazarus IDE (every release is more buggy that before), I already started work on my own IDE.

I strongly believe in the saying: "put your money where you mouth is", and I'm not afraid in doing so either. I write software to solve problems, not make problems.

Regards,
- Graeme -

Just a simple adhesion testimony from a satisfied FPC-user.

I am very glad that FPC WORKS and that it works the way it does! In particular in combination with the retro-like medieval DOS-IDE! This combo of FPC with the IDE allow me to use and expand my projects in a way that I started in 1989 using Borland PASCAL. Libraries from then still do their job, only now with access to the full memory, on the newer processors and on any platform. The IDE gives me fast insight into the details taking place under the cover of the executable, reducing development time to a fraction. Stability of the compiler is great and my programs are fast!

Where can I pay for some beers to celebrate the work done by the FPC team in the past many years?

Keep up the good work and don't spoil it!

Arjan

Disclaimer RIVM

Indeed, you're one of the few example where mailing list noise is not inversely propotional with the produced code though you didn't fork FPC yet either ;)

Op 2010-10-22 09:04, Florian Klaempfl het geskryf:

Other people spent years of their life into getting something working and now suddenly somebody pops up and thinks he can do better?

It's called evolution. Every new generation is supposedly producing more clever people than the generation before. It's been proven to be true more often that we would like to admit. :)

Regards,
- Graeme -

Yes, but this is not self driven but only because the not so clever cannot assert themself :) Only being a new generation doesn't prove that one is more clever.

Not to mention the fact that in a sufficient complex environment a new generation needs first the breeding and teaching of the old generation :)

You don't need me to tell you you're a superlative developer to the degree that I won't even claim to be a fraction of. But, often, one exceptional talent is granted at the expense of a few others --i.e. none of us are as perfect as we'd like to believe we are.

That longish tirade is meant both to appreciate your talents, and offer negative criticism at some of (what I consider) short sightedness.

Here is what I mean --and, please help me fill in the blanks I am bound to overlook:

How many platforms (OSes and CPU archs) can FPC run on?

My answer is, basically enough --if not more than enough.

IOW, most of the really really hard work is done --not by itself, but by you and other members of the core and sometimes by the odd and daring <g> contributor.

So.. Where do you go from here?

Focus on unit compilation/loading and/or the register allocator?

Of course, you could do that (and by the looks of it, it already is on your mental roadmap too), but are they really --really-- that critical?

I mean, even though having those sorted out would be nice, FPC isn't after all crashing without them.

A near-perfect compiler it probably will be.

Now.. let's look at the other option --not that they are mutually exclusive, but let's consider them that way for the sake of argument.

Let's suppose that we have agreed that it would be much more fun and more useful to turn FPC itself into a kind of component/module which itself is composed of components/modules so that people can use FPC as an engine for their projects more directly, while other people tinker and experiment with modules within the FPC.

At this moment I could offer an analogy from the computer industry, but as is customary, I'll stick with the obligatory car analogy as I already have.

ATM, at least to me, FPC looks like a custom-made engine and gearbox as well as the rest of power train with no user replaceable parts. No mortal can dare tinker with it. Can't swap turbos, can't drop in an alternative gearbox.

It is, however, a piece of art alright. But, when you consider its functional aspect, one invariably wishes to do things with/to it other than admire its complexity. And, complex --by George!-- it is. Yet, complexity isn't a virtue --sophisticated simplicity is.

I think you should seriously consider not considering FPC as a great big black box.

Fixing the the unit reloading logic is quite critical, because it's the main cause of crashes and other weird errors you sometimes (or regularly, depending on how many circular dependencies you have and the kind of changes you make) get when recompiling units without erasing them first or without using the -B command line parameter.

That said, I fully support the creation of a fork of FPC by everyone who thinks that is a good idea. If something good comes out of it, we can always integrate it later (or who knows, main FPC development could eventually move to that fork), and in the short term it will save a lot of time spent on elaborate discussions by everyone involved.

Jonas

Of course, if somebody pops up who we trust that he can handle this, his patches will be integrated. Throwing half-baken patches into the bug tracker, giving up at the first obstacle or reporting own trivial coding mistakes as bugs surely doesn't increase the trust that somebody can handle such a huge task.

The sad thing about all this is: if we integrate all patches without quality controll, people will also cry about the decreasing quality of FPC.

1) In the fpc-devel I have read quite a few arguments that FPC is production quality and no significant changes can be afforded to that code.

This should have been stated much earlier, before I ever started to think about refactoring the compiler :-(

Since parts of the compiler already are OO, it may be no problem to replace the implemenations of entire classes, provided that their functionality is documented - see the thread about the hash tables. Syncing problems arise for the code that implements the interaction, or higher-level use of the base classes, where the dependencies and order of method calls is quite obscure in many cases, and must follow the original code perfectly.

So, I think it would be more sensible/rational to remove this artificial/unsustainable restriction/desire and decide to call this a proper fork for a new version which may or may not be source-mergeable with the FPC trunk.

I want to preserve those parts of the code, that may be subject to further trunk evolution, as kind of an (external) library - with a somewhat strange looking implementation.

Herefore I'll try to leave those obscure pieces of code in place, i.e. in the original units, and only insert additional procedure declarations around the identified functional code blocks (procedure header, begin ... end;). Most such procedures will become methods, so that the local variables of the original code can become class/object members, and no further declarations or changes to the separated code have to be inserted into the original code. Other parts of the code, which become unused (old procedure declarations...), can survive as comments, so that SVN or Git has good chances to merge any updates from the FPC trunk.

+1

I can hear the 'speed arguments' (that, doing this would lower the speed of compilation etc.) but I am yet to be convinced; plus, if I had to choose between sacrificing a few percent on raw performance and the ease of maintainability, I'll always go for the ease of maintainability.

+1

I'm not sure about the speed impact of refactoring - the result may become even faster, by optimization at an higher abstraction level. In the non-production fork we also can drop certain requirements, that only apply to small machines (little RAM, no caches...). According changes may prevent the immediate use of this compiler version on such small machines, but that's acceptable since cross-compilation still can be used for such cases.

I'm not sure about the real-life use of such mixed-language code. When parts of the code require knowledge of other languages, and is not understood by the mainstream coder, such unreadable code could reside in (external, binary) modules as well. Nonetheless it's desireable, for the sake of integration, that such code is compiled for compatibility with the FPC environment (RTL...), so that it can be linked into any OPL application, package or library.

This was the goal of my ToPas project, that converted C code into Pascal, at source code level. Adding FPC, as an full fledged compiler, will simply eliminate the need for such a code transformation, with all known restrictions, and instead will perform the conversion in an lower level, at its intermediate (compiler internal) representation.

DoDi

Well, I doubt that the *want* for such advantages can be followed by the required updates. As it already turned out, most refactoring will result in consequential changes to a huge number of units, whose integration has been rejected for each of my refactoring attempts. It also may be unclear *which* parts of the fork have to be imported, when the achieved advantage depends on other changes. Of course there exist chances for some strictly local changes (micro optimizations), but most likely I won't separate such changes into specific commits, when I come across them while working on an different issue.

But perhaps we then can turn things upside down, and I'll spend some time to prepare certain parts for FPC trunk integration. Then it's up to the FPC maintainers to resolve those issues themselves, that lead to the rejection of my patches before (coding style...).

DoDi

All my projects are ambitious, because I prefer to spend my restricted manpower on such topics, that can not be done easily by everybody else.

Some people maintain patch quilts for ages before it makes it into the kernel, for example.

That's one of the reasons for a fork, I'm tired to wait for the time that any part of my work will be accepted by other developers. The best way seems to demonstrate the impact of my ideas, be negative or positive, and let the FPC developers decide which parts to cherry-pick from the fork.

DoDi

To implement a complicated feature, you need to break down the implementation into a lot of patches to make it easy for review.

This is a contradition, IMO. Big changes can not always be broken down into smaller steps, when the result only compiles after a lot of such small steps have been taken. [Wasch mich, aber mach mich nicht naß ;-]

DoDi

Hans-Peter Diettrich wrote

but most likely I won't separate such changes into specific commits, when I come across them while working on an different issue.

You should really learn the basics of cooperative software development before trying to show up as the great software architect ...

I wouldn't call restructuring the parser ambitious in terms of FPC development, it's just a lot of work. The parser is after all the simple part of the compiler.

2010/10/22 Adem :

Fine, lest's look at that: Did you notice the response from the core that --to the effect, that is-- the code is 15 years mature and those who are familiar with it aren't prepared to see things shifted around.

I'm sure they will be happy to accept changes to very old and mature code if it brings them real benefit. Unfortunately, no real benefit was not produced. Only arguments about style and preference were produced.

Henry

... Or you need to take another refactoring approach. From my experience, patches of that size are one of the main sources of bugs (apart from not checking input data ;), and nobody wants them in FPC.

I believe that there is space to split your patch into several smaller smaller ones. It is lot of work which could seem like a waste of time, but it will give you much higher chance that your solution will be integrated into trunk, and it will show other FPC developers that you understand the way FPC development works, and that you are willing to work as part of that team.

On the other hand, you can always make a fork, and have Graeme criticize your code in several years ;-)

For that we don't need forks. You don't fork a large project when you want to implement a contentious feature that's going to take a while to mature and prove itself. This is what branches are for. Unfortunately you think the fpc team will merge your branch before it is useful.

Good luck with the fork.

I'd like to ask you, if I may, how you would go about it.

Suppose you're the one wanting to do that work.

First, how would you prove you're worthy of the task?

Second, could you really do it in small steps?

Third, how would you feel if the /masters/ kept referring to your efforts as 'half-baked'?

Fourth, how would you react if your attempts are belittled on the grounds of them not being comliant with coding style --of all things?

Fifth, how would you feel if you're considered to be a wet-behind-the-ears noob?

Finally, how do you suggest an understanding conducive to co-operation can be established.

The sad thing about all this is: if we integrate all patches without quality controll, people will also cry about the decreasing quality of FPC.

Too True.

Quality control must, definitely, be applied before releasing the code for production use.

But, "quality control of what?" is the more immediate question.

We need a roadmap (more like an arhitect's design/specification) so that everyone has good enough an idea what is expected at what stage etc.

DoDi has written up some; other people and I have written some (consider them wishlist, if you like).

I'd bet you already didn't have a more detailed plan in your head.

At this poit, let me quote Machiavelli (I think it was him): "A prince isn't accountable for what he did; but for what he didn't".

If he is right --which, he often is-- the onus is on you :)

You need to make the plan against which quality control will be performed.

For that purpose I prefer mailing lists. They also have the advantage that in my (old) Thunderbird I can delete all messages of no interest, whereas I can compress newsgroups only based on the time of a contribution. But that's just a very personal argument.

I also think about opening another blog, as for the Lazarus drag-drop project. It would allow to document ideas and encountered problems, so that I don't have to open and follow dedicated threads in another newsgroup or list. See http://dodi-lcl-dragging.blogspot.com/ for what you may expect to find in such a blog. And also find out how many people added comments to my articles - for some reason I only can see questionmarks or Chinese glyphs :-(

DoDi

Adem wrote

I'd bet you already didn't have a more detailed plan in your head.

This should have been: I'd bet you already *DO* have a more detailed plan in your head.

Florian Klaempfl wrote

Indeed, you're one of the few example where mailing list noise is not inversely propotional with the produced code though you didn't fork FPC yet either ;)

This 'list noise' concept must be peculiar to FPC/Lazarus crowd for I have never seen it come up anywhere else.

Is this, I wonder, because 'noise' adds to the running of the list server? If so, where/who do I pay to put an end to this complaint?

Or, is it because certain people prefer to *own* the place as opposed using a kill file or even deciding to not follow certain threads?

Regardless of the reasons, a separate git repository would allow for any number of additional contributions. My problem still is how to set up such a repository, for public use, and how to sync it with the SVN trunk. Can your fpc/Lazarus git repository be used for that purpose, or can another repository refer to and stay in sync with it?

DoDi

2010/10/22 Adem :

Let me answer as someone who wrote several patches, and only one or two of them were accepted.

Suppose you're the one wanting to do that work. First, how would you prove you're worthy of the task?

Firstly, you need to understand how FPC development works, and to accept that. Secondly, you need to show other FPC developers that you are willing to work (continuous task) and work as part of team.

Second, could you really do it in small steps?

If you really want it - yes.

Third, how would you feel if the /masters/ kept referring to your efforts as 'half-baked'?

How would you feel if someone came and change lot of your code? Would you just blindly accept those changes?

Fourth, how would you react if your attempts are belittled on the grounds of them not being comliant with coding style --of all things?

I would give more importance to coding style. Personally, I change coding style every few months, for two reasons: first, I adopt coding style of the code I use (engines, libraries, ...), and second, I respect my co-worker's coding style (unless it is horrible in which case I talk to them about it).

Fifth, how would you feel if you're considered to be a wet-behind-the-ears noob?

I actually feel like "wet-behind-the-ears noob" every time I start working with new library/technology/problem area. But that's what we are until we learn something :)

Finally, how do you suggest an understanding conducive to co-operation can be established.

It's psychological question - how to you establish trust or love? This is open-source project, and it's developed based on the free will to do so. If you want to be part of that, you need to be team-worker, and that requires not only knowledge but also team working skills. At least, that's how I understand it.

Regards,
Aleksa

Op 2010-10-22 12:08, Aleksa Todorovic het geskryf:

On the other hand, you can always make a fork, and have Graeme criticize your code in several years ;-)

Hey, that's a cheap shot. Be nice. :)

Regards,
- Graeme -

Op 2010-10-22 12:43, Adem het geskryf:

This 'list noise' concept must be peculiar to FPC/Lazarus crowd for I have never seen it come up anywhere else.

+1

Regards,
- Graeme -

Well, other people call it trolling.

By submitting bug or regression fixes.

Second, could you really do it in small steps?

Yes. We did this with the back end as well.

Third, how would you feel if the /masters/ kept referring to your efforts as 'half-baked'?

Trying to improve my patches and not ignoring suggestions how to improve it.

Fourth, how would you react if your attempts are belittled on the grounds of them not being comliant with coding style --of all things?

Follow coding style. Most big OSS projects have a coding style, if you don't follow your patch will be rejected. Basic rule of OSS contribution.

Fifth, how would you feel if you're considered to be a wet-behind-the-ears noob?

Trying not to look like one. See above.

Finally, how do you suggest an understanding conducive to co-operation can be established.

Try to follow established rules.

We need a roadmap (more like an arhitect's design/specification) so that everyone has good enough an idea what is expected at what stage etc.

No. FPC is driven by volounteers. You can create your own roadmap and wishlist and work on it, no more no less.

DoDi has written up some; other people and I have written some (consider them wishlist, if you like).

Yeah, send them Santa.

Anyways, just created a mail filter for you, guess where the mails end :)

Graeme Geldenhuys wrote

Op 2010-10-22 12:43, Adem het geskryf: > This 'list noise' concept must be peculiar to FPC/Lazarus crowd for I > have never seen it come up anywhere else. +1

-1E38

http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

That's the language spoken on other places.
Here it's more that you are treated like a Disney princess. (http://disney.go.com/princess/)

helmut

Op 2010-10-22 13:02, Aleksa Todorovic het geskryf:

This is where I think FPC and Lazarus teams get it all wrong. Not everybody wants to "join for life", hold hands and cuddle around the source code. Many times I use a tool, find a bug or annoyance, fix it and contribute back by supplying a patch and most importantly, MOVE ON. It's up to the FPC devels to review and commit those changes. But no, we must first fight about it for ages, prove ourselves to the ends of time before anything is accepted "outside the close family unit". There loss, not mine.

God sakes man, this is ridiculous! Look at other successful open source projects - they don't work like that. If your patch works, that enough. No need to prove your loyalty shit.

The FPC and Lazarus teams keep bitching about not having enough contributors. Well, you can start by.... NOT MAKE IT SO F**KEN HARD TO CONTRIBUTE.

I've taken the following stance with the Lazarus team. I contribute, and forget about the patch. They can do with it as they please, I did my part. It works on my side, git makes it easy to ingrate that fix/feature after every update, that's what's important to me. That's not a very successful way from their side in running a open source project, but they left me no choice. I don't have time to quibble over every line of code I changed. FPC seems to follow closely behind the ways of the Lazarus team, and that makes we want to contribute even less.

Martin Schreiber (author of MSEide&MSEgui) seems to have the write approach. Fork everything in FPC (one of his examples being sqldb code), and maintain that code yourself. No hassles, less stress, a happy life. If FPC team wants any of his changes, they can go fetch it themselves.

Regards,
- Graeme -

That's fine for simple patches and such patches are normally directly committed to FPC. If someone wants to rewrite/restructure half the compiler however, then it's not fine, because such a patch can easily cause more work than it removes without offering enough benefits that offset this work.

Jonas

Aleksa Todorovic wrote

2010/10/22 Adem: Let me answer as someone who wrote several patches, and only one or two of them were accepted.

I do appreciate you responding to these questions, but I would also like to hear Florian's comments for his stance (whether he likes it or not) represents a different category of multiplier.

You're of course right --a team can only be a team if its members work in sufficient unison.

But.. and there's always a 'but'..

These things usually work give'n'take fashion.

I mean, a certain amount of flexibility is required from the team too;
or else it risks becoming a cult sort of thing.

I am trying to point at being accomodating..

> Second, could you really do it in small steps? If you really want it - yes.

There's, I am sure you'll agree, a limit to 'really wanting it'.

> Third, how would you feel if the /masters/ kept referring to your efforts as > 'half-baked'? How would you feel if someone came and change lot of your code? Would you just blindly accept those changes?

Of course not. Nobody expects anyone to do that.

But, a litlle 'thank you' would go a long way --even if you don't mean it.

Personally, I am far less flexible about coding style than you are. The moment I start looking at a piece of code, I want it to be formatted the way I am accustomed to. I suspect a great majority of Pascal people are like that too.

While using Delphi, DelForEx did everything I wanted and was faster than I needed.

In FPC/Lazarus world, we have JCF.

Which is sort of fine, but it is slow to begin with.

And worse, it has no guarantee to format all FPC/Lazarus code.

When it fails, it gives me fits --derails all my train of thought.

The thing is, I am (was) quite familiar with JCF [I was laterally involved in its development], and it's not its fault that it fails at some code. It needs to be updated.

It's true problem is speed: basically JCF needs to be re-written.

I suppose I could do it, but most of it would be a waste of time since the stuff it needs is already (somewhere) in FPC is always up-to-date.

My aim was to come up with a code formatter in both as console app as well as Lazarus/whatever module so that (say) when I receive/retrieve code from some repository I'd apply MY coding style, and when it's time to submit/upload I'd apply the receiver's coding style.

It was to be a cure for 'coding style' headaches.

Well.. it didn't quite happen.

Instead, that discussion turned into 'list noise' which resulted in the creation of 'fpc-other'.. :)

Yeah, I feel the same.
But, what I feel and what I am made to feel do not necessarily produce the same psychological sensation :)

True.

There does need to be a point of compromise/equillibrium.

If the time/effort to gain that trust/love takes too long, it may become likely that one/both party loses interest and takes off.

We may explain those absences as 'silences' but at least some of them are loses in the 'should have been avoided but we'll never know' category.

Florian Klaempfl wrote

Anyways, just created a mail filter for you, guess where the mails end :)

I don't mind the filter; this is life, it happens,

But, I must say I am disappointed at the lack of management skills.

What did you google? Linus bullshit ;)? Great post, but I just learned, I'am still too nice and patient.

Can you describe the requirements for that part, that allow others to understand and think about the problem, and to invent and explore possibly different solutions?

References to existing code are of little help, because that code obviously is not an adequate solution. A description of the encountered problems may be helpful, in order to prevent others from ending up in the same dead ends.

DoDi

Graeme Geldenhuys wrote

God sakes man, this is ridiculous! Look at other successful open source projects - they don't work like that. If your patch works, that enough.

Oh yes, bringing a patch into the linux kernel is just simple compared with FPC. Xen, ReiserFS4, Android patches etc. were applied within days. Oh, wait .... they are still no in the vanilla kernel though it's so easy as Graeme just explained.

The FPC and Lazarus teams keep bitching about not having enough contributors.

You missed the "good" before contributors. Hacking together some bullshit and praising it as god's own code is something I can do as well quickly, even after five bears.

Op 2010-10-22 13:40, Jonas Maebe het geskryf:

That's fine for simple patches and such patches are normally directly committed to FPC. If someone wants to rewrite/restructure half the compiler however, then it's not fine, because such a patch can easily

Valid point. But sometimes [in my case more relevant to Lazarus project than FPC project - to be fair] a relatively small patch is contributed, but then it is totally blown out of proportion - as if it was a total rewrite of something, which it wasn't. Such actions alienate contributors - ending up in the project receiving less and less contributions (big or small).

Regards,
- Graeme -

Oh yes... I sent a small patch to the video4linux mailing list (which is part of the kernel) in April. In July I sent a corrected version (ok... that time difference was my problem) and yesterday it was finally queued for inclusion in 2.6.37.

But I wanted that patch in there, cause I wanted my device to work without manually patching around. So I waited and finally my wish was fulfilled :D

Regards,
Sven

A patch to make every early fpc versions work with linux (adding support of the enter instruction in the kernel) was rejected. With the comment, "support of the enter instruction is not needed, gcc doesn't generate it anyways", though enter is supported even by 80286 processors.

So much about the truth of Graeme's statement :)

Op 2010-10-22 13:30, Helmut Hartl het geskryf:

That's the language spoken on other places.

...and I should forward you some of the private messages I received after discussions in FPC or Lazarus mailing lists. Yes they kept it in private, but the language used and personal insults will make Linus's message look like a saint. So here is no better than there.

Regards,
- Graeme -

Op 2010-10-22 12:47, Hans-Peter Diettrich het geskryf:

I don't actually know how collaboration (write permissions for others) work with GitHub, that is why I suggested SourceForge. Just keep in mind, Git is a distributed VCS, you can pull and push from/to anywhere. The repository in GitHub is just a "public view" of one repository, mimicking the "single server repository" model of SubVersion, CVS etc. Yes you can clone the GitHub mirror as a starting point, then publish your branches to wherever you want.

At the moment the github mirrors of FPC and Lazarus are a one-way street. I setup our server to only push Trunk commits from SubVersion to Git. None of my personal branches end up on GitHub's mirrors.

Public collaboration can easily be accomplished via Pull Requests (the contributor notifying you of the server and branch you can pull from), or posting patches via email (newsgroups or mailing lists). Git has excellent email+patch support (official method used by git.git project itself), and can extract and apply patches directly from emails without hassle.

If you do the latter, it would be wise to get organized early on. This is what Junio (from git.git project) does so well. Each contributor gets his own branch (usually by using initials) in Junio's local repository. Those contributor branches will exist until the features is dead (not going to be accepted), or until it made in into 'master' (what will become the next release). Keeping them in branches makes the job really easy for git. You can quickly query another branch to see what commits haven't been applied/merged yet, apply additional commits (improvements to the original patch) etc...

I highly recommend you email Junio in person, or post to the git mailing list for some guidance. Junio does an excellent job, and taking into account that he is one man running most of the git repository tasks, cutting releases etc. Very impressive for such a busy project.

Regards,
- Graeme -

Exactly that was my intention.

In our previous episode, Hans-Peter Diettrich said:

True. But then the corresponding advantages must be that much bigger.

And more certain.

In our previous episode, Adem said:

I don't mind the filter; this is life, it happens, But, I must say I am disappointed at the lack of management skills.

You should ask yourself how management skills work in a community where nobody can force work on sb else.

Graeme's last mail where he explains he just wants to drop quick and dirty patches AND IT IS FPC'S CORE TEAM JOB to make head or tails of it, explains the fundamental misconception better than I could do here.

It takes an infinite amount of patience.
But, sometimes even that runs out.

To conserve some of that patience for the real important things, it's probably best for a manager/leader not to enter into nit-picking discussions.

At times like these, I read 'Linus on kernel management style' [ http://lwn.net/Articles/105375/ ].

Not that it helps resolve anything, mind you; but, it soothes me to know that certain headaches are integral part of the function you've undertaken.

Graeme's last mail where he explains he just wants to drop quick and dirty patches AND IT IS FPC'S CORE TEAM JOB to make head or tails of it, explains the fundamental misconception better than I could do here.

Personally, I find it more useful to focus on the solution Graeme found for himself and not on the complaints which must have grown out of frustrations.

Here is that 'solution' which should be in Mantis as an auto-responder for every submission:

/*When you contribute, forget about it until the time someone from the core team contacts you directly or refers to your contribution in one of the discussion lists.
In the mean time, if the contribution is important for your own internal work, use git to ingrate that fix/feature after every update. This way, you will have micro-forked FPC (or Lazarus or whatever) but it is OK; forking isn't a sin.*/

Now, if only Graeme wrote up a comprehensive (and comprehensible) howto for doing that :)

In our previous episode, Adem said:

Yes. Forever, since it won't happen. Specially if the workpressure is increased several magnitudes because people don't bother to put in some minimal effort to present their work.

To conserve some of that patience for the real important things, it's probably best for a manager/leader not to enter into nit-picking discussions.

I don't see why nto.

At times like these, I read 'Linus on kernel management style' [ http://lwn.net/Articles/105375/ ].

I don't care what Linus says. (either the Snoopy or the penguin one). But I'm pretty, pretty sure, that Linus will throw back a bad patch in your face.

I don't know what this means. Please answer to the actual quote.

That doesn't seem to help much either --as, then, it can be perceived as dumping loads of code.

> To conserve some of that patience for the real important things, it's > probably best for a manager/leader not to enter into nit-picking > discussions. I don't see why nto.

It was just a suggestion.
Just like why parent shouldn't involve themselves in each and every row/argument/discussion kids are having among them; or why a manager should not prematurely intervene in debates between his/her team. Obvioulsy, these are not hard and fast rules, but there's some wisdom in them --or, that's what I have come to think.
It is also a major time (and nerve) saver.

Sure he will.
But, rarely have I seen him --or his lituenants-- pruning every single thread.

See his post 22 Oct 2010 @ 13:38 (about 12 posts above this)

Marco van de Voort wrote

Graeme's last mail where he explains he just wants to drop quick and dirty patches AND IT IS FPC'S CORE TEAM JOB to make head or tails of it, explains the fundamental misconception better than I could do here.

And here I thought that is what a detailed commit log is for. Correct me if I'm wrong, but it seems the norm of SubVersion users is to give one liner commit comments. That is just wrong. The normal in Git repositories, well at least git.git repo and our company repos, is to give a much more detailed commit message. Makes applying patches a breeze, as well as when you have no review a old commit.

Oh yes, the vcs is to blame for poor commit comment. Maybe we should create a list fpc-bullshit for you?

In our previous episode, Graeme Geldenhuys said:

I don't understand what providing quick and dirty patches that are not cleansed in the bug tracker has to do with a VCS. Either SVN, GIT or etching sources into metal plates.

2010/10/23 Adem :

work, use git to ingrate that fix/feature after every update. This way, you will have micro-forked FPC (or Lazarus or whatever) but it is

This works very well indeed. I have +- 15 such feature branches for Lazarus IDE alone, and it takes all of 1 minute to rebase and merge them into my own work branch - after a update.

Now, if only Graeme wrote up a comprehensive (and comprehensible) howto for doing that :)

I think I've done this a few times, but here goes again.

$ git checkout master
$ git pull github master

The 'master' branch is the branch on github that tracks the SubVersion trunk branch.

$ git checkout feature1
$ git rebase master
$ git checkout feature2
$ git rebase master

'feature1' and 'feature2' are branches that implement the features I need, and that are not included in Lazarus or FPC svn repositories. The rebase command resets that branch to be identical to 'master', then replays the commits on top of that. This makes the repository history linear, and looks as if I implemented those features on top of the latest commit in 'master'.

$ git checkout master
$ git checkout -b work

Start from the 'master' branch, then create a 'work' branch off of 'master'. I'll use the 'work' branch to apply/merge all my features I want. This will be the branch I use on a day to day usage.

$ git merge feature1 feature2

This now merges the 'feature1' and 'feature2' branches with the current 'work' branch. Now simply recompile FPC or Lazarus using this 'work' branch. It will then contain the local features you want, without having to bother the FPC or Lazarus team members.

When it's time to sync with subversion, by pulling new updates from github, simple redo the process above. You can even place all these commands in a script or batch file to speed things up even more.

Florian Klämpfl wrote

Oh yes, the vcs is to blame for poor commit comment.

Or maybe actually manager YOUR project better, by telling all the read/write users of your project to give better commit messages. Nobody can describe a patch very well, and the reason for the patch in a single line commit message.

Just to 'svn log' or 'git log' and actually look at the history of the FPC project and the commit messages of each commit. 99% are one liners.

So with such bad practices of yourself and of your team members, you are setting a terrible example. That clearly rubs off on the new contributors - they just follow the example that was set before them. Your are to blame, because you don't manage your project well, or set down some basic (logical) rules for all your team members.

Having descend commit messages for a patch that explains what the patch does, and why the patch is needed, will making it so much easier for the person reviewing that patch.

Graeme Geldenhuys wrote

Just to 'svn log' or 'git log' and actually look at the history of the FPC project and the commit messages of each commit. 99% are one liners.

Why shows git log only a one liners? I though using git fixes this?

Marco van de Voort wrote

I don't understand what providing quick and dirty patches that ....

How do you get to 'quick and dirty'? Not every small patch is a hack or quick or dirty. The same applies for bigger patches. If the author of the patch simply explains in the commit/patch message (git automatically includes those when you email a patch, subversion doesn't) what the patch does, and the reason for the patch, applying that patch should be easier for the person reviewing that patch. They have more detail regarding the patch and what it should do - no guessing required.

But the FPC & Lazarus team set such bad examples (just review the repository history and lengths of each commit message, new contributors just follow suite. Sergei Gorelkin seems to be the exception in the FPC team - he is about the only one that seems to give (above agv) multi-line commit messages, explaining in more detail what that commit does. Jonas Maebe being second after Sergei. Learn from those two!

Florian Klämpfl wrote

Why shows git log only a one liners? I though using git fixes this?

God, now you're being stupid too. 'git log' if you are using the FPC git mirror, or 'svn log' if you are using FPC's subversion repository directly.

Everybody gets the replys he deserves :)

Florian Klämpfl wrote

Everybody gets the replys he deserves :)

That's correct. :)

2010/10/24 Graeme Geldenhuys :

At least you agree on some thing :-)

Vincent

I wondered too, I expected complaints about missing irony tags, they are sooo easy to type with the right editor :)