Does that look good? http://gitweb.beryl-project.org/?p=compiz/plugins/animation;a=summary
Regards, Guillaume 2007/4/11, cornelius <[EMAIL PROTECTED]>: > Ok, so how about the subdir /compiz/plugins/animation ? > Is this ok? > > On 4/11/07, Guillaume Seguin <[EMAIL PROTECTED]> wrote: > > For animation, it should be quite easier to just clone the repo under > > a compiz/ subdir (merging animation into -premerge would require > > latest git git and it's brand new git-merge-subtree to keep the > > history) > > > > Just tell me :) > > > > Regards, > > Guillaume > > > > 2007/4/11, cornelius <[EMAIL PROTECTED]>: > > > On 4/11/07, Danny Baumann <[EMAIL PROTECTED]> wrote: > > > > > For the git tree, is this all-in-one "pre-merge" tree the final form? > > > > > Or are we going to eventually split this to folders for each plugin > > > > > (which might make it easier for packagers to pick whatever plugins > > > > > they want to include)? (like in Mike's extra-plugins packages). > > > > > > > > After being in favour for an all-in-one tree first, I think the best > > > > compromise is to have one directory in the tree per plugin while still > > > > having the complete bunch autotoolized. This enables packagers to select > > > > single plugins out of the tree while still being able to build all stuff > > > > in one go. > > > > > > I completely agree. That would be the best of both worlds. :) > > > > > > So for now, I guess I'll just move over my animation/ folder as it is > > > with its own Makefile. Is that ok? And where should I put it? Maybe > > > under a /post-merge/plugins/ folder? > > > > > > > > > > > Btw, David is in favor of multi-tiered packaging for plugins. I also > > > > > think a few source packages would be good to have, like base/crucial-, > > > > > extra-, experimental-plugins packages. > > > > > > > > I think the best idea would be categorized packages (like you > > > > described), but that -good, -bad, -ugly stuff looks cool, too :-) > > > > Only drawback: Who selects which plugin would go into which package? ;-) > > > > Anyways, I think with my suggested layout this could be decided later > > > > on. > > > > > > Yeah. While this naming scheme sounds cool, I think some people might > > > get upset with it. And their definitions are not clear anyway. > > > _______________________________________________ > > > beryl-dev mailing list > > > beryl-dev@lists.beryl-project.org > > > http://lists.beryl-project.org/mailman/listinfo/beryl-dev > > > > > _______________________________________________ > > beryl-dev mailing list > > beryl-dev@lists.beryl-project.org > > http://lists.beryl-project.org/mailman/listinfo/beryl-dev > > > _______________________________________________ > beryl-dev mailing list > beryl-dev@lists.beryl-project.org > http://lists.beryl-project.org/mailman/listinfo/beryl-dev > _______________________________________________ beryl-dev mailing list beryl-dev@lists.beryl-project.org http://lists.beryl-project.org/mailman/listinfo/beryl-dev
