What are we missing?

[kupferstecher]

Would you countenance the destruction of library books just because they were 'old' ?

Actually libraries do discard a lot of old books in order to get space for new ones.
In the wiki/documentation the space is not critical, but old information could be marked as such. And put on less prominent positions. Or some information could be merged.
Nevertheless I wouldn't delete old information just to make things look more tidy. And I'm sure most members here hesitate to delete or even change the others documentation work and rather write a third tutorial on how to build an android cross compiler instead of updating the existing ones.

Perhaps its this fuzziness which allowes the high number of targets, which is amazing.
Delphi in comparison put all their efforts in one target.

So imperfectness brings benefits, too.

[Wosi]

Benjiro and others, I must ask you to stop the empty whining. Think, you could have improved the documentation, fixed bugs or do something else useful while writing the horribly long rant.
I know this will escalate like an avalance, more people will join claiming the project's developers try to prevent progress, they don't even want to use GitHub, they work too slowly for us, they are evil ... blah blah blah ...
This is not the first time it happens.
I suggest now that every whiner must somehow improve the issues he is whining about. This is a FOSS project in case you didn't know, done purely by volunteer workers.
If a whiner refuses to work to improve things, he will be banned from this forum. Does it sound reasonable?

Most of Benjiro's critics are valid. I agree with most of his points except for the Pascal syntax related things. I don't see criticism as whining but as a kind of contribution. Benjiro listed a few points about what the FPC world is missing. There are a lot of people who dislike Pascal. Some of their arguments are valid but others are simply not true. One of their arguments is "Pascal is dead". Most of them don't even know about FPC even though they visit hackernews, dev.to or other general programming websites a couple of times a week. At least on hackernews FPC pops up from time to time. But what's the first impression to somebody who starts to look for FPC related resources on the web? Most websites look like they were build in the late 90's. Screenshots of Lazarus and UI applications built with it do look also like they are about twenty years old. What is the impression an average 18 year old student will get when he visits https://www.freepascal.org/ and https://www.lazarus-ide.org/ for the first time? That must feel like a flash back to his earliest child hood. I doubt this will attract further attention towards FPC.

The other very important Benjiro brought up is GitHub. SourceForge used to be a good place to host open source projects in the early 2000's but this has changed dramatically in recent years. It's extremely hard to contribute on a SourceForge project compared to GitHub. I wanted to commit a small bugfix (a one-liner!) in January this year. I gave up after a while as it was way too complicated to do all this patch creation, patch upload, mantis bug tracker and mailing list stuff. I decided not to contribute the bug fix. The fix is described in the corresponding Mantis ticket, so it's not lost. You can call me a whiner but that doesn't help anybody.

If an open source project is looking for new active contributors then the maintainers
 - should make it as easy as possible to contribute
 - and should try to attract new developers

By now FreePascal doesn't make a good job here. Don't get me wrong, it's awesome how good the compiler and many libraries are performing on many platforms. And it's even more awesome when you take into account that it's all done by hobbyists. It's perfectly fine for the devs to do their hobby using the tools they want to. But nobody should whine about missing contributors when the project is not present at the places where open source enthusiasts spend their time.

[JuhaManninen]

Nevertheless I wouldn't delete old information just to make things look more tidy. And I'm sure most members here hesitate to delete or even change the others documentation work and rather write a third tutorial on how to build an android cross compiler instead of updating the existing ones.

Old text must be deleted from documentation to keep it good.
You just pointed out the biggest problem with wiki in general. Deleting old text written by somebody else is amazingly difficult. It is a psychological thing. Writing new text is much easier. That is why a public wiki can never be well structured. It will always be a mess.
Wiki has its good aspects but it cannot be the only source of documentation.

Perhaps its this fuzziness which allowes the high number of targets, which is amazing.
Delphi in comparison put all their efforts in one target.
So imperfectness brings benefits, too.

I am not sure if I follow you. Many targets could be supported better with less fuzziness.
Things should be better organized etc. but limited resources prevent it. It does not mean it is good.

About Benjiro: I am happy that he is gone but only for his own sake, not for others' sake.
I guess Pascal was an obsession for him. He didn't see anything good in it, yet he continued using it. Even his friends mocked him about it. It is clearly better to switch to another language.
If I understand right, this is not a religious sect trying to convert everybody to follow it. No, the projects should be embraced only if they feel useful and good.
The changes Benjiro suggested would turn Pascal into something very different. It is like asking an elephant to turn into a giraffe or wise-versa, or something as unnatural.

[kupferstecher]

I am not sure if I follow you. Many targets could be supported better with less fuzziness.
Things should be better organized etc. but limited resources prevent it. It does not mean it is good.

What I mean is that if resources are scheduled to reach the optimum, then there would always be tasks with higher priority than a target DOS or whatsoever. There might be no arm support today, no android etc. But instead a better Windows/Linux support.
Sure its not contradictory to have both, good organization and pluralty, but its less likely.

[marcov]

Most of Benjiro's critics are valid.

Some of the critics are valid, specially the documentation and website points, however their implied solutions are not. You can try a non professional media offensive on social media and the like, but you simply will get you nowhere and it saps resources.  It is just the current iteration of the old "you build it and contributors will magically come" argument which has repeatedly proven to be untrue.

That said, previous initiatives of people that did do good things for the more concrete issues (the ones that actualyl did things rather than do gratuitous posts and then delete their account). I think the last one did the lazarus-ide website design he seems to despise.

I don't recognize anything sane in the codebase/compiler/bugreporting parts.  I think those were just thought up on the spot and mixed with an up-to-date (but hollow sounding) vibe.

I don't see criticism as whining but as a kind of contribution. Benjiro listed a few points about what the FPC world is missing.

All have been known since 2000 or earlier. They are nothing new or insightful. IT fashion-du-jour is in every magazine. The problem is the manpower lacks to actually do something about it on a scale that actually matters for these perceptual things.

Irrational feelings are hard to fight, look who is president of the US :-)

There are a lot of people who dislike Pascal. Some of their arguments are valid but others are simply not true. One of their arguments is "Pascal is dead". Most of them don't even know about FPC even though they visit hackernews, dev.to or other general programming websites a couple of times a week. At least on hackernews FPC pops up from time to time.

While true, it is takes more than an ad-hoc amateur media offensive to correct this. Embacadero/Borland has been trying in vain for years and they have quite a bit more resources to spend.

Most of the sentiment comes from people that had to use pascal in some introduction to programming course instead of whatever the darling l33t language at the time was. It never got a real chance, and they never revisited.

There is an enormous amount of effort necessary to counter such sentiments. Basic also never got rid of its beginner reputation, despite even having Microsoft behind it.

The other very important Benjiro brought up is GitHub. SourceForge used to be a good place to host open source projects in the early 2000's but this has changed dramatically in recent years. It's extremely hard to contribute on a SourceForge project compared to GitHub. I wanted to commit a small bugfix (a one-liner!) in January this year. I gave up after a while as it was way too complicated to do all this patch creation, patch upload, mantis bug tracker and mailing list stuff. I decided not to contribute the bug fix. The fix is described in the corresponding Mantis ticket, so it's not lost. You can call me a whiner but that doesn't help anybody.

Being a lazy ass, and trying to dump the load on the maintainers doesn't either. IMHO it is a really sad argument.

btw all Sourceforge ever was to FPC/Lazarus was a mirror. It's odd that you don't know that.

If an open source project is looking for new active contributors then the maintainers
 - should make it as easy as possible to contribute
 - and should try to attract new developers

If you think you really will recruit long time contributors from people that can't be bothered with some due diligence in submitting a patch, then you are simply wrong. Github might be a fun place for beginning projects (where it doesn't matter much), but the opinions about established projects are mixed.

[JuhaManninen]

The other very important Benjiro brought up is GitHub. SourceForge used to be a good place to host open source projects in the early 2000's but this has changed dramatically in recent years. It's extremely hard to contribute on a SourceForge project compared to GitHub.

I must comment here because this is partly wrong information.
First, neither FPC nor Lazarus are hosted in SourceForge. They have their own Subversion server. SourceForge is used only as a robust provider for release downloads.

I wanted to commit a small bugfix (a one-liner!) in January this year. I gave up after a while as it was way too complicated to do all this patch creation, patch upload, mantis bug tracker and mailing list stuff. I decided not to contribute the bug fix. The fix is described in the corresponding Mantis ticket, so it's not lost. You can call me a whiner but that doesn't help anybody.

A patch can be created by typing "svn diff", or if you prefer Git type "git format-patch". TortoiseSVN on Windows makes it even easier.
It can be uploaded to Mantis by clicking a button that says "Upload File".
Mailing list is not needed for that.

If an open source project is looking for new active contributors then the maintainers
 - should make it as easy as possible to contribute

It is quite as easy as it can be. With GitHub the process is more complex. There you must create local hash keys, register them, fork a project, clone your forked project to a local repository, change code, commit it, push changes to GitHub, make a pull request for the original project and then hope the one account holder person there will notice it.

Our system is smoother. There are many subsystem maintainers checking bugtracker changes.
Anybody can type "svn diff > MyPatch.patch" and click a "Upload File" button.
How could it be easier? If somebody is not clever enough to do that then we may not need his contributions.

In fact the arguments here resemble the Git versus SVN bashing campaign some 6-7 years ago. FPC and Lazarus developers were bad and against progress because they didn't switch to Git. The claim was there would be substantially more contributions if Git was used.
Finally I wrote instructions about how to use Git for Lazarus development either using a mirror repo or git-svn link.
As a surprise there were no more contributions ... but the whiners left, at least temporarily. Now the same arguments are back for some reason. In reality things would be worse if we switched to GitHub. This is all bullshit, an excuse to bash the project.

- and should try to attract new developers
By now FreePascal doesn't make a good job here.

There is one serious problem. Sometimes it takes a long time, months, a year, before valid patches are applied or even acknowledged. It is extremely frustrating for the contributor.
I sincerely ask FPC devels to pay attention to this.
It was a serious problem with Lazarus patches, too, but now it is better AFAIK.

[Wosi]

btw all Sourceforge ever was to FPC/Lazarus was a mirror. It's odd that you don't know that.

Sorry, my fault.

If you think you really will recruit long time contributors from people that can't be bothered with some due diligence in submitting a patch, then you are simply wrong.

If you really think you can change people and force them into your own open source workflow which is different to roughly 95% of all the other open source projects in the world than you are simply wrong. You won't change people - at least not without an immense media campaign! An open source project can adopt to people's behaviour to make it easier for them to contribute. It's still challenging enough to learn the project structure and programming concepts etc. before a developer can contribute quality code to the project. Why bother new people with a different workflow and different tools? From an outsider's point of view FreePascal seems to build a wall around itself that keeps occasional contributors away. Of course, you want long term contributors who spend a huge amount of time in the project. But do chances increase to find them when the project lives in its own world?
What is the pro argument for staying on SVN and create / upload patch files by hand? Is there any argument besides "We always did it like this" and "The long term contributors don't want to change the workflow" ?
I occasionally follow discussions about moving to GitHub on other projects. IMO the Linux kernel project in the only one that has valid arguments against GitHub as it doesn't meet the requirements for such a huge project.

It is quite as easy as it can be. With GitHub the process is more complex. There you must create local hash keys, register them, fork a project, clone your forked project to a local repository, change code, commit it, push changes to GitHub, make a pull request for the original project and then hope the one account holder person there will notice it.

Our system is smoother. There are many subsystem maintainers checking bugtracker changes.
Anybody can type "svn diff > MyPatch.patch" and click a "Upload File" button.
How could it be easier?

Oh, come on, you can't be sorious with that one. You make the GitHub process seem longer than it is by just mentioning every single click you have to do. You don't need to create hash keys. Forking a project is a single click, cloning is the same as svn checkout but much faster and making a pull request is again only one click. Whoever is interested in the project receives an email as soon as a new PR is created. The vast majority of open source contributors are used to this workflow.

And how can it be easier? If I want to make a PR for a one-liner then I can edit the file in the browser and create an instant PR from it. No fork, no clone, no local commits, no patch files. This is contribution made as easy as using a discussion forum.

In fact the arguments here resemble the Git versus SVN bashing campaign some 6-7 years ago. FPC and Lazarus developers were bad and against progress because they didn't switch to Git. The claim was there would be substantially more contributions if Git was used.
Finally I wrote instructions about how to use Git for Lazarus development either using a mirror repo or git-svn link.
As a surprise there were no more contributions

That's no surprise. Two reasons: First of all, GitHub can only be one of many steps to attract people. There is no silver bullet that makes everything better.
Second, using Git and GitHub for an open source project without being able to make pull requests is pointless. The current git workflow for Lazarus only adds a layer of complexity.

[skalogryz]

I occasionally follow discussions about moving to GitHub on other projects. IMO the Linux kernel project in the only one that has valid arguments against GitHub as it doesn't meet the requirements for such a huge project.

That sounds kinda funny.

Because GitHub is a glamorous web interface based around git functionality.
Where git

...was created by Linus Torvalds in 2005 for development of the Linux kernel, with other kernel developers contributing to its initial development.

  (link)

That makes me think, that any glam-looking interface, in the end, doesn't really help the development.

Thus well established workflow of a project, should not be adjusted towards the latest "trends" and "fashions", unless there's a significant technical benefit to the project.

[JuhaManninen]

Oh, come on, you can't be sorious with that one. You make the GitHub process seem longer than it is by just mentioning every single click you have to do. You don't need to create hash keys. ...

Yes you need them if you want to push your commits to GitHub. You have to create them again after you install a new Unix / Linux distro.

If I want to make a PR for a one-liner then I can edit the file in the browser and create an instant PR from it.

Then how do you test the code compiles and works? Sounds fishy!

That's no surprise. Two reasons: First of all, GitHub can only be one of many steps to attract people. There is no silver bullet that makes everything better.
Second, using Git and GitHub for an open source project without being able to make pull requests is pointless. The current git workflow for Lazarus only adds a layer of complexity.

Now a pull request is the silver bullet that makes everything better?
Earlier, years ago, it was Git itself. Many times more contributions were promised if only Lazarus switched to Git.
Please let's stop this nonsense. You are wasting your and everybody else's time.
You have no intention to contribute anyway. I have learned that much about the mentality of people behind these rants. If we truly switched the development to GitHub, you would find another excuse to bash the project's developers.
I suggest you find a project hosted in GitHub and contribute there.

It is interesting, the people who actually want to contribute to this project have no difficulty creating patches and clicking the "Upload File" button.
Maybe you should contemplate on that for a while.

[balazsszekely]

@JuhaManninen
It is interesting, the people who actually want to contribute to this project have no difficulty creating patches and clicking the "Upload File" button.

Creating a patch with TortoiseSVN takes about 10 seconds, without TortoiseSVN maybe 20(if you are slow at typing  ). The same is true for git. Navigating through the complexity of a large project such as Lazarus it requires much more time, sometimes days or even weeks. If somebody is willing to find a bug, I'm almost certain he manage somehow to create a patch.

[Thaddy]

Creating a patch with TortoiseSVN takes about 10 seconds, without TortoiseSVN maybe 20(if you are slow at typing  ).

I timed mine:
cd ~/fpc311
svn diff > mypatch.patch

3 seconds  .

[marcov]

If you really think you can change people and force them into your own open source workflow which is different to roughly 95% of all the other open source projects in the world than you are simply wrong. You won't change people - at least not without an immense media campaign! An open source project can adopt to people's behaviour to make it easier for them to contribute.

Your workflow is too idealized and far from reality. The figures you quote are inflated. Nearly all big projects have own repositories, and at best some github mirrors.

The idealization of your workflow only works for very simple patches that are accepted without dialogue or modification by people that know both github, have an account AND fpc/lazarus hypothetical layout on github.

That is so far from reality where the only patches that are committed as is are usually from long time contributors.

Moreover, newbies will have to learn the FPC structure be it in SVN or on github.

It's still challenging enough to learn the project structure and programming concepts etc. before a developer can contribute quality code to the project. Why bother new people with a different workflow and different tools?

Yeah. If Linus had just used SVN we wouldn't have this discussion. Apparently there are sometimes reasons to deviate from the norm. And not just us. Direct equivalents like LLVM and GCC also don't work that way.

Only small teams with few rules and low complexity do. For the rest it is only a way to invite low quality input.

From an outsider's point of view FreePascal seems to build a wall around itself that keeps occasional contributors away. Of course, you want long term contributors who spend a huge amount of time in the project. But do chances increase to find them when the project lives in its own world?

There is no wall. You inflate githubs popularity, and look over procedures that even large projects have on github, and push some idealized case that only exists in a few cases. GCC requires copyright assignment to be signed even!

What is the pro argument for staying on SVN and create / upload patch files by hand?

Note that changing to GIT is something else than github all together. I don't think this procedure would change if we would change to git. But the svn vs GIT discussion has raged many times already.  Just search forum + maillist.

Is there any argument besides "We always did it like this" and "The long term contributors don't want to change the workflow" ?

In a nutshell, benefits lower than projected, costs/trouble/migration higher than projected and nobody wants to be the long term responsible (and that includes actually finding solutions for the remaining counter arguments other than just doing a quick conversion and say "DVCS/GIT is really different and you shouldn't want that" which is just a simple form of saying f*ck you)

I personally don't think the conversion is worth it, and then I already assume that GIT really is better long term. Which I'm not convinced of either. If only and particularly the fact that it doesn't have something easy as substitute for the current revision numbers and there are several issues relating to maintaining stable branches too. (see next post for details)

But since in my current FPC devleoper role, I only use a small subset of the version system, so I'm willing to adapt.

But only if the conversion is taken seriously, and not done as a quick conversion to give a small portion of users the features they want and then leave the rest with the broken pieces to solve themselves. If there is a workflow now, the GIT migrator will have to come up with an acceptable alternative.

And I see that a lot of communication now is done on the basis of revisions, and I do most of the merging to stable branches. So those are things I would like to see covered (and truly covered, not just a one line workaround and postcommit hook workaround)

I occasionally follow discussions about moving to GitHub on other projects. IMO the Linux kernel project in the only one that has valid arguments against GitHub as it doesn't meet the requirements for such a huge project.

Submitting the project to a third party that blocks access from certain countries (and we have a long time contributor in Mali, which is on the US blacklist) is not an option anyway. Same with crypto laws.

A mirror, at best. Same as with sf.net.

[marcov]

I found an old bullet list. It is not complete, but might give you an idea:

1. global revision versions instead of not sequential unwieldy guids or urls. revisions are easy to communicate with, and are unique across branches.

2. partial checkouts (needed depending on if the solution to (3) is to stuff everything in a giant repo) (e.g. the fpcbuild repo has a history with in it all binary binutils, both cross and native used since 2005))

3. externals

4. one should be able to mark certain branches that never should have mutliple heads. (fixes and other stability branches)

5. decent merge tracking of what is merged to which branch. cherry picks already fail if previous merges needed some minor editing to merge.

(6.) lineendings handling. Lineendings in the repo should never be an issue and human error should be minimized (no client setup or post commit hook fiddling required etc). There was some movement on this in GIT since the last discussion, so it might be solved. Didn't get a practical evaluation of the current state though, so I put it in parenthesis

7 Many simple operations are simple in SVN, and require a combination of commands (and often the check of complicated output) in git. 

[ccrause]

My experience of trying to fix and submit patches for both FPC and Lazarus was that the effort of understanding the code base and figuring out what was wrong/lacking and then correcting/improving it was an order of magnitude more difficult than figuring out how to submit said patches.  I use both svn on SourceForge and git on github for small projects, so far the differences between the systems haven't fried my brain*.

* Of course one could argue that my brain is fried and because of this fact is incapable of noticing it.

[avra]

GIT is great and I use it a lot, but for anyone who thinks that GIT and GITHUB are perfect here is some food for thought:
http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html

How to use GIT to submit patches to Lazarus:
http://wiki.lazarus.freepascal.org/git_mirrors#Submitting_changes
http://wiki.lazarus.freepascal.org/Creating_A_Patch#Using_a_forked_Git_repository_directly
http://wiki.lazarus.freepascal.org/Lazarus_git-svn

So I honestly don't see what is stopping gitters to submit patches?