[oe] Plans for OE classic future

Tom Rini tom.rini at gmail.com
Sun Nov 27 18:25:55 UTC 2011


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

OK.  So provided we have an easy way to make pull requests of trees
hosted on oe.org (like oe-core/meta-oe today), are there any other
objections to moving towards pull request model for classic OE?

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

My understanding of the git server side of things is a contrib repo is
easier to setup and manage permission-wise.

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

So, like we do today for openembedded-core-contrib / meta-openembedded-contrib?

-- 
Tom




More information about the Openembedded-devel mailing list