Because of that I finally had a look at BlueGriffon (written by the same developer as the Netscape/Mozilla/SeaMonkey Composer and Nvu) as it seems to be in active development and supports quite some of the new HTML5 and CSS3 stuff and created an initial openSUSE package available in the mozilla OBS repository for testing now. There is also an openSUSE feature request to make it available.  If you are a web developer or already know BlueGriffon please give the package a try and send your feedback.

My plan for the openSUSE distribution would be to keep SeaMonkey’s Composer (basically anyway because it’s a part of SeaMonkey which is to stay), add BlueGriffon and drop KompoZer. If you see a reason why that might be a bad idea based on your experience as a web authoring application user please let me know.

Looking forward to your feedback!

I cannot tell much about 11.2 (but as far as I can see Stefan does an awesome job in maintaining it) but will share my thoughts about the 11.1 flavour of Evergreen.

When I started that project it was clearly an experiment as I haven’t had an idea how much work it would be and if people would use it or even help with it. Looking back at what we’ve created it finally is more than I expected. Compared to what I announced in the beginning it was almost possible to maintain every part of the distribution and not only server packages. There are things which turned out be quite hard (e.g. kernel) but overall most issues were covered for 11.1. I think what I was able to prove is that it’s possible to somehow maintain a distribution  with very few manpower.

Now as 11.1 is nearing its 3rd birthday on December, 18th and given the fact that it’s getting harder having stuff updated while still being more or less compatible and stable I found that I cannot keep the pace with my limited spare time and without neglecting my other volunteer projects (remember Mozilla’s rapid release cycle?). For that reason I’m announcing that I’ll step back from being the Evergreen/11.1 project leader by end of this year. As of now noone else has stepped up so I need to announce that 11.1 will most likely be unmaintained as of end of this year. This does not affect 11.2 and I’ll also try to keep my packages updated for maintained Evergreen projects in the future. I’ll also stay involved and help out with organizational and administrative stuff where needed.

It’s still possible to step up taking over the 11.1 maintenance but in the end I think 3 years is already a good timeframe for a community distribution.

I hope that I find a bit of time in december to post a (statistical) summary about Evergreen/11.1 to let you know about some details.

Thanks for your support during the last year!

The first to follow are maintenance updates for Firefox 4 which are now codenamed Macaw. 4.0.1 is in upstream beta testing for a few days now. At some point in future we will have a SeaMonkey 2.1 release which will  be (most likely) based on the same Gecko version as Firefox 4 and you can get 2.1b3 snapshots for that from mozilla:beta. From the same repository you can also install a new Thunderbird 3.3a4 (codename Miramar). Please note that this early package has no Enigmail support yet.

Now to some interesting changes which are coming up with Firefox development and releases. Mozilla switched to a “rapid release cycle” after the release of FF4. This means that we will see new Firefox major releases around every 6 weeks. Firefox 5 is currently planned for end of June 2011. Firefox now is developed through different stages before the final release where Aurora is branched already for FF5 and will enter the beta stage in a few weeks. A current Firefox Aurora build is available in mozilla:alpha.

This changed release process also means that there won’t be long maintained branches anymore which has an impact on how we deal with updates during a distribution lifetime. Nothing has been discussed on that topic yet though. Another fallout is that our Firefox packages will be standalone packages again after several years of being based on XULRunner. What will happen to XULRunner in the distribution is yet another thing we need to figure out.

In general we are in good shape. Up to now we have released around 55 source updates. You can find the list here. So looking back that means that we were able to update almost everything including desktop applications which was not clear in the beginning how that would work out. Also the Packman team decided to support Evergreen by keeping the Essentials repository available. Unfortunately it is not quite usable at the moment since it contains RPM packages signed with keys not supported by the RPM version in 11.1 which means zypper refuses to install those.

Another milestone is that it seems we will also support 11.2 when it runs out of Novell’s maintenance on May 12th, 2011. Another community member agreed to  lead the effort. More details on that to come soon.

But not everything is working perfectly fine though. Besides some rare cases where community members submitted packages to Evergreen/11.1 all the backporting/packaging work up to now was done by myself. At some points in time I was quite on the limit of my time for the project and there is no redundancy if something bad happens to me. We really need more people contributing to Evergreen. That said it would be really nice if maintainers (especially community maintainers) would  prepare updates for 11.1 as well. Obviously there is no obligation in doing so but I somehow think that in some cases they are just missing the fact that Evergreen exists at all.

So if anyone out there has interest in helping maintaining 11.1 and/or 11.2 please contact us through our mailinglist or contact me directly.

We had a longer discussion on the mailing list if an openSLES (a’la CentOS) or “openSUSE LTS” would be the better or easier solution. There are pros and cons for both while the required infrastructure differs a lot. I’m not diving into details here though. While I would find a SLES clone appealing I’m not in the position to drive such an effort. I also do not think that having both makes sense and therefore I decided to go on with the other approach for now trying to extend the lifetime of an existing openSUSE release.

People in the community came up with the project name Evergreen and I think that matches what we try to build pretty well. I proposed to give the whole effort a trial with openSUSE 11.1 which went unsupported with the new year. At the moment we still have organizational and technical issues and most likely won’t be able to utilize all the update features (deltarpms, zypp patches) but still we will try to deliver updates from a certain update repository. Because of the holiday season we couldn’t figure out the details yet but hopefully will get it sorted out in time. Stay tuned for further detailed information here and on the mailing lists.

Please note that this effort is in experimental state still and didn’t attract that many contributors yet unfortunately. So at the moment it’s still unclear if we will be able to deliver as we would like to.

If you are interested in this project feel free to join our (current) project list.

A possible solution?

Sometime last year there was a discussion about options for something like an “openSLE” or “openSUSE LTS” distribution. There is an external page where some outcome was documented here. The dicussions stopped mainly because of health issues of the main initiator. There was done some planning and voting on the different options but no real results ever happened (as far as I know). So I’m trying to resurrect that topic a bit once again:

The amount of work related to such a project is the critical part and therefore my proposal is to try to start off with a “lightweight” approach.

This would be something like an openSUSE LTS version. That means that the community would take over (security) maintenance after Novell as main contributor drops it out of official maintenance after around 18 months. This will likely only work for a subset of packages which were delivered with the original distribution but the focus might be on server services anyway. Using the openSUSE release which also is the base for SLE could help us a bit as the work is done anyway (some of the Novell employees who are also openSUSE community members would hopefully help us here?). There are quite some details to work out still but it could be doable.

While I think we wouldn’t need a lot of people we at least need some and the more the better.  We will bring that topic up again on opensuse-project@o.o as well. The main intention of this post is to get feedback if there is enough interest and contributors to do further planning. I’m very interested in hearing from you via comments, mailing lists or personal mail.