Introducing Winterfell

Up north, where the men are real men, the fights are real fights, and peace is an intermezzo. Hear! Hear!

Some projects, with some of the GNU/Linux distributions among the most well-known, have code names for their bleeding edge builds. Be it Rawhide, Tumbleweed or Sid, these code names are used to refer to the least stable, fastest moving edge of the project’s progress in pursuit of salvation. Hear! Hear!

The continuous integration and delivery for Kolab Groupware requires such a landing place — a project with a well-established reputation of eating babies, for breakfast.

I’m pleased to announce the availability of Winterfell.

The project is managed by the warden of the north — from this day until the end of days. This is currently an open position, for which we may want to find a process in appointing the first generation.

While Winterfell is subject to continuous delivery, it will be the role of the warden to make sure Winterfell is not burned down, or overrun by an army of the dead, or captured by Ironborn, or raided by wildlings — as you might know either of these things can happen. It may be difficult to keep under control. It can be rough to run Winterfell — because winter is coming.

What About Kolab:Development?

The future of the Kolab:Development project is uncertain. It is currently used as the target for Continuous Delivery, but like I mentioned, that’s going to be Winterfell.

I could propose Kolab:Development is where packagers pick up changes for their individual favorite distributions — so I can slim down the number of target distributions for Winterfell to a very few distributions and version that are most often used by contributors.

I could also propose Kolab:Development in its current form goes away entirely. In its place could come a rolling release for packages that the community submits, reviews and accepts changes. These packages should originate from Winterfell, but would eliminate the likely very unstable nature of continuous delivery. It would be the target end-point for a stage between “git master HEAD” and “yum update”.

That said, it would be a rolling release, meaning there would not be one certain version number, no life-cycle, nor a successor as such, but instead “yum update” remains valid perpetually. I would call this project “Snow”.

However, for those of you that just want something stable, we have Kolab 16. We have talked about improvements to our release processes, and converging community and enterprise editions. We have talked about the world of difference between short- and long-term commitments. We have talked about the evolution in Kolab Groupware development.

All of this accumulates to one stable version of Kolab 16, and a focus on better and faster development, which we would like you to participate in.