[Kolab-devel] Kolab 16 for Debian

[Aaron J. Seigo]

On Saturday, October 29, 2016 08.23:15 Timotheus Pokorra wrote:
> How do we count if there is enough demand?

Here is how I have been "counting" for our efforts at Kolab Systems (KS):

a) Customers. We have visibility on them (which truly helps in measuring ;), 
and they also are very influential on the agenda of KS as we are committed to 
supporting them and their needs. This group includes both paying customers as 
well as potential/interested groups.

b) The next metric we have been watching is access to the repositories: how 
many people hit which repository for which OS and Kolab version.

Otherwise ... ?

There is certainly demand out there for a Debian build, both from community 
and customers. Ubuntu seems purely community.

So we @ KS have been trying to find a good balance there. The community is 
vital, and we also only have so many hours in the day and people on our 
payroll working on packaging.

The absolutely most compelling form of count, though, is people's efforts. If 
someone takes on Debian and/or Ubuntu packaging in a very serious fashion, 
that is the most impact one can have. Period.

> Is there a time plan?

Until we had a few ... "events" ... that took up the team's time last month, 
we were actually planning on charting out and leading a packaging effort for 
16.1 during October. I hope we will see this go forward this month. As soon as 
we have a firm "yes" on our availability, we'll let everyone know here.

> Do we need help from the community?

Always :)

> Should we offer a slimmed down version of Kolab (without guam) if
> Erlang packaging is a problem? (I don't know if it is)

One of the easiest things to do, if this is a challenge, is to create and ship 
a release version of Guam. This is that horrible, horrible thing (to 
packagers, anyways ;) known as "vendorization". If you run `make release` in 
the top level, you should get a fully self-contained set of binaries in the 
rel directory. And I mean fully self-contained. It will include the erlang 
runtime and everything.

This gives you a zero-dependency,  no-nonsense package to ship.

The downside is that it is "vendorized": if there is a useful update to Erlang 
or any of the (small number of) erlang libraries guam uses, it would need to 
be rebuilt. It also means the single guam package would be rather larger than 
if it was all split out into a bunch of packages as it is done in the Red Hat 
world.

I have no personal opinion on which is better or worse. I know that packagers 
tend to hate the vendorized-builds that are more and more The Standard 
Practice for frameworks as varied as node.js, PHP and Erlang/Elixir. But it 
does make it easy to make shippable binaries you KNOW will work with ZERO 
conflict with any other applications.

-- 
Aaron Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20161104/441bfb04/attachment.sig>