[oe] Plans for OE classic future

[Tom Rini]

On Sun, Nov 27, 2011 at 3:12 AM, Frans Meulenbroeks
<fransmeulenbroeks at gmail.com> wrote:
> 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.

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

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

-- 
Tom