I’ve been poking around a bit among reviews and experiences of users of SVN and Git.
And as it comes to me right now, it doesn’t seem such a bad idea that you work in SVN with Git bridge.
It’s a bit like like getting best of both worlds.
What I would advise however is to build Freepascal and Lazarus as modular as possible, both with a good workining package system for extentions. Pascal used to be great in this sense (proper compartmentalisation) so I suppose you guys have already accomplishes that.
You can try. There are multiple such efforts like fppkg and lazarus packagesmanager
Git seems great for smaller and more decentral projects like modules and extensions.
Current afaik they simply use zips, and leave the version system decision wholly to the packages maintainers themselves, rather than force something on them.
And the younger generations can be found more on git nowedays than on SVN. So you could stimulate the younger generation to work on those in Git.
The problem is that this is often small potato experience in relative small projects on github. This experience doesn't really translate to larger projects with some quality control. Catering too much for this difference will lower thresholds, but at the cost of procedures (and possibly quality), which will create an even bigger management problem in the central administration.
I therefore don't share the thought that advocating GIT changes so much. It is now overly focussed on because it is an easy target. The reality however, it is the problem between having procedures and standards for acceptance and not. That can't be washed away with technology.
FPC and Lazarus have always accepted contributions in patch format. You can just as well generate them from git if the quality of your repo's contents is enough. And if it isn't, the fact that both you and FPC use git isn't going to help either. It only changes the blame game to the next easy argument. (probably some procedure. Why don't you simply pull it from my git? A: because i wouldn't touch that shit with a bargepole because you reformatted everything)
And too much modularization will also create a support issue due to versioning. (at least now the release packages are forced synchronized)
That way you would keep the core into the hands of those who have been given the status of fullblown committers
and give the rest in the hands of the other devs.
So your goal could be to migrate modules and extensions that need a lot of extra development towards Git
and pull them into the core package on SVN as soon they are mature and are expected to need only limited future improvements
(off course taking into account whether you can also turn their committers into SVN proper committers)
This is a really bad idea. Package dependencies are not static, and some packages would have to move to and from the distribution. Having internal modularization is good, but the repos would need to remain linked.
And as you noted that “the GIT vs SVN factions are nearly 100% split over compiler vs other devs”,
it seems to me thsat my that solution would also please both faction in your community.
The compiler devs wanting GIT, and the target maintainers and RTL, FCL developers prefering SVN? (or at least not being in favor of the migration. You can still favor GIT and consider conversion and the subsequent lost year not worth it)
I would consider (if not already present) to give users of Freepascal and Lazarus the opportunity
to choose which hardware platform they which to support with their Pascal programming environment.
That way it will keep things lean.
What hardware problem? Users don't chose. They have to take what is there, or be developers. Most target maintainers started development that way (including me, wanting to run CGIs on my FreeBSD account and ending up porting FPC to FreeBSD)
Also I would start making a clear and timely difference between Planned Releases (LTS), Planned Updates on Releases and Unplanned (emergency) Updates/Fixes.
Release planning is very limited and very fluid in time. We have been trying to change this for about 20 years now, and it only gets worse :-)
(Releases having major improments, with less stress on backwards compatibility or even purposly breaking away off old hardware platforms etc.)
I don't really understand all this, but quite often fixes don't let them sort easily in multiple categories, simply because they are related. Also targets often lose support for older OS versions, so porting them back to the LTS versions of those targets is no longer possible.
(Updates on Releases having minor improments, with High stress on backwards compatibility compared to the original Release, no breakage allowed unless for security reasons)
Sometimes security fixes are done by Linux distros. But the number of incident is still low enough to not even have policy on this.
And off course try to put a time limit on it, taking in account what commitments people are willing to make promises on.
(I know this is a hard thing with volunteers but you have to strive to it noneteless, the moment you stop doiing that is the moment you start setting yourself up for a slow death of your project).
You simply won't get promises you can hold anybody too, which makes it pointless.
By better planning and communicating this planning, you enable users to plan and take timely action on their own code or hardware base. Thus creating a market environment for Pascal in which users are more able and willing to evolve their code confrming to the evolution path of Pascal.
If some users would start working on continuous releases and feed back info into the project (and maybe even become members over time) maybe something would happen here. The problem is that releasing is only a side task for most of the devs too, and to change anything, you would need a (more) continuous release manpower. It is the only way.
But with modularization, lazarus packagemanager, fpcdeluxe etc, this might grow organically over time. It would help if fpc and lazarus used the same package system for modularization internally, and externally, so that packages could move more fluid between them. But then first people must work on that, and grow it, and only then you can start the big redivide.
There is movement, but it is glacial.
This will enable Pascal to get rid off (archive) old code and get lean not only for users but also for its developers (you guys),
Not really. Most of such attempts miserably failed, because the users generally are not interested in maintaining, except for a few popular focal points. The few exceptions make developer anyway. So this is probably betting on manpower that simply is not there.
Which, as far as I can see with my limited knowlegde, seems very necesserry to give Pascal development more dynamics considering Pascal had a very slow pace of release over the last years, and does not seem to be able to keep up the pace in this ever faster chaging world, whith less and less programmers interested in maintaining age old platforms.
In my opinion it is betting the bank on some magical influx of devels, and requiring a lot of investment up front that will be mostly only have complicated things (and the work void) if that fails.
I've heard it many times, and the argument is flawed, simply because if those hordes were really out there, they would not be hampered by simple things like git vs svn, or some minor ease of use. They would simply get in touch and start working.
Note btw that the number of submissions for some of the retro platforms is higher than of many popular targets. Having old targets is not the problem, getting people to work on the new ones is.
Also I would advise to make the contributions to and the allocation of those donations by the foundation as transparent as possible.
At least present quarterly numbers on this website/forum, and create a donation page for do digital payments (once or automatic periodically), where people can see what budget is needed to realize certain projects (with links to detsailed info on these projectsl), and choose for which Pascal Project they donate their money.
That irks me somewhat too, that people donated for FPC/lazarus process, and it got invested in a new product, a standalone pas2js with own RTL/libs etc.
Also the foundation might consider starting to sell merchandise to fund things
(off course for that you need to have nerd and youngster friendly fashionable logo’s).
Works only for projects with very high visibility. And if we get major attendance from some major company, the mugs stuff would be the small potato.
Just the two pennies of an old fart, take it for what it’s worth.
They abolished cents in the Netherlands :-)
Seriously. Lots of open doors, and optimistic to extreme optimistic scenarios that are not really supported by fact (all IMHO of course)