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

Mon Dec 21 10:42:46 CET 2009

Hi

Here are some comment about what I read in previous post:

What about the appliance model ?
1. Choose a base distribution
2. Build an auto-install CD that will finish the normal distribution
installation by the kolab installation
3. This appliance could be installed as a virtual machine on other system
This way, the choose distribution will be supported, and kolab could
be installed on other system as a virtual machine.

Why not to make a survey on the mailing list about which distribution
kolab users use ?

What about solaris user ?

Please forget about fedora, (a new fedora every 6 month could be hard
to support :) thing about Centos

On Tue, Dec 15, 2009 at 4:03 PM, Gunnar Wrobel <wrobel at pardus.de> wrote:
> 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 <<
> --------------------------------------------------------------------
>
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>

-- 
Alain Spineux
aspineux gmail com
Your email 100% available with Emailgency  |  http://www.emailgency.com