[oe] Plans for OE classic future

[Frans Meulenbroeks]

2011/11/27 Tom Rini <tom.rini at gmail.com>

> On Sun, Nov 27, 2011 at 3:12 AM, Frans Meulenbroeks
> <fransmeulenbroeks at gmail.com> wrote:
> > Personally I think we are not yet at at point where we should move OE
> > classic to a pull/patches model. Give it some time.
>
> So, why are we not at that point yet for OE classic?  I'd like to
> think I've been timely in my pulls.
>

I'm not saying you are not timely. Au contraire, you are.

>
> > I understand the concerns with people using master for new projects, but
> I
> > also understand the concerns of people that for one reason or another are
> > still bound to oe-classic.
> >
> > I feel that it also would be helpful to have some sort of staging area
> > where people can update things before they are pulled. Doing that
> > distributed not really creates visibility to those changes, so I'd say it
> > is better to keep that centralized. Might even be more convenient too.
>
> We already have this for oe-core/meta-oe so it shouldn't be hard to
> make up a contrib repo for classic OE, for folks that don't want to
> just fork the mirror on github.
>

Whether it is a branch or a separate repo does not make too much of a
difference (at least not to me).
It was my impression that a branch would work a little bit simpler, but I
may well be mistaken here.

>
> > That still leaves the issue of new projects.
> > What if we decide to rename master to e.g. maintenance-staging, or
> legacy,
> > or classic or whatever you want to; keeping it as it is now (so not R/O),
> > and have a new master that is R/O and only contains a document with some
> > explanation and referring to oe-core for new projects. This doc could
> > mention the legacy branch together with a statement that it is not
> desired
> > for new projects, but mainly there for maintenance/testing purposes.
>
> The only part here I object to is saying we need an anyone-can-write
> branch.
>

If it is a contrib repo or overlay fine with me.
I do think it is probably convenient that it should be an
anyone-who-is-authorized-can-write repo/overlay/branch/whatever, in order
not to unneededly raise the barrier to submit patches.

Frans