[Kolab-devel] Fwd: RE: New Kolab Website Live

[Jeroen van Meeuwen (Kolab Systems)]

On 2012-02-29 21:04, Del wrote:
> I looked through the conditions here:
> http://mirror.kolabsys.com/pub/
> Point 1-4 is fine. Point 5 and 6 I find more alienating. Point 5 may 
> suggest
> that security updates are withhold from the community on purpose for 
> no good
> reason.

Point 5 is to illustrate that - in conjunction with point 1 - the 
community may not be as speedy as corporate requirements from both the 
vendor as well as the customer may spawn interest in getting security 
updates out to customers and spending the resources at it in order to do 
so.

Furthermore, the community may not have a need to maintain, in the 
future, (old) versions of software for (old) Kolab Groupware product 
series, while long-term support requirements for customer deployments 
make Kolab Systems release those security updates through software 
repositories available to customers and partners only.

There's nothing strange nor new about that, it's RHEL vs. 
CentOS/Fedora.

That said, all of the packaging you see is being done by community 
members who are all on Kolab Systems' payroll at this moment, so rest 
assured everything is running at the same pace.

> Point 6 may suggest that Kolab has moved to an open core model.

Never, for as long as I have a say in it.

That said, again, customer requirements of a certain product series may 
spawn the need for a Kolab $x.$y product series to support version $z of 
software package $foo.

> Re-phrasing them may be sufficient. Point 1 may of course provide an
> explanation for those two, so please share your thoughts on community 
> involvement in
> packaging?
>

We'd love to have more (and better?) packagers involved with the 
packaging of the software for a variety of distributions - including but 
not limited to Debian, Ubuntu, Fedora, CentOS, RHEL, Scientific Linux, 
OpenSuSE and SuSE.

It's why we keep the packaging semantics out in the open; see 
http://git.kolabsys.com/ and http://git.kolabsys.com/?ofs=300 for 
examples of GIT repositories for packaging. FWIW, we attempt to follow 
the various upstream guidelines for packaging best we can.

Now, parts of our build infrastructure is behind closed doors (on an 
internal network inside our slice of a datacenter in Zurich), but I 
would sure love to find ways to make build infrastructure available for 
community to actually trigger the builds as well.

Before we do that, because it is quite the effort to do so, I think it 
is fair to first start with people sending patches to the existing 
package repositories, later giving them access to commit to the 'origin' 
repository, to then follow up with some build infrastructure.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08