Page MenuHomePhorge

Documentation for the installation of Kolab 16 on Debian Jessie
ClosedPublic

Authored by vanmeeuwen on Nov 21 2016, 10:34 AM.
Tags
None
Referenced Files
F11587380: D278.diff
Thu, Mar 28, 5:22 PM
Unknown Object (File)
Mon, Mar 25, 8:09 PM
Unknown Object (File)
Mon, Mar 25, 1:13 AM
Unknown Object (File)
Wed, Mar 20, 10:30 PM
Unknown Object (File)
Tue, Mar 19, 1:46 PM
Unknown Object (File)
Sun, Mar 17, 11:41 PM
Unknown Object (File)
Sun, Mar 17, 9:33 PM
Unknown Object (File)
Tue, Mar 5, 3:04 PM

Details

Summary

Document the installation of Kolab 16 on Debian Jessie

Test Plan

Try it out.

Diff Detail

Repository
rD docs
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

vanmeeuwen retitled this revision from to Documentation for the installation of Kolab 16 on Debian Jessie.
vanmeeuwen updated this object.
vanmeeuwen edited the test plan for this revision. (Show Details)
This revision is now accepted and ready to land.Nov 21 2016, 1:55 PM
pokorra added inline comments.
source/installation-guide/index.rst
26

this is not clear to me. will we not be able to push updates to Kolab 16 anymore, after the release of Kolab 17?

seigo added inline comments.
source/installation-guide/index.rst
26

This resolve the need to support N past versions in parallel (16, 17, 18, ...) and keep focus on the current release. A useful way to think about this is that 17.0 supersedes a 16.2 release; so instead of doing a 16.2, we move directly on to 17.0, and that becomes the upgrade step from 16.1.

source/installation-guide/index.rst
26

But not everyone will upgrade to Kolab 17.0 on release day. Some people might want to wait a bit until they hear enough reports of success, until they upgrade. Therefore it should still be possible to maintain Kolab 16 for some while.
I understand that we cannot support older releases for a long time. Perhaps define a limited time of parallel support for Kolab 16 and Kolab 17 (perhaps 6 or 9 months?).

If we want to get Kolab into distributions, we need to have longer support anyway, at least for the upstream packages.

dhoffend added inline comments.
source/installation-guide/index.rst
26

IMO you can't really call it 17.0, 17.1 and 17.2 if they're all delivered from the same Kolab:17 repo. I would like to compare it with Debian Releases. Version 7.0 becomes stable, 7.1, 7.2, etc are smaller updates. When Debian 8.0 comes out Debian 7.x becomes oldstable and gets community support and/or max security fixes. At some point in the future when 9.0 comes out and become stable, 7.x gets moved to the archive and doesn't receive any updates while 8.x becomes oldstable

This the community has at least a change to uptime withing 1 or 2 years while enterprise customers have their 5 year business plan.

In one of the roadmap blogposts there was something written that X.0 will be the new release while the first iteration X.1 will become the base of the new enterprise distribution. I personally would wait until the dot.1 release comes out before I would upgrade from the previous to the most recent release. But that's likely because of debian packaging bugs in the past which needed to be reviewed first most of the time.

source/installation-guide/index.rst
26

not everyone will upgrade to Kolab 17.0 on release day.

That is absolutely fine, and expected. But this is true no matter how the version numbers would be handled / labeled. We missed the target with 16.1 by half a year; 17.1 will be out in a more timely fashion, allowing people to upgrade with reasonable rapidity.

Therefore it should still be possible to maintain Kolab 16 for some while.

With security updates, sure. With feature enhancements, non-critical bug fixes, etc. it is generally not feasible to do a good job of that with the resources that are available in the community as a whole. Such ongoing support can only be done properly with significant commitment and support, and that is the point of subscription: it supports the efforts required to take on maintenance of prior releases as the product moves forward.

If people want to sit on Kolab 16 for an extended period of time, they should pick up a subscription to support that. It coincidentally helps forward development as well, but for the subscriber there is the immediate benefit of knowing they don't have to make a choice between upgrading or falling increasingly out of date.

And by "extended period of time" I don't mean just mean 5 years, or even 3. 2 years is already quite a commitment if we are also to keep putting out 2 releases per year which also contain necessary forward development and improvements.

26

IMO you can't really call it 17.0, 17.1 and 17.2 if they're all delivered from the same Kolab:17 repo

We already do the functional equivalent that, so it is evident that we can :)

This the community has at least a change to uptime withing 1 or 2 years while enterprise customers have their 5 year business plan.

Firstly: enterprise customers are part of the community too. They give back significantly more than the vast majority of other users in the community, and not only monetarily but also in terms of testing, end-user feedback, requirements creation, event attendance and support, etc. They are on equal footing in my eyes with users of Kolab who participate in development, documentation, translation, etc. So let's give them their due and admit they are part of the community, and try to move away from this "enterprise vs community" language which is simply not accurate.

Simply put: have users of Kolab, some of whom pay for support and SLAs, and others who don't. They are all part of our community.

It is obviously up to each user how to participate with Kolab: as a user that has no contact with the Kolab community projects, as a user that participates in the creative flow, and those who choose to also support Kolab financially either because they realize the intrinsic value in doing so or because they want the quid-pro-quo that Kolab Systems offers in return.

Those who use Kolab without participation have all the source code and access to stable releases at least once per year (if we ignore the .0 releases). There is no reasonable expectation for it to be packaged to their personal convenience beyond that.

What I do think would be reasonable is to recognize community participation as a form of currency and offer those who participate in the creative processes that make Kolab in a meaningful way (people in this discussion fall into that category, easily :), and work out a sensible way to provide access to long term support packaging repos for those peoples' personal Kolab usage. Something to discuss in future, and hopefully sooner rather than later?

This entire discussion should probably be moved somewhere more useful rather than this differential though :)

This revision was automatically updated to reflect the committed changes.