> At the risk of breaking out of the flow of the conversation we were having.
>
> I've talked to Jason (DBO), Dennis (Onestone), Guillaume (iXce), and
> Thomas (lupine) about this. We obviously doesn't represent all of
> Beryl, but the opinion is relatively significant.
>
> Everyone was quite excited about the ideas, and the consensus was
> mostly the following:
> New name, with the project including both core and a non trivial
> set of plugins.
I'm probably willing to agree to this but I'll have to see what the
other people involved with compiz thinks about it.
> Commits to core would be made to a branch, and 1 of 2-3 people
> (including you) will merge it in to the actual core if deemed
> appropriate. This is a balance between the obviously different
> development models of Compiz.
Any number of people can keep personal branches around. Where they're
hosted doesn't even matter as long as we use a distributed version
system.
Whoever wrote some piece of code should have the final say in what
changes that will go in. E.g. I'm not going to allow anyone to apply
changes to code I've written without them first knowing that I'm OK with
it.
I don't mind at all that a large amount of people have commit access to
my code. Obvious bug fixes can of course be applied by people when they
are sure about them but other changes should always be discussed first.
I'll of course make any significant changes I plan to make to code I've
written available for discussion before anything is moved in to the
core.
These are general rules that are used by most open source projects out
there. If you believe that other rules should be used I'd need a good
motivation before I could agree to that.
> License, MIT might be ok, but would have to be discussed more.
> LGPL was brought up, this would still allow linking to by non GPL
> compatible plugins but be less liberal in it's terms than MIT.
I'm interested in reasons people have to why MIT shouldn't be used that
are so important that the reasons for using MIT that I've pointed out
would have to be sacrificed.
> Core of the new project would have to have settings all in core
> (no settings plugin like Compiz has...), something like
> libberylsettings would be preferred, though this is definitely
> something that can be discussed.
I'm very skeptical to this. I'd need a very good motivation for why we
would want to have a specific configuration backend part of the core.
> Also some of the Beryl multihead
> changes would likely be very nice.
I don't know what this is.
>
> The biggest points we believe to be essential are the first one, and
> the second point (or an even less stringent model).
OK.