After beginning to use Lazarus more and more I there a few things I want to write about. I can't say I have studied its workings well enough, or asked around enough. Perhaps there are solutions to the issues, or there are reasons for their being the way they are, but I feel I must raise them all the same. I am welcome to any corrections or criticisms.
Does new FCL functionality need to depend on 2.5.1 compiler or LCL/IDE features?
The first point I want to raise is the matter of the FCL, the LCL and the Lazarus IDE.
From what I understand the FCL is code which is independent of Lazarus object/component model and the LCL as well.
I find that new functionality is going into FPC 2.5.1 FCL and Lazarus 0.9.29 and I wonder whether that functionality is dependent on new features of FPC in 2.5.1 or is it mainly because the developer is using Lazarus 0.9.29 which depends on 2.5.1.
If the source will work with 2.2.4 or 2.4.0 then why force a needless upgrade to 2.5.1 with all the hassles involved with compiling from SVN?
It also means that the code may develop needless dependencies on other 2.5.1 library code instead of being abstracted out properly, and it cause more problems down the line. My pet peeves here are fcl-web and fcl-xml. They are the ones that made upgrading to 2.5.1 a must for me. Anyone who finds my build scripts useful has them to thank for it. :) I am sure they will be joined by a few other libraries soon!!
In relation to this issue I asked if there is an easy way to compile the libraries from the same source directory, but configure the IDEs to place the unit output in their own folders. I hope with judicious use of macros this is be possible.
Does fpc 2.5.1 / Lazarus 0.9.29 miss support from users of earlier versions, because of lack of interest?
Another aspect to this is the ability to create components at runtime and set all the properties with code.
Support for creating some objects and setting their properties in the IDE may be present in Lazarus 0.9.29, but not in 0.9.28, but if the same objects can be created and have their properties set at runtime in source code, should they be limited to 0.9.29 users?
This issue is probably just as applicable to 0.9.26 and 0.9.28 code, because a lot of features properties that can't be set at design time can be done in code at runtime, and lack of code examples means they can't be used.
Perhaps a stronger emphasis on creating code, rather than GUI will help new users and teach them a lot of more, and this will create a strong foundation for future versions.
I also think it creates a situation where the developers of 0.9.29 and fpc 2.5.1 may not be getting support from users of earlier versions because those users feel satisfied with what they've got and think they have nothing to contribute to something they feel they have no use for, although they are in a good position to.
Obtaining pertinent info from Roadmap, Feature List, Subversion
When you look at the Lazarus Snapshots page, you see that both 0.9.29 and 0.9.28 are listed with the same revision, without even knowning whether the last 50 or so revisions had any bearing on the 0.9.28 as most of the current updates are on 0.9.29.
Is there some svn tool which can help you check what updates were made to what the version you are working with? Some project managers, like Redmine, enable you attach an issue number to a commit, something like that would help a lot. Even though right now I will be using lazarus-svn, I don't know at all if any upgrade I make contains stuff relevant to my needs, or may even break something that already works.
Make it easier for smart drive by contributors - the majority of the smart guys work for the competition
I am using Lazarus and I want to contribute whatever little I can make time for, but I can't as much as I want to, because it takes me too much time to find the information I need. By the time I get going with it, I have already blown my time budget and cannot make the time to contribute.
There are lot of smart guys out there (sadly I am not one of them), most of them Delphi developers who could probably contribute a lot to the FPC libraries.
But if finding the information takes too much time they will loose interest and give up. Lazarus/FPC must support people who have a few hours every week at evenings and weekends to contribute what they can.
A person may be an expert in some arcane area in maths or computer algorithms which can make a lot of difference. With the necessary info she can organize it in her head and get done in 30 minutes, but if will take her weeks to find out what she needs to implement it, its not going to happen. I think Lazarus misses a lot from such people. ( I have to be more than gender neutral here, I am sure there a number of female Lazarus programmers out there - hint, hint)
Another point is support for bug fixing. When a bug is reported the usual response is to create a test case and file a bug report on Mantis.
Could the reponse be extended to this:
If you are okay with debugging the IDE fire up a debug/development image on Amazon EC2 and update to the latest svn. I suspect the offending code may be found hereabouts in the source. Check it and send us your report.
This would save the time of lead developers who may not have enough time and free them to focus on more important areas.
I think something like this can go a long way into speeding up the development process, and it can be very time effective. I don't have Linux on my local workstation and I pressganged a mostly idle Linode into Linux development. If I used an EC2 image for a few hours every week, I would probably get more CPU and RAM for an even lower monthly price.
This is an area which has been criticized to death. I am not going to make any more critical comments, only a suggestion on how it may be improved.
Say we create a document outline, chapter, content, headings, subsections etc, all laid out. Instead of adding an article (perhaps lead developers and experts in that area may have permission to create articles directly), a contributor creates a link to a page on the topic on his own webspace somewhere, even on some community provided space, properly formatted of course, with strict rules on structure, perhaps DocBook or subset of it.
Regular users read it, vote, criticise it, point out errors etc suggest improvements etc. It gets voted up, voted down, ranked etc. Reasons must be giving for voting down.
Someone can take an existing article and rewrite it (with proper attribution of course). It may be possible for an individual to contribute multiple articles on the same topic.
Of course nothing gets deleted, good articles rise, outdated or poor articles sink. The community can then create 'Official' documents out of the best articles, turn it into a PDF, printed paper, whatever.
Off course it is all there, if anyone wants to create his own manual out of the stuff there, including stuff that did not make it into the 'Official' docs, fine, because it is all coerced into an organised machine readable form from day one.
The key thing is not a few people spreading their effort across different areas, but many people each specializing in an area and doing it well.
Users can even have their preferred versions by tagging their preferred articles when they log in.
Web Tools for Documentation in FreePascal
A lot of the more popular web programming tools, like Python, Ruby etc seem to have good documentation tools because most of their users program for the web, whereas Pascal was around and doing lots of different things and the focus for Lazarus for the web is not so good.
Having to go through a compile-debug-edit cycle causes FPC/Lazarus to suffer here, and the web libraries are not well documented. Some interpreted embeddable language like Python or Ruby with Lazarus would go along way.
I have seen Python4Delphi on code.google.com but apparently it is languishing because because of lack of support for custom variants.
Is Pascal Script good substitute for Lua/Python/Ruby or is it hampered by strong typing?
I am feeling lagged now, and don't have much to add now
In the final analysis it comes down to making it easy to get new users up to speed, and that means examples and documentation, so they in turn can finish up on good time and contribute back to the project.
I hope I have the ears of the great and the good of the FPC community in this matter and we can all work together into getting things going faster.