[Kolab-devel] Fwd: Introducing OpenPKG 4.x

Gunnar Wrobel wrobel at pardus.de
Tue Dec 15 16:03:51 CET 2009 

Hi Mathieu,

this is going to be a long mail. Summary at the bottom :)

Quoting Mathieu Parent <math.parent at gmail.com>:

> On Fri, Dec 11, 2009 at 9:52 AM, Gunnar Wrobel <wrobel at pardus.de> wrote:
> ...
>> I think we should start discussing the different available options on the
>> list so that we get an overview on the different options including their
>> pros and cons.
>
> Let's do it!
>
> I have setup a page on the wiki:
> <https://wiki.kolab.org/index.php/Developer_packaging_platform_comparison>
>

Thanks!!!

I added a short summary on top and the licensing information from
the recent mail from OpenPKG to clarify why we consider changing
the distribution.

I did actually try to call OpenPKG twice just to get some
personal feedback from them but they seem to be in holiday
already. They don't offer a way to leave them any messages. I
guess I could mail them but I think the letter Martin Konold
forwarded was already clear enough. I just would have liked to
discuss it in person.

To me the move away from OpenPKG seems to be unavoidable now.

I would like to reprint the requirements you added to the wiki
page:

  Requirements

     * MUST be FOSS

     * MUST be available without charging clients

     * MUST cover major Linux distributions (see on distrowatch or
       Wikipedia) : Ubuntu, Fedora, openSUSE, Debian, mandriva,
       ...

     * MAY include a build service

     * MAY include automated tests

I think they are complete. Does anyone have something to add?

> Currently, two solutions have been mentionned:
> - OpenSUSE Build service
> - Project Builder

I'd like to split the "solutions" part somewhat further.

You listed two build services as possible successors to
OpenPKG. The outcome of these build services would be Kolab
Server images/builds for several different distributions. This is
a worthy goal and I believe it would help with some of the
problems we are currently having. It should be a part of our
strategy.

But I say "a part" as these build services will yield different
flavors of the Kolab Server. Each distribution specific build
could have its unique problems. If we would declare such a build
service as successor to OpenPKG then this would mean that we need
to test the resulting builds for each distribution. And that was
a central part of the quality control strategy: Just testing a
*single* distribution which customers can install on any base
distribution.

Testing is a limitation for us. The guys at Intevation are doing
a tremendous job concerning the quality of the server. As this
requires significant man power I really don't see how we could
extend that effort beyond a single distribution.

Back to the build services: We could of course use such a build
service but restrict testing to a single distribution built by
the service. This is in fact what I'd like us to do. But that
means that the original question remains the same: Which
distribution will we test instead of OpenPKG? Which distribution
gets our commercial support?

This is the primary question to me.

I do see two broad categories into which the solution might fall:

  1) Source based distributions (OpenPKG, pkgsrc, Gentoo, ...)
  2) Binary distributions (Ubuntu, Fedora, Suse, Debian, ...)

Source based distributions have the great advantage that we test
only a single distribution. Nevertheless the user can install
this system on many platforms. Most of the source based systems
support many variants. Of course this has a major drawback: While
you can install on many platforms you still install a new
distribution within the one you are used to which means to have
to learn the OpenPKG toolset.

A binary distribution would have the advantage that everyone used
to that distribution would feel at home immediately. The
disadvantage would be that we remove support for platforms we
have been supporting so far.

As much as I dislike OpenPKG I have always considered the choice
of a source based distribution to be a good one. Of course people
were unhappy with using the OpenPKG toolset rather than the one
provided by their favored distribution. This has fostered several
native ports and expressed a certain disagreement with the
OpenPKG choice. But my impression was also that there are many,
many people which are happy with the simplicity and robustness of
the Kolab server. Using OpenPKG has allowed us to provide a
consistent and high quality over many platforms.

I'm absolutely convinced that we should not leave users behind by
removing support for platforms we supported before. Using a
binary distribution as the base we support for the Kolab Server
is no option to me.

Back to the build services: Assuming we choose the distribution
we want to support then I see no reason why we should not use one
of the build systems you mentioned. The OpenSUSE build system
would of course only work if it supports the distribution we
chose. The project builder seems more generic.

The build service would hopefully reduce the amount of duplicated
work necessary to build the Kolab server on the different
distributions. All the required packaging information could
probably be centralized in one repository.

It should also help us to improve the quality of the native ports
as this is one problem we currently see: A user that wants to
install Kolab might start to try with a native port. These are
usually maintained by less people than the OpenPKG variant and so
the chances for problems are slightly higher. If the user hits a
problem he might have difficulties getting support from the
mailing lists. I know how often I have to say that I don't know
what the state of a specific native port actually is and how the
problem might be solved.
I would hope that using a build service helps indicating early
that a commit might cause problems on one of the distributions
supported by the build service. It would improve my awareness of
the state of the native ports which would be a good thing.

On top of the supported distribution and an optional automatic
build system I see automated testing. We should investigate if it
would be possible to use a testing framework that allows testing
the different Kolab Server builds equally well.

This would help us in development as problems might be discovered
early. It would also reduce our testing effort as some checks are
performed automatically. In addition it would also help the
quality of the native ports.

Summary
=======

I believe the primary focus of the discussion is the quality of
the Kolab Server. To keep the standard high we absolutely MUST

  - select a single distribution that will be tested and supported
    by the Kolab consortium

We SHOULD

  - find a build service that makes building the Kolab Server on
    different distributions easier and helps dissolving the
    current barrier between Kolab/OpenPKG and the native ports.

  - investigate automatic testing further to reduce the effort
    required for testing, to improve development and to help the
    native ports.

Cheers,

Gunnar


-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20091215/8dcab9b8/attachment.sig>

More information about the devel mailing list