Free Pascal / Lazarus Foundation

[k1ng]

One is the rigidity the principle participants have about conducting business the way they always have. For example, nearly all the rest of the world has moved to embrace git. But you guys say it is not desirable. Well, if I was thinking of joining the effort this position would make me think more than twice. (Moving to use git would help make the project look fresh and alive.)

Indeed and FPC could also include the bugtracker in git as other projects do and patches can easily be created as merge-req where devs can directly comment on code lines, syntax problems, other ideas, etc.
Like you do nowadays in 2019
Sometimes you have to break old habits and start over using more modern concepts

A second reason you may not be getting the help you need is the project looks very wobbly. Many comments made over the years make it look like it is barely getting by, "living of a shoestring", and therefore may be shut down soon. No one wants to join such an effort. (Updating the web site so the project looks successful and alive would help with this a lot!)

You could also host a fresh website via github which could maintained by everyone through commits for spelling errors etc.
That would pretty awesome! 
But seems FPC/Lazarus likes it more to be the monthly #1 on a dead website...

A third reason you may not be getting the help you need may be because the image of the group is that a small number of principals control nearly all of the project. Without more transparency of process it looks like a tight circle that is hard to break into and not friendly to outsiders. This is where having someone coordinate who is good at explaining what is going on would help enormously.

That's true, sometimes the tone is very harsh to new contributors in my eyes.
Most of them will just disappear and join another community where the old devs are more warmly and welcome everyone with respectful tone.

[marcov]

You could also host a fresh website via github which could maintained by everyone through commits for spelling errors etc.

Any self-respecting non American large project stays away from github (the site and its hosting, not necessarily running the services yourself) because of legal aspects.

So that will never happen. Git and github are totally unrelated discussions, and the "I already have a github account" argument is useless.

[Martin_fr]

Indeed and FPC could also include the bugtracker in git as other projects do and patches can easily be created as merge-req where devs can directly comment on code lines, syntax problems, other ideas, etc.
Like you do nowadays in 2019

Personally, I am a git fan. But the bugtrackers on githup/lab... not my cup of tea.

[skalogryz]

Indeed and FPC could also include the bugtracker in git as other projects do and patches can easily be created as merge-req where devs can directly comment on code lines, syntax problems, other ideas, etc.
Like you do nowadays in 2019

Personally, I am a git fan. But the bugtrackers on githup/lab... not my cup of tea.

Let's face the fact. The Foundation doesn't really influence the management of neither FPC, nor Lazarus projects.
The Foundation can only choose the repository for the projects its funding.

And thus:

Git and github are totally unrelated discussions.

+1

[Bitbeisser]

I can speak for the foundation.

It is correct that the foundation website is the least of our priorities.
Despite asking several times for volunteers, so far no-one has stepped forward to actually do the work of creating a nice-looking website. I am not a designer of websites.

But we're definitely actively working on the progress of FPC/Lazarus
...
If you need more transparancy: ask, and you will get answers. There are plenty of invitations to contact us. It's up to you to do so.

Well, Michael, with all respect (I "know" and appreciate you and most of the others for up to 25 years by now), I think as far as the "Foundation web site" is concerned, it is a typical case of "information over presentation". Even a simple but regular "blog style" entry on a "news" section, with a date and the full name of the person posting would be sufficient.
There are no bylaws posted (not even in Dutch) but at least the foundation memorandum lists a financial report needs to be published with in 6 months of the end of the fiscal year, and there is stated at least in two different places that

The foundation will publish the accountancy report at the end of the first three months of 2019 or earlier if possible.

In two days, it is July 2019, that's another 3 months past that.

I hate accounting myself and much rather spend time programming or other technical stuff, but paying a bit more detail on the transparency when money is involved serves only to cover your own butts in case someone would get really pissed...

Ralf

[PascalDragon]

The most recent patch for attributes was "assigned" to Sven Barth over a year ago on the bugtracker:
https://bugs.freepascal.org/view.php?id=33384

Since then, there's been nothing but radio silence on the subject.

So? I'm not getting payed by anyone for my work and in fact I don't want to. I'm working on FPC on my own free time when I feel like it. Getting payed for it (especially with specific goals) puts me under pressure. I already have that at work, I don't need that at my free time as well.

One is the rigidity the principle participants have about conducting business the way they always have. For example, nearly all the rest of the world has moved to embrace git. But you guys say it is not desirable. Well, if I was thinking of joining the effort this position would make me think more than twice. (Moving to use git would help make the project look fresh and alive.)

Indeed and FPC could also include the bugtracker in git as other projects do and patches can easily be created as merge-req where devs can directly comment on code lines, syntax problems, other ideas, etc.
Like you do nowadays in 2019
Sometimes you have to break old habits and start over using more modern concepts

Changing the repository doesn't change the fact that patches, especially larger ones that introduce new features need to be carefully groomed and tested. A developer needs to apply them to their own, local checkout anyway to test them, to ensure that nothing broke. That is not something that would change by "using more modern concepts" and that is in fact the bulk of the work.

- We agreed with Karoly Balogh (Charlie) that he will be working on WebAssembly fulltime this summer.
  There is still an outstanding bounty for this.

Good to know, then I can cross that off my infernal todo list 

[ssliackus]

Probably I could help a little bit, but not sure what could I do for you. My skill and experience are not related to programming, project management, development or anything. I am an accountant, so there is little use of me.

Maybe you don't know but there are very few people that are working on all of this stuff.
We have a lot to do. I will make a list of all activities I do on the several sites.
Because I forgot about the Foundation, it is me to blame. I will  finalize the administration next week, so it will b up to date. I had started it but not finalized.
Sometimes one needs to do urgent things first.

People that have a lot of comments should come and help us to fulfill all of our tasks. PLEASE COME AND HELP.
If your interested simply send an email to me:
Detlef Overbeek = editor @ blaisepascal.eu or send it to: foundation @ freepascal.org or to professionals @ lazarusfactory.org

For all we do the development of FPC, Lazarus,pas2JS, Web-assembly, all the websites and writing and publish the books: Lazarus Handbook, Learning to program Lazarus and Blaise Pascal Magazine.
I have 100% daytime/nighttime job because of this, so if you have any questions please send them to me directly and I will answer instantly.

[greymont]

No, they don't. This is a ludicrous statement to make.

OK, there are plenty of exceptions. But let's not get caught in the weeds.

I think @marcov simply meant that some people will not want to jump completely into the git universe even though they might like git itself. So he overstated the situation. Let's move on.

[Akira1364]

OK, there are plenty of exceptions. But let's not get caught in the weeds.

I think @marcov simply meant that some people will not want to jump completely into the git universe even though they might like git itself. So he overstated the situation. Let's move on.

Honestly, I'd say it is more like "there is almost nothing but exceptions, and SVN is an objectively dying technology with no real benefits to speak of".

SVN is much slower. It's less reliable. And so on and so forth. There is a very real technical reason that major projects keep moving away from it, and it is not for any non-existent ideological purpose. It is because Git is objectively better technology with far more to offer.

[lucamar]

It is because Git is objectively better technology with far more to offer.

That is simply not true. At all. Git is a different technology with its strengths and its weakness, like any technology. Doing standard, central version control with Git, compared to SVN, is a nightmare and doubles the work load for all, developers, maintainers and admins, alike.

Whether a central or distributed version control system is best for a project depends on lots of variables and Gt doesn't always comes out as "the better", even technically.

And we are now way out of topic. Sorry

[k1ng]

You could also host a fresh website via github which could maintained by everyone through commits for spelling errors etc.

Any non American large project stays away from github (the site, not necessarily running the serves yourself) because of legal aspects.

Sorry but you're talking bullshit! Seems to me you never browsed on the github webpage...
And to be honest, I wouldn't call FPC a large project with the few contributions compared to other real large projects.

You could also host a fresh website via github which could maintained by everyone through commits for spelling errors etc.

So that will never happen. Git and github are totally unrelated discussions, and the "I already have a github argument" is useless.

Even if you personally don't like github, its the #1 and used for ~95% of every open source project. Gitea/Gitlab can be hosted yourself but its not that popular as Github and will never be.

The most recent patch for attributes was "assigned" to Sven Barth over a year ago on the bugtracker:
https://bugs.freepascal.org/view.php?id=33384

Since then, there's been nothing but radio silence on the subject.

So? I'm not getting payed by anyone for my work and in fact I don't want to. I'm working on FPC on my own free time when I feel like it. Getting payed for it (especially with specific goals) puts me under pressure. I already have that at work, I don't need that at my free time as well.

One is the rigidity the principle participants have about conducting business the way they always have. For example, nearly all the rest of the world has moved to embrace git. But you guys say it is not desirable. Well, if I was thinking of joining the effort this position would make me think more than twice. (Moving to use git would help make the project look fresh and alive.)

Indeed and FPC could also include the bugtracker in git as other projects do and patches can easily be created as merge-req where devs can directly comment on code lines, syntax problems, other ideas, etc.
Like you do nowadays in 2019
Sometimes you have to break old habits and start over using more modern concepts

Changing the repository doesn't change the fact that patches, especially larger ones that introduce new features need to be carefully groomed and tested. A developer needs to apply them to their own, local checkout anyway to test them, to ensure that nothing broke. That is not something that would change by "using more modern concepts" and that is in fact the bulk of the work.

That also sounds like year 2000.
Compilers should have tests (as FPC has afaik) which should be executed after every commit to see if something is broken. Very easy with e.g. Travis CI to run tests on x targets or you install a set of own servers to run the tests.
This does also work for merge requests on github, no need to test everything locally if this setup has been done once. Just check in merge request if compiling/tests passed, also very helpful for new contributors which might break a thing even without noticing as you cannot setup 30 different targets at home just for one single commit....

[PascalDragon]

SVN is much slower. It's less reliable. And so on and so forth. There is a very real technical reason that major projects keep moving away from it, and it is not for any non-existent ideological purpose. It is because Git is objectively better technology with far more to offer.

Git does not provide externals to files (we use that feature at work), sub module handling is also more complicated than SVN externals. Shallow checkouts are also unheard of (those where you checkout only some directories, not the ones with reduced history; I know Git supports those). The latter two features are used by some of FPC's infrastructure (automatic testsuite runs, release generation). Also the workflow we use for compiler development is not as nicely useable on Git as it is on SVN (and we do prefer a linear history, though we've already found solutions for that).

So yes, Git has advantages (and I use Git with FPC through git-svn myself), but it also has disadvantages. Switching a version control system is neither an easy decision nor task as there are mechanisms that rely on it. We are researching it, but we are under no pressure to do it "right now, like 5 days ago".

You could also host a fresh website via github which could maintained by everyone through commits for spelling errors etc.

So that will never happen. Git and github are totally unrelated discussions, and the "I already have a github argument" is useless.

Even if you personally don't like github, its the #1 and used for ~95% of every open source project. Gitea/Gitlab can be hosted yourself but its not that popular as Github and will never be.

We've already decided that if we should switch to Git that our main repository will be a Gitea repository on one of the servers owned by the FPC development team. Github will get a mirror, but that's it.

The most recent patch for attributes was "assigned" to Sven Barth over a year ago on the bugtracker:
https://bugs.freepascal.org/view.php?id=33384

Since then, there's been nothing but radio silence on the subject.

So? I'm not getting payed by anyone for my work and in fact I don't want to. I'm working on FPC on my own free time when I feel like it. Getting payed for it (especially with specific goals) puts me under pressure. I already have that at work, I don't need that at my free time as well.

One is the rigidity the principle participants have about conducting business the way they always have. For example, nearly all the rest of the world has moved to embrace git. But you guys say it is not desirable. Well, if I was thinking of joining the effort this position would make me think more than twice. (Moving to use git would help make the project look fresh and alive.)

Indeed and FPC could also include the bugtracker in git as other projects do and patches can easily be created as merge-req where devs can directly comment on code lines, syntax problems, other ideas, etc.
Like you do nowadays in 2019
Sometimes you have to break old habits and start over using more modern concepts

Changing the repository doesn't change the fact that patches, especially larger ones that introduce new features need to be carefully groomed and tested. A developer needs to apply them to their own, local checkout anyway to test them, to ensure that nothing broke. That is not something that would change by "using more modern concepts" and that is in fact the bulk of the work.

That also sounds like year 2000.
Compilers should have tests (as FPC has afaik) which should be executed after every commit to see if something is broken. Very easy with e.g. Travis CI to run tests on x targets or you install a set of own servers to run the tests.
This does also work for merge requests on github, no need to test everything locally if this setup has been done once. Just check in merge request if compiling/tests passed, also very helpful for new contributors which might break a thing even without noticing as you cannot setup 30 different targets at home just for one single commit....

This hasn't necessarily to do with some patch breaking the build. This has also to do with finding out whether the developer of the patch has thought of all potential problems that might arise. There were often patches in the past where a new feature could be easily broken or where the developers decided to use an approach that was unmaintainable in the long run and thus should be rewritten. Only because a patch compiles and does not break the testsuite does not mean that it's good.
Also we have both nightly test suite runs as well as some systems that do continous integration (mainly to detect compilation errors for the more seldom developed targets like the Amiga family). Running the testsuite takes time (on current x86 systems it's rather quick with a few minutes, but on less powerful targets it can take an hour or longer), so running it on each commit is not necessarily feasable for all targets.

[marcov]

The whole pro git discussion is pointless. An inquiry was done in early 2018, and nearly directly release branch management was the problem point.

Over christmas the discussion started again, and it seems the majority of FPC seem to wanti git actually, but somehow solutions are slow coming (or are weak like "separate software has to be written for that"). Nearly anything that is a oneline in SVN is suddenly a separate script(*) in git, and requires workarounds like stuffing metadata in commit messages. THOSE hack SOLUTIONS IS WHY WE FLED FROM CVS, IT IS GOING BACKWARDS  !

Note that the GIT vs SVN factions are nearly 100% split over compiler vs other devs, with the exception of Michael whose employer uses GIT already.

If you want to promote git, come up with workflow solutions for release and stable branch management somewhat equal, because that what the migration is hinging on for 1.5 years now.

p.s. Personally I favor staying with SVN, simply because it works, and because I think the migration and solving the problems git outweigh the fairly minor benefits. And yes, if I started a new project I would probably chose GIT. But for many things we already have its advantages via the SVN+GIT bridge, and I don't want the project taking a sabbatical year to recover from a VCS migration

The fact that popularity arguments have to be made to cover up that GIT is so deficient in the current situation, and that it can't simply win on merits (even after people studying 2 years on the issue of those release branches) is IMHO telling. It is simply not versatile enough, too much a "my way or the highway" philosophy.

And the popularity arguments, like the language feature ones, never deliver on their promises. The big unwashed masses never come because of such changes, it is all hot air.

Like many of the propose language features: solutions in search of a problem

(*) and scripts are problems, since FPC is not an *nix only project, and everything has to work on multiple systems. And no, requiring a mingw install for *nix scripting emulation is not acceptable.

[k1ng]

Over christmas the discussion started again, and it seems the majority of FPC seem to wanti git actually, but somehow solutions are slow coming (or are weak like "separate software has to be written for that"). Nearly anything that is a oneline in SVN is suddenly a separate script(*) in git, and requires workarounds like stuffing metadata in commit messages.

(*) and scripts are problems, since FPC is not an *nix only project, and everything has to work on multiple systems. And no, requiring a mingw install for *nix scripting emulation is not acceptable.

Can you give an example?
Why not writing the "script" in FPC or bash+batch?

If you want to promote git, come up with workflow solutions for release and stable branch management somewhat equal, because that what the migration is hinging on for 1.5 years now.

Where is the problem?
Use master branch as trunk, fork it into a beta-branch for a new version which then gets forked into release-branch when its finished.

[ssliackus]

Yes, I didn't realise these three exist.

I do not thinks it is good thing to include donation in book price.
First of all, it makes book to be more expensive, therefore it will be less affordable for some.
Second, not all who are willing to donate, would like to buy a book (ok, these can do this), but those who want just to buy a book, must donate. That is not very right.

I would keep those to separate. Authors would still have an option to donate if they want from their profits, not from sales revenue.