On Fri, Jul 29, 2011 at 6:06 AM, Scott Moreau <[email protected]> wrote: > > > On Thu, Jul 28, 2011 at 12:24 PM, Sam Spilsbury <[email protected]> wrote: >> >> Hi, >> >> I'd like to propose a simplification to our current repo structure, >> based on the way development is going. It seems like a lot of the >> structure of the project was impacted by the political development of >> compiz and this is proving to be a high barrier to entry to people who >> want to get started on compiz. >> >> 1. fold libcompizconfig into core: I can't think of anybody that uses >> the legacy gconf and ini plugins now. compizconfig provides this >> functionality just fine. We would still have a libcompizconfig library >> for the backends to link to and for external applications to use to >> configure compiz. It also means that we can drop some of the behaviour >> that the gconf backend used to track the gconf plugin, such as copying >> keys around on profile change. >> 2. fold the backends into core under gnome/ and kde/ . Again, there is >> no need for more repositories for these things. We already maintain >> the decorators as part of core, the backends can be done in core as >> well. > > Sounds good.
I'll get started on that ASAP > >> >> 3. fold plugins-main into core, move plugins-extra and >> plugins-unsupported into plugins-community. The main plugins are what >> distributions are shipping with, so keep them. The extra and >> unsupported plugins are community things. > > I propose that all non-wm-essential plugins be moved out of core into > separate repos and be included with plugins-main and possibly keep > plugins-main separate. I agree about moving the plugins into separate repos and having them synced into plugins-main. I think that the plugins should be distributed as part of core though, it means less stuff to compile (since compiz is a fairly useless wm without them) > >> >> 4. fold compizconfig-python into core: There isn't any reason these >> day to ship python bindings separately. > > As a side note, we probably should prepare for python3 support at some point > as well. I believe we already do support python3, or at least, I remember implementing support for it at one point. It was a fairly easy task. > >> >> The individual plugins will still remain in their own repos. This is >> useful because it allows those components to have different release >> schedules and development methods. For everything else, developers >> should be able to branch one project and get started right away. >> >> If nobody objects to this, I'll start doing it within the next few days. > > Sounds good. > > > Regards, > > Scott > > _______________________________________________ > dev mailing list > [email protected] > http://lists.compiz.org/mailman/listinfo/dev > > -- Sam Spilsbury _______________________________________________ dev mailing list [email protected] http://lists.compiz.org/mailman/listinfo/dev
