[Compcomm] Releases and packaging. And stuff.

[Jeffrey Laramie]

On Friday 11 May 2007 09:00, Franz Rogar wrote:
> 2007/5/11, Nick <nick at lupine.me.uk>:
> > RYX wrote:
> > > How about having individual packages for each plugin and using
> > > metapackages for user-friendly installation of special
> > > groups/selections? An automated build-system could do that the same way
> > > as it would create few packages from all plugins.
> > >
> > > As far as I can say there are many people who prefer being able to
> > > install plugins separately. Maybe it is ok for developers to group them
> > > in good/bad/ugly but for the average user this is highly confusing.
> > >
> > > There could still be good/bad/ugly metapackages which then install only
> > > a small selection of the available plugins. This is the way many other
> > > "modularized" applications handle it.
> > >
> > > (Just a thought - feel free to ignore me ;) ...)
> > >
> > > Rico
> >
> > -good, -bad and -ugly are at the source-level. At binary-level, it makes
> > a lot of sense to have one plugin per package.
> >
> > /Nick
>
> Following with this idea, I suggest this:
>
> At GIT repo, folder naming:
> - compiz : compiz fdo mirror
> - app : applications (ccs-settings, cws, ccsm... folders)
> - lib : backends and bindings (ccs-python, bcop, compizutls... folders)
> - plugins : plugins (animation, mousegestures, python, wall... folders)
> - scripts : scripts for building source tarballs and (optionally) for
> building them
> - users : as there're now
>
> - inactive : as there're now. I think if there were any option to
> split this from actual git could be fantastic :)
>
> So scripts could create at source level (-good, -bad, -ugly) and pkg
> level (each folder on its onw targezipped file)
>
> Just my thoughts :)

The reason that the plugins, libraries, etc. are in the compcomm directory is 
to allow the repo to host other programs that may not be part of CompComm. If 
for example, one of our devs develops a popular program "superwidget" and 
superwidget also uses libraries, how would we keep track of which libraries 
go with which program? While it's not necessary right now, keeping related 
code in subdirectories will avoid confusion in the future and allows us room 
to grow. BYW, the current git layout is based on the fdo git design.

Jeff