I believe that adding blogging technology to bug tracking systems (such as the Debian BTS and the Red Hat Bugzilla) offers significant benefits for users and developers.

It seems that there is only one significant difference between the features offered by blog software and the features required by bug trackers, blog entries are owned by the person making the post (the owner of the blog) and BTS entries are owned by the package owner. This is a minor technical difference, adding the ability for anonymous users (or users who have authenticated via an email address or other method) to create new entries in a blog owned by someone else is a minor feature change. Once the entry is created only comments would be accepted, and comments could be made in the usual manner with moderation etc.

The benefits of using blogging software (or extending current BTS systems) would be to have RSS feeds of bug reports and comments on bugs, include a single feed of all bug reports (IE blog entries) and updates (IE comments on blog entries) for a single blog (IE package) – this functionality doesn’t seem to be common in blog software but surely will be soon.

This would allow Planets of recent bug reports in distributions or in areas. EG a SE Linux planet installation could syndicate the bug feeds for packages in Fedora and Debian as well as other sources of SE Linux information. The SE Linux bug feeds could include all bugs with the selinux tag in all blogs on the BTS, thus a single Planet configuration could easily cover all new development and debugging.

Another configuration possibility would be to have a single blog for all bugs in a distribution and to have tags for each package, this would become messy though as tags have to be used for issues that are not specific to packages (EG a “selinux” tag would list bugs in all packages that relate to SE Linux).

Tags could be changed by any user (possibly with some restrictions), and there could be special tags for release-critical bugs or for bugs in different stages of QA (for example the Red Hat Enterprise Linux approval process could be managed by adding certain restricted tags to the bug – this would also allow getting a feed of all bugs that have passed certain approval milestones). This would make it easy to get a list of all bugs in a certain approval category.

Current BTS systems such as the Debian BTS and the Red Hat Bugzilla could be extended to syndicate content. As they already have web interfaces and support automatically sending updates by email it should be easy to add the basic level of such support to them. But it might give a better result to go the other way and modify a multi-user blog system such as WordPress-MU to have extra features for bug management.

BTS systems typically have bug ID numbers that increase sequentially while blog software typically gives something like http://blog.example.com/YYYY/MM/blog-entry-name.html when it’s often more convenient to have something like http://bug.example.com/number. Of course it would not be difficult to have a little database that allows creating sequential numbers to map to arbitrary URLs in a similar manner to tinyurl.com. This could be either integrated into blog software (so that it says “bug #1234 has been created” or be available on demand (click a link to get a sequential number assigned). Incidentally using characters and digits for the short name of the bug (as done by tinyurl.com) would allow four characters to represent 1679616 bugs, this is enough for all bugs in the Debian and Red Hat bug databases combined. With tinyurl type technology there is nothing preventing us from having a single system creating unique IDs for all bugs in all distributions of Linux with a four character index (which is easier to remember than the 6 sigit numbers used in Debian and Red Hat at the moment).

I realise that most blog software will store the entries in a database which has sequential numbers assigned. So doing a database lookup to convert a human-readable URL into a sequential index when we have just done another database lookup to convert a sequential index into a human readable form is inefficient, but that’s the way of things, computers do things inefficiently so that humans can work in ways that are efficient for them.

Note that throughout this post I refer to the Planet aggregation system, but really any of the aggregation systems can be used. One of the benefits of this is that people can use mailing lists, Google’s reader, Planet, or any other reader they wish with the feeds. RSS feeds can be read by many programs and the user gets to choose which works best for them.

I’ve read quite a few blog posts about someone leaving Debian and whether they should remain on Debian planet. An official policy on these matters has now been posted which stated what I expected, if you feel that you belong and meet technical criteria then you are welcome.

Not that this solves much, the next debate will be about what content is suitable for Debian-planet with the expected answer being “anything which meets technical criteria and doesn’t offend many people or break any laws”. I’ve already had some comments on my blog from people who want me to change topics. I don’t know if other people get this or whether doing an average of one post per day gets me more attention from the loons.

I started blogging after leaving Red Hat. I considered asking for my blog to be added to the Fedora Planet, but wasn’t sure whether I would be posting much about it. I just checked and it seems that my old Advogato blog is aggregared on the Fedora Planet and there is no mailto URL on that site to allow me to get it changed. I’ve just put a final blog entry on Advogato to inform everyone of the change.

I’m not sure if it’s worth adding my blog to the Fedora syndication. I have just decided to change my main desktop machine from Rawhide to Debian/unstable. The reason is that Fedora is mostly a Gratis distribution and Debian is more Libre. For most computer users there is no real difference as they don’t have the skills to use the liberty that Debian offers. But for people who can code (note that we are in a small minority of computer users) the difference is significant.

The final issue that forced me to this decision is this bugzilla entry about Xen. In Debian there are kernels for Xen on i686, Xen on AMD K7, and Xen on i686 with vserver (doesn’t Xen make vserver redundant?). In Fedora there will be one Xen kernel which won’t boot on the machine that is most important to me and which ironically is the machine that was issued to me by Red Hat (and sold to me when I left).

This issue of a lack of choice is quite understandable from the Red Hat Enterprise Linux side of things. It’s OK to say to a customer who wants to pay for a RHEL-AS license that they need a machine less than 3 years old if they want to use all the features. Adding new kernels adds support costs and I think that most RHEL customers want to have a smaller set of supported options with a higher level of support. I often recommend RHEL to clients and I will recommend that clients use Xen on RHEL-5 – and that they purchase recent hardware to do so.

But for home and hobby use it’s a different matter. I provide all the support I need, I can compile my own kernels without much effort – but it saves time to have someone else do it. Fedora simply lacks choice here by design. I still support a bunch of Fedora and RHEL machines and will still develop RPMs for them. I will put everything I develop under http://www.coker.com.au/rpms/ for anyone who wants it.

Given that if the Fedora Planet people want to syndicate my blog I am more than happy to have them do so. I don’t dislike Fedora, in fact I still recommend that people use it. It’s just that Debian suits my personal needs better than Fedora does. I expect that I’ll have more Debian content than Fedora content on my blog, but there will also be a lot of Linux content that’s not distribution specific.

It will be interesting to see what the Fedora Planet people do.

For fun I just set up my own Planet. Reading both Planet Debian and Planet Linux Australia is a bit of a drag due to the overlap. So I wrote a little Perl script to extract the feeds from both those sources and generate a Planet configuration. My planet is publicly available in case anyone is interested. Also you will notice that I have a formatting problem on my planet, if anyone has some advice on planet templates (I’m using the Debian package) then please let me know.

While playing with Planet I noticed that my blog has one of the largest file sizes of all the blogs from Planet Debian and Planet Linux Australia. That would be partly due to writing blog entries of moderate size and trying to maintain an average of one post per day. But also I imagine that it woul d be partly due to the blogger configuration.

I changed my main blog page from 14 days to 7 days (which took the index.html size from 80K down to 40K). But strangely I can’t seem to change the number of days that are to be kept in the RSS feed file which remains at about 80K.

It seems to me that the feed mechanism is badly designed in this regard. A more efficient mechanism would be to send an XML file that describes the other blog entries, which could then be downloaded IFF they meet the criteria that are desired by the syndication software (and IFF they have not already been downloaded). If the web server and the syndication program are correctly configured then the requests could be chained on the same TCP connection for no loss of performance under any situation when compared to the way things currently work.

Also as many (most?) RSS and ATOM feed files are generated from a database it might be difficult to preserve the creation time, and thus I expect that most web caching is also broken. I haven’t verified this though.

Also it would be handy if there was a mechanism for syndication programs to request notification of changes and for a blog server to push content to a syndication server. I have Planet running every 6 hours, some of the blogs I read are updated once per week, apparently my Planet server does 28 downloads of the entire XML file for every change. This might not sound so bad, but there are planets which run every hour and would therefore have 168 downloads per week.

Please let me know if you have any ideas of how to alleviate these problems, or if there are already solutions of which I am not aware.

Previously I asked for advice about running an Intranet blog, and running an Internet blog with hosting for friends.

In response to the question about running a small Intranet blog the recommendations were strongly for WordPress, with a mention of Ikiwiki as well. One of the features that I consider desirable is for software to be reasonably popular which means that support is often easier to obtain. So WordPress is my main candidate at this time for Intranet use. I’ll install WordPress and probably won’t try anything else unless WordPress fails in some significant way (which seems unlikely).

In response to my question about a blog server for serious blogging again WordPress was well recommended. There is also a version of WordPress in beta called WordPress MU that supports blog server operations such as wordpress.com. Although I didn’t mention it before I have had some ideas of starting my own server along such lines so WordPress again does well.

Over the next few weeks I will start playing with WordPress and WordPress MU. If things go well I’ll move my blog away from blogspot and to a domain I own in the near future.

I’m getting sick of blogger. The main thing is that I’m simply not a user. Taking what someone else gives me and just putting up with any failings doesn’t suit me at all. I can deal with bugs in things I control (such as Linux distributions) because I can fix the bugs I consider important at any time.

So now I’m looking for a serious blogging program. WordPress was strongly recommended to me after my previous post on the topic of blogs, but that was in regard to a simple blog program for Intranet use. I am now after a blog program that is designed for Internet use, it must have good security, support multiple users (some of my friends will probably want to use my blog server machine), and not be overly difficult to customise (I am resigned to the fact that I will have to learn another programming language – probably re-learning PHP or Java as that is where web programming is at nowadays).

One thing that I want to do is to have the main web page that displays all recent posts display each post in a frame with a separate Adsense section. The topics of my posts vary a lot so I want to have adverts that match.

Another feature I want is to have multiple RSS feeds with different settings. One use for this is to have tags for each post to specify which channel(s) the post will end up on, another is for Adsense for feeds functionality which I want on for some feeds but off for others. I also want to generate multiple feeds for different syndication services. Ideally a syndication service such as Planet Debian or Planet Linux Australia would use a unique feed for sucking it’s own data and also have a unique feed address advertised on it’s site for the users (if this isn’t supported or desired at the syndication level then I can do tricks in the web server to serve different content for different IP addresses). That way I can track use by the different services, work around bugs in syndication services that matter to me, and change settings for post summaries, etc to suit the syndication service.

In terms of HTML editing I only need the most basic functionality. I would be entirely happy to write blog entries in raw HTML, my friends would probably desire line breaks to be converted to paragraph or break tags and basic linking functionality, but they could probably deal with entering bold and italic tags themselves (the few of my friends who couldn’t manage this would probably only want to write plain-text in paragraphs).

I also want to run my own syndication software. I guess I have to consider blog server and syndication server at the same time as there may be some dependencies (EG having them both written in the same language might be handy – I don’t want to re-learn BOTH Java and PHP). The syndication software would ideally automatically collect the feeds from other syndication services that I specify (although I’m sure I could write a simple Perl script to scrape them from the Planet web sites). Then I want to provide an RSS feed of that content for anyone who wants it.

Please let me know via email or comments if you have any suggestions about which software to use.

I’m currently working for a company that in the past has not embraced new technology. One of my colleagues recently installed a wiki which did a lot of good in terms of organizing the internal documentation.

The next step is to install some blogging software. What I want is to have every sys-admin run a blog of what they are doing and have an aggregation of all the team’s blogs for when anyone wants to see a complete list of what’s been done recently. The security does not have to be particularly high as it’s an internal service (probably everyone will use the same account). The ability to store draft posts would be really handy, but apart from that none of the advanced features are really needed.

Also it would be handy to be able to tag posts. For example if userA did some work on the mail server they would tag it with SMTP and then at some future time it would be possible to view all posts with the SMTP tag.

I’ve done a search on google for this topic and there are many pages comparing blog software. But all the comparisons seem based on Internet use, they talk about what versions of RSS are supported etc. But I don’t need much of that. An ancient version of RSS will do as long as there is a single syndication program that can support it. Performance doesn’t have to be great either, I’m looking at less than a dozen people posting and reading and a fairly big Opteron server with a decent RAID array.

For the minimal requirements I could probably write blog and syndication programs as CGI-BIN scripts in a couple of days. They wouldn’t support RSS or XML but that’s no big deal. But I expect that if I use some existing software that someone recommends in a blog comment it will be faster to install and have some possibility of future upgrades.