[Compcomm] Releases and packaging. And stuff.

Jeffrey Laramie imnotpc at Rock3d.org
Wed May 9 21:46:32 EDT 2007


On Monday 23 April 2007 19:11, Nicholas Thomas wrote:
> Hi,
>
> I've been asked to re-open the discussion on packaging, and (jokes aside)
> we aren't all /that/ far from being able to spit out a 0.1 (or whatever
> we're going to release as), I guess. So... to reiterate what's more-or-less
> agreed-upon so far (flame me if I get anything wrong here ;) )...
>
>  * CompComm releases source tarballs, and we have official repos and
> packagers who turn them into user-friendly goodness
>
> * The packaging should be distro-quality, and we should be aiming to get
> said packages into the official distros ASAP.
>
> * Release tarballs - currently, we have the source laid out as suggested by
> Jeff, see: http://gitweb.opencompositing.org/
>
> We'll have the following source tarballs:-
>
> emerald, emerald-themes
> libbs
> compiz-plugins-good: everything verified working with no major bugs, and,
> has an active maintainer.
> compiz-plugins-bad: everything in the "it compiles, ship it" category;
> mostly unmaintained (except for fixing compilation, updating for API
> changes, etc) compiz-plugins-ugly: everything being actively worked on that
> isn't yet stable enough for -good
> bcop
> $settings-manager-that-works-with-libbs
>
> compiz-core (depending on the first "what we need to think about" point ;)
> )
>
> These will be binary packaged as: emerald, emerald-themes, libbs,
> libbs-<backend>, $settings-manager-that-works-with-libbs,
> compiz-plugin-good-*, compiz-plugin-bad-*, compiz-plugin-ugly-* (each
> plugin in it's own package), bcop, $s-m-t-w-w-libbs, compiz-core, some
> others (see below)

I talked to David briefly about packaging and he's on board with your good, 
bad, and ugly naming scheme. He indicated that he would like that he would 
like to see "the requirement for -good package to be a lot more than bug-free 
and that plugins should at least work properly to be included in the -ugly 
package". He also likes the idea of the plugins each having their own repo 
(the way we laid it out in opencompositing.org) and that the division between 
plugin groups would only apply when packaging them. I would suggest that any 
devs who wish to discuss this in more detail bring it up on the compiz ML.

David also indicated that he is happy working with all the devs and thinks 
that we are working together well on code issues. Despite the ugly forum 
discussion, I think we are making a lot of progress in the areas that really 
count.

Jeff



More information about the CompComm mailing list