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

Tue Dec 22 17:45:44 CET 2009

On Monday 21 December 2009 02:42:46 am Alain Spineux wrote:
> 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_compariso
> >>n>
> >
> > 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

I think whatever will be chosen, testing native distributions will be a big 
plus for adoption of Kolab. Right now, it involves a lot of work to get it 
working in a native Mandriva environment, even just to build on native 
distributions. This environment will not guarantee that it will build on the 
native environment, but I believe it will make it easy if adjustments are 
needed

-- 
Thomas