Release of the GM code

I was thinking about the previous regime of Greymatter support and how we could make it better. In the past a few individuals have collected mods/bugs and decided what would be included in a release. This led to very long gaps between releases and very few releases.

I favour a more open source approach. It would be better to release more times and more often. A major release with great new features could be released at longer intervals.

My thoughts were to add fixes for bugs small mods (any mod should be included in the core with the ability to not use it or we need a plug-in mechanism to allow all mods to follow the same format and to make it easier to include mods at runtime instead of the current mod process that means editing code to instructions on forum posts)

So why dont we have a stable release and a candidate release that includes the latest fixes. These should go up as 3rd point releases – i.e. 1.3.1 to 1.3.2 and we should have a major release on a longer schedule. The point releases would be available as soon as fixed code is added or small mods are included and would be available as a candidate release for all to download and test. As soon as its agreed its stable it would become the stable release and so on. The advantage is that everyone gets fixes straight away and more people test the bug fixes and new features.

Just some thoughts. What is everyone elses view???

A modular mod system (or plugin, if you will) is something I would like to see (as well as modular themes).

I like the idea of regular releases, but wouldn’t want to do too many, too often (I think people would get tired of upgrady all the time (like me )) However, maybe we can plan on quarterly releases with security fixes as needed?

Also, I am trying to find a project host for us (with cvs, bug tracking, etc.). I am still looking and seeing if we qualify for sourceforge, otherwise, I have a list of potential free hosts.

I also like the idea of plugins and themes. Great!

On the release cycle, I think its a case of upgrade when you want to. If the code tree has small fixes and we release often people do not need to upgrade. They can wait a few releases unless there is a serious security fix to take care of. I like the idea of a stable release and a release with new fixes / mods / features that is available to everyone for testing. A debug release if you will.

I would like to hear others opinions as well

I wanted to come back to the question of updating the code of GM, how often we should release and how many updates per release. I am still edging towards shorter release times and smaller updates.

I have spent quite a bit of time going through the code trying to understand its structure and one thing that strikes me immediatly is the problem for multiple people to update the code at the same time as its very monolithic and not modular.

This sort of backs up my suggestion to fix small amounts and release regularly at least until the code is tidied. I personally have a few fixes in my running versions of GM and for me it would make sense to update to 1.3.2 and release these.

I would like to see the code tidied in terms of style. The code is not easy to read as some is indented and some not and some indented differently. A clean consitent style would make sense to release quickly.

Then it would make sense to seperate various groups of functions to differeent files. For instance seperating search and comments, then a bigger task would be to split up gm-library into multiple files that support dedicated features.

Then as discussed before seperate out the access layers. In having a cleaner style and more modularity it would be easier for multiple people to work on the code at the same time.

For me, code style doesn’t really do much for functionality or even ability to modify. I have worked on projects with varying styles and the thing that I found to be the most usefull with multiple developers are good comments (usually what the method does, what arguments it takes, what it returns, and how to use it).

The thing I see with GM is that it doesn’t protect variables and its amazing there hasn’t been a name collision with variables. When I add new code, I always use ‘my’.

Functions always return values (unlike many gm functions, e.g. date, where the function is called and then the date variables are used through the code).

I agree that breaking the code out into other files is a good idea. The thing I also am trying to address where I can is that alot of code is copied, rather than a function written. There is alot of if … elseif … else that can be written as a function that is used.

Currently on my local development Gm, I have broken the code out into modules in a ‘libs’ directory. Here are the current libraries that I have:

 

• Gm_Storage (all the file access is being moved here)
• Gm_Web (contains util functions specific to the web
• Gm_Util (contains non-core util functions such as date, delouse, etc.)
• Gm_Core (will contain the core functions such as template replaceing, etc.)

I am sure there could be more, but thats what I have for now. I would also like to move admin screen stuff to the gm.cgi script, since I would like to see the cgi specifc functionality in the cgi scripts.

A last note on the line identing thing, its alot easier to fix with programs like UltraEdit and TextWrangler that lets you ident blocks of text. It seems like everyone has pet peeves as far as coding style goes, and it seems like it can be a touchy subject (I had someone delete some of my code out of our cvs repository at one job because I didn’t follow his formatting style. Ironically enough, we were using JBuilder, which lets you modify the format of an entire file with one mouse click, so it was easily changed. Oh well.).

Thanks for your comments. I forgot to mention this one. you spotted it as well. the 11,000 line file could be smaller if it were modular and used functions. There is quite a lot of repetition as you point out.

I am not a luddite on styles, I dont really care which style is used as long as its consistent. I agree totally comments are needed. I also noticed this issue. I am also with you on namespace collisions and functions returning values.

I will be on site for the next couple of days but late this week I will report back on progress on the comment moderation mod.

Sorry I have been “off-line” for the last week or so working on site and also took some hols.

I have made progress writing comments to a queue and I am creating the admin page for the queue management. I am doing this by adding another option in the admin interface to allow access to work the queue.

I have also been looking into catchpa’s – these are the graphics that have the word / letters / numbers for the commenter to add.

If anyone has details of any other comment mods I would be interested to see them to decide whether to include them in this mod.

In the future I was going to look at some plugins that friends of mine use with word press called ‘akismet’.

And then I was given some links by another acquantance:
http://codex.wordpress.org/Combating_Comment_Spam/Denying_Access
http://codex.wordpress.org/Plugins/Spam_Tools

While I am not saying we should implement these for GreyMatter, its something to think about and possibly inspire. I think spam moderation is still an issue even for sites like Popular Science (a U.S. mag that recently started using the image verification gimick).

Lastly, a friend pointed out that encoding all links with the ‘nofollow’ directive makes them useless to spammers as search engines won’t follow/count them. That might be something simple to put into urls.

I think the queue method will be extremely useful, just my personal opinion though.