| Summary: | Project request: Beryl | ||
|---|---|---|---|
| Product: | freedesktop.org | Reporter: | Robert Carr <racarr> |
| Component: | Project Creation Requests | Assignee: | fd.o Admin Massive <sitewranglers> |
| Status: | RESOLVED INVALID | QA Contact: | Robert Carr <racarr> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| URL: | http://beryl-project.org | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Robert Carr
2007-02-26 16:43:30 UTC
one thing i'm personally quite concerned about is the fork. it seems to me like there should be a lot more work done in common with compiz -- for instance, it should be possible to develop plugins in a common repository, rather than the push and pull that goes on between the projects. The problem with developing plugins in a common repository is the cores have different features and ways of doing things (Even things that are the same interface wise are often done differently, i.e. beryls handling of multihead perspective). Right now theres sort of a last ditch attempt to rectify the differences of the projects (A bit on this: http://lists.beryl-project.org/pipermail/beryl-dev/2007-February/000237.html but the situation isn't nearly as depressing as that thread implies). Ideally we would all like to collaborate to make a better composite manager, but the projects have large enough differences in goals and methodoligies that it's diffiult to rectify. Whether or not this gives us the right to fork a project is obviously a lot more questionable, but if you look at the history it was difficult to avoid. The compiz-quinn constributors were sitting on a large pile of improved (Depending on how you look at it) over months code that they were being pressured not to distribute under the name Compiz, so there were three options: 1. Attempt to merge the codebases in some fashion. Compiz wasn't a big fan of this. 2. Throw the code away, I think it's understandable why this wasn't a desired option. 3. Fork Obviously there are areas in which the projects are able to cooperate, David and I discussed the idea of a common mailing list for discussing issues common to compositing managers in general, and this would at the very least be nice. okay, i need some time to think about it. i understand that obviously you guys had your reasons for forking. (just as an aside, though, i think kristian missed david's point about the license. the x server does not accept gpl'ed code, and a bit of code that began life in compiz has been migrated to the server. if the code were gpl instead of mit, then this would not be possible.) thanks, btw, for the follow-up and explanation. not much point, since this is now part of compiz ... |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.