[oe] Plans for OE classic future

[Frans Meulenbroeks]

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

>
>
> So the question is, what is the long term plan for classic OE based
> stuff?  The TSC has been saying, perhaps not with enough voice or
> emphasis:
> - 2011.03 is the last "release" of oe.dev (unless someone(s) step up
> and wish to do another!)
> - 2011.03-maintenance will be maintained as long as people are saying
> they have a need for it.
> - The master branch needs to go away somehow as the last step of
> migration.  This is what I was trying to say below...
>
> >> In my mind, we couldn't do a technical branching of the repository, we
> >> made a new one. But people are still working off of a branch made
> >> against an 8 month old snapshot.  We really want to encourage this to
> >> stop.  If we were all in one repository still, it would be people
> >> saying "don't make legacy/main read-only!  I still want to add things
> >> to it!".
> >
> > I did not understand that paragraph. Sorry.
>
> The analogy I'm trying to make between classic OE master branch and
> behavior is that it wasn't "lets start from scratch with this new
> repository and hope someday most people stop using the old tree" it
> was "if we could cleanly do a 'git branch -m master legacy' and start
> master as the new meta-oe repository, we would".
>
> Now I'm going to make a Linux Kernel analogy.  The 2.4 series didn't
> (nearly) go away for a long while after 2.6 came out, but after a
> while the rules for what could go in got rather restrictive.
>
> The direction the TSC has recommended for how to deal with classic OE
> is to have the folks that can't yet move off of it be using the
> maintenance branch.  It's not going to be pulled out from under
> anyone.  It's just got rules about what kind of changes are allowed
> in.  Today that's "must exist in relevant oe-core based layer or be
> N/A in that world".  I can't imagine that changing until the user base
> is small enough and themselves in a maintenance mode to be happy with
> that too.
>
> If anything it seems like there's an objection to switching classic OE
> from "free for all" to the pull request (or patches posted) model
> oe-core/meta-oe/etc are using.
>
> 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.

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.

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.

Frans.