[Compcomm] Releases and packaging. And stuff.

[Nick]

Guillaume Seguin wrote:
> 2007/5/10, Jeffrey Laramie <imnotpc at rock3d.org>:
>   
>> 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.
>>     
>
> We (onestone and I at least) think that what we could do is have one
> repo per plugin and that these repos would be automatically merged in
> the plugins-good/bad/ugly global repos which would use an appropriate
> autotools system. We wrote a git hook for that while I was at UDS, and
> we are testing it at the moment.
>
>   
>> 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.
>>
>>     
>
> Great :)
>
>   
>> Jeff
>>     
>
> Regards,
> Guillaume

OK, good news. Quick point... -good, -bad and -ugly wasn't my idea :).

I've no problems with raising the bar for quality - it should be as high
as possible really, since we're talking about releases.

No other sensible comments at the moment, as I'm totally snowed under.

/Nick