On 2/21/07, David Reveman <davidr@novell.com> wrote:
> On Tue, 2007-02-20 at 17:37 -0500, Robert Carr wrote:
> > 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.
>

This seems fair enough, and was more or less what I meant.

> >     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.
>

Again, I'm not really concerned about MIT so I can't argue this point
for other people, I will try and get some more specific information
though. After taking to people though there seems to be very little
resistance.

> >     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.
>

I think we could probably work something out here, will have to talk
to others about this though. One thing that I think does make a lot of
sense is the settings plugin being in core (individual backends can
still be plugins). After we transitioned to this we also started using
an is_active setting on each plugin rather than a_active_plugins.

> > 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.

I will write again once I have a chance to talk to other members of
the community again.

Thanks,
Robert