[oe] Plans for OE classic future

[Tom Rini]

On Sat, Nov 26, 2011 at 9:11 AM, Frans Meulenbroeks
<fransmeulenbroeks at gmail.com> wrote:
> 2011/11/25 Tom Rini <tom.rini at gmail.com>
>
>> On Thu, Nov 24, 2011 at 1:33 PM, Paul Menzel
>> <paulepanter at users.sourceforge.net> wrote:
>> > Am Donnerstag, den 24.11.2011, 09:06 -0800 schrieb Khem Raj:
>> >> On (24/11/11 10:31), Frans Meulenbroeks wrote:
>> >> > 2011/11/24 Koen Kooi <koen at dominion.thruhere.net>
>> >> >
>> >> > > OE .dev will go read-only soon, If you need an OE-classic setup,
>> >> > > 2011.03-maintenance is there for you.
>> >> >
>> >> > As stated before there are still people using .dev and committing to
>> it
>> >> > [1], and there are people interested in keeping it that way for a
>> while.
>> >> > So as it stands I suggest to keep it open for a while for those that
>> still
>> >> > are interested to use it.
>> >>
>> >> I would suggest that people interested in oe classic should use 2011.03
>> >> branch since its maintained and tested regularly. Its in their best
>> >> interest too since there are people behind the branch and it gets
>> >> regular bug fixes thats not true for master.
>> >
>> > That statement is not true as far as I can see from the commit log.
>> > Almost all patches to 2011.03-maintenance went through master.
>>
>> Yes, but that's also due, in general to the nature of the branch.
>> Angstrom/TI related stuff was going master->2011.03-maintenance before
>> I clarified that coming from oe-core is also fine.  As of yet, no one
>> else has stepped up and said "I need DISTRO=foo MACHINE=bar working
>> here, and I intend to keep an eye on things".  Having angstrom-2008.1
>> in there seems to be good enough for most cases.
>>
>
> Forgot to mention this in my previous email, but I do have an interest in
> minimal and minimal-uclibc for mpc8313. Then again virtually all of my work
> is console only, so I'm not really into a position to test lots of things.
> I'm keeping an eye on things though and have one or two patches pending
> (e.g. our current netsnmp version and uclibc do not seem to be friends).
> Personally I prefer to commit these patches to master and issue a pull
> request for them and I prefer it if others do the same, so we have a
> centralized location, instead of a gazillion git trees at several places.

Well, today oe.master isn't read-only.  But tomorrow do you want to go
and fix these problems again in oe-core?  Most of us do not and have
already gone through the pain of "oh, I need to bring this change, and
this change, and ...." into oe-core+meta-oe.

But, perhaps we're running into a naming problem.  What I see as the
direction the TSC wants things to go is that development is done
against oe-core+meta-oe+etc, people that need classic OE, for
historical interests (history, reproducing old builds) have somewhere
to pull from.  And that legacy projects have somewhere to work against
until they can migrate to oe-core.  We want to discourage development
in the OE classic tree.  A 'git cherry' showed 250-odd changes in
oe.dev master not in the maintenance branch, which is pretty good.
The issue right now is we have two choices for the legacy projects use
case, master and 2011.03-maintenance.  Some places have chosen the
maintenance branch and some have chosen master, and we'd like to unify
that.

-- 
Tom