Greetings and Salutations! ------------------------------------------------------------------------ Table of Contents ------------------------------------------------------------------------
- Editors Notes - Midgard -- A Review - Midgard Website Maintenance - MidCOM Status Summary - Asgard 1.4.3b released - Bugtracker Summary / Bug Squashing Roadmap - Mailinglist Summary ------------------------------------------------------------------------ Editors Notes From: Torben Nehmer <[EMAIL PROTECTED]> ------------------------------------------------------------------------ This issue of the MWS is a little different: I would like to try to build a summary of where Midgard currently stands in the CMS world, what happened over the last year or so, and where our future priorities should lie - form my point of view at least. Apart from this there are some more administrative points like Bug Squashing policies. ------------------------------------------------------------------------ Midgard -- A Review From: Torben Nehmer <[EMAIL PROTECTED]> ------------------------------------------------------------------------ I wanted to give you some update about where I have tried to move Midgard in the last few months. I assume that you know a good deal of that already, but I feel responsible to share a few thoughts that came to me during that time. Please consider this not as a roadmap but as some personal notes from a Midgard Developer, Midgard User, Midgard Supporter and Web Project Manager: What I'm primarily trying to accomplish is to get Midgard really ready for business. Midgard is strong, even if we consider all the legacies we are towing with us. But I see two major problems that keep Midgard from gaining the acceptance it could have: Documentation and Quality. (Yes, I know that many of you know that :)). The Documentation of Midgard is rudimentary at best. We have a API Reference which is inaccurate and incomplete as well as a generic overview of Midgard. The code documentation itself is rudimentary at the same time there is nosource where a new developer can read for himself how Midgard really works. This is a major obstacle for newcomers to the project. Philipp Rotmann has already started updating the API Reference and what I saw, up to this point, looks really good. But we need more: Most important, considering the questions that are often asked on midgard-user, a couple of tutorials are necessary as soon as possible. Additionally, those who know how Midgard works should start to document the code (just do regular comments in the C-Files) and put together an �Overview� of the interaction of the parts. If the overview existed, then the better writers among us could take this up and make some kind of Developers Manual out of it. Anybody who has a little bit experience in writing is welcome to write documentation about Midgard. Everything 'How-To's, Tutorials, even short notes is welcome. The ultimate goal in my eyes would be a single person who could coordinate all those efforts; we need a style-guide, a central repository for the documentation and if possible a single tool that manages all docs. (LaTeX, DocBook ...) Now we come to the really interesting part: Quality. From what I remember from the Linux Tag 2001, the Mailing lists, some personal requests and personal experience this is a far greater problem than anything else. These issue include, with no claim to completeness: Midgard's biggest problem is the consistency of the programming interface. Considering the number of functions and the incomplete or inaccurate documentation this is a mammoth task. We have already started with it, some changes in 1.4.3 reflect this, and there are already another couple of API change requests delayed for 1.5. Looking back I feel we are a lot better now, but we should focus on this for 1.5. Only with a stable and useful API we can promote Midgard as easy-to-use CMS System. I think that we are on the right track here, but it will definitely take some time. Further on, if we start to stabilize the automatic package building processes, we need regression testing. Too many avoidable bugs have made their way into CVS in the last two years. This is a big job if we want to pull it of, but I think it will pay off in shorter release cycles and improved backwards compatibility since we have a defined set of functions that are guaranteed to work. Also, we lack Packages for the current major distributions, which makes Midgard Maintenance a time-consuming task. We have made progress in this respect, Debian and Red Hat packages can be built with relative ease by now, but we are missing packages for the German SuSE Distribution, which is quite wide-spread here. Effective package management would mean much less trouble when updating Midgard. With a little bit luck this problem should be solved for Debian and Redhat in a couple of months from now on (perhaps next January?). As for SuSE, we do not have any experts around that could build those packages... One last thing was often ignored in the last months: Performance. Yes I know, I can buy a faster server. But there are limits. Our hosting server currently hosts something around five Midgard Websites, one of them already featuring MidCOM, and if one of those sites would really start to generate traffic we might get into trouble. Main reason for that is not Midgard, but PHP. As the number and complexity of Midgard applications increase, however, so will the performance lag. I'm not even aiming at highly interactive sites here, which tend to require even more powerful hardware. Our target audience, medium complex Websites of companies want to start to use component-oriented software. MidCOM is only one example here. MMP is only part of a solution, since it cannot cache such things that most of the time make use of Snippets. We haven�t really discussed this moch over the last few months but should begin to think more about performance. I have some proposals here, which I will post to @dev when I get around to it (in a couple of weeks probably). Summing up all those things I can see that Midgard starts to mature away from a pet-project to a full fledged Web CMS System. Initiatives like (in alphabetical order) Aegir, Asgard 1.4.3, MidCOM and SpiderAdmin definitely prove that Midgard can be more. If we concentrate on getting the above problems under control, I'm sure, that Midgard could give some people real headaches when it starts to fire away. ------------------------------------------------------------------------ Midgard Website Maintenance From: Torben Nehmer <[EMAIL PROTECTED]> ------------------------------------------------------------------------ The Midgard Website has begun to stagnate over the last few months. There seems to be no one who is directly responsible in coordinating the Website and bringing new topics online. What we need is someone who takes over the lead here, someone who has no problem stepping on the toes of other if he needs content. I, for example, like writing articles like this one very much, but I don't have the time in putting it to the Website in a form that really looks good. If anybody out there with enough experience to effectively use Midgard would like to blow some wind into the existing Website, tell us on the dev-list [1]. I suspect that you will be welcomed with open arms. [1]: mailto:dev@;midgard-project.org ------------------------------------------------------------------------ MidCOM Status Summary From: Torben Nehmer <[EMAIL PROTECTED]> ------------------------------------------------------------------------ MidCOM is quite good underway. The very first MidCOM driven Website is already live [2] and it works quite well. Unfortunately I wasn't able to fire out a new alpha release, partly because I'm under a lot pressure with other large projects. Our current internal roadmap features the Administration Site Infrastructure for Mid-November, when IMMA-Project is finally complete. This is an absolute deadline, so this is one of Midgard's timelines that actually have a good chance of being met. After that is complete MidCOM will be able to build up a complete Website from components including a sophisticated Admin Site Builder that matches exactly the structure of the Website. A Control Panel System allows me to introduce new system services step by step. And - oh wonder - the documentation about the whole system is fairly complete even as I write this. There is one problem though, MidCOM is slow, Really slow. On a 800 MHz Athlon Server the average MidCOM request currently takes something around 650 ms to complete, which is not reasonable in my opinion. To address this problem the next step in MidCOM evolution will be a sophisticated caching system: MidCOM will store the HTML Output of a given URL request to serve it to other clients -- if the cache copy hasn't been invalidated in the meantime. The concept is not fully thought-through yet, but has it nears completion, I will introduce it to you as soon as there is some proof of concept that it works. So much for now: With a little bit of luck we could get away with a database request and a few lines of PHP code that finally include an HTML file of the hard disk and a caching strategy that works for most conventional Websites. See a more or less draft of the MidCOM specification at [3] and the download of the current version at [4]. Be aware thought, that the current package is not production stable and that the import might reset your SG0 Admin Password... [2]: http://www.imma.de (German language only) [3]: http://www.nathan-syntronics.de/midgard/docs/midcom.html [4]: http://users.nehmer.net/~classic/MidCOM-0.2.2.tar.bz2 ------------------------------------------------------------------------ Asgard 1.4.3b released From: Matthias Englert <[EMAIL PROTECTED]> Editor: Torben Nehmer <[EMAIL PROTECTED]> ------------------------------------------------------------------------ Matthias has release a small update to Asgard. The "b" doesn't stand for "Beta" by the way... Its only notable change is a patch from Francois Deppierraz, which replaces the gif images with PNGs. The current version can be obtained here [5]. The Website [6] is not yet updated, but it should happen soon according to Matthias. [5] http://asgard.midgard-project.org/asgard-1.4.3.b.tar.gz [6] http://asgard.midgard-project.org/ ------------------------------------------------------------------------ Bugtracker Summary / Bug Squashing Roadmap Editor: Torben Nehmer <[EMAIL PROTECTED]> ------------------------------------------------------------------------ There was a single new bug this week concerning the Workings of the :f formatter. It has to be investigated. [7] One bug was fixed during the last week in the 1.4.3 CVS tree: Repligard now correctly leaves the changed-timestamps alone when exporting. [8] See the Bugtracker [9] for more details. More important: I finally came around to sort and prioritize the bugs in the Bugtracker which paves the road for Midgard 1.4.4 Bug Squashing: There are two broad categories: Urgent and High Prioritized Bugs. The former are necessary for 1.4.4, while the latter would be nice-to-have. You can distinguish them by the two up-arrows for urgent and the single up-arrow for high prioritized Bugs. Besides this the bugs are sorted into "Confirmed" and "Acknowledged" Bugs. The Confirmed Bugs have been reproduced by me, and they usually should have enough information to reproduce it again. The "Acknowledged" ones on the other hand are reported but uncertain. For all developers out there: Please work first on the Urgent Bugs I have sorted out, beginning with the most severe ones. If you decide to work on a bug, Assign it to yourself so that the others see that somebody is already working on it. Commit the changes into the CVS Branch "release-1_4_3-branch" for that. I will backport them into the main trunk later. [7]: Bug #220 [8]: Bug #56 [9]: http://bugs.midgard-project.org/ ------------------------------------------------------------------------ Mailinglist Summary Editor: Torben Nehmer <[EMAIL PROTECTED]> ------------------------------------------------------------------------ There was a discussion about whether to promote primarily binary packages on the Website on both midgard-user and midgard-dev. We came to no real conclusion yet, but since the tarball gets out first, it will probably stay as the primary download for quite a while. More interesting are the discussions about what to do with -data which were spread over several thread in details of the original discussion. We all know that we need a friendlier way to manage Midgard Databases. The most probable solution currently looks like an application distributed with midgard-lib which manages the DBs itself and which provides an automated Repligard Interface to them, perhaps with an apt-get like structure for Admin Site Downloads. ------------------------------------------------------------------------ Want to continue reading MWS? Please help us create this newsletter. Currently, it's mostly a one-man show, which is anticipated to fail in the long term. We urgently need volunteer writers who prepare items. Please see the contributing page to find out how to help. We're looking forward to receiving your mail at [10]. Midgard is an Open Source Content Management System, visit our Homepage [11] for further Information. [10]: [EMAIL PROTECTED] [11]: http://www.midgard-project.org Live long and prosper! Torben Nehmer -- Torben Nehmer, Munich, Germany http://www.nathan-syntronics.de, mailto:torben@;nehmer.net PGP Public Key: https://www.link-m.de/pgp/t.nehmer.asc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
