hey emilio, On Monday 11 February 2008 10:33:32 pm emisca wrote: > Hi Sean, here is what I think about compiz packages reorganization: > > Pros: > - small number of packages > - single uploads and queues
i think i haven't been clear enough... this isn't about *binary* packages,
it's about *source* packages. so that is to say the same list of packages
that we had before (compiz-fusion-plugins-main/extra/unsupported, etc) will
be the same, but they will be generated from a smaller number of source
packages which are organized based on what makes it easier for us to manage
with respect to releases.
> Cons:
> - versioning not aligned to upstream, they often release modifications
> to each of these packages in a separate way.
part of the organization should take that into effect, yes. for example, the
plugins trees are usually released in sync with each other, or at least when
we find ourselves having to update one (due to supporting a new API/ABI from
upstream compiz), we usually have to update the rest as well. therefore,
managing them together in the same source package seems like a nice idea to
me. and as a bonus, it's all managed in a single control file, so keeping
dependencies in sync should be fairly trivial (for example defining a
compiz-fusion substvar that we substitute into Depends, in addition to the
automatically simultaneous uploads).
> - compiz-fusion-plugins: those plugins are classified by upstream
> support. It would be a pain for us, supporting the "unsupported" or
> "extra" plugins without the upstream support...
well, that's somewhat orthogonal to the matter at hand. that's really an
argument for "should we even package this at all"... which of course is
perhaps worth discussion, but since we already have them uploaded... :)
personally i feel as long as they stay classified the same way as upstream
(i.e. our plugins packages come in teh main/extra/unsupported flavors), i
think it's okay.
> - technical issues: it's more difficult to create a packages from more
> than one source tree.
this is true, and is the biggest variable as far as i'm concerned. it could
be that using submodules (or just keeping a source package as a collection of
git repositories) is just too much overhead or too complicated or too error
prone from a maintenance point of view. if that's the case then obviously
nothing should change :)
> - fusion icon, ccsm, simple-ccsm are from different upstream teams...
right. but this will only mean that if they have different release schedules
that we'll need to rebuild/reupload the same source package more often. since
most/all of these are python apps, it shouldn't be too much work, modulo the
issue mentioned in my previous comment above.
> Perhaps there is the need of metapackages to ease the installation
> process to final users.
sure, i agree. again though, this is orthogonal to the point, since we could
generate meta-packages from these source packages just as easy as
we could from the current set.
(please continue to CC me)
sean
signature.asc
Description: This is a digitally signed message part.
