[oe] Plans for OE classic future

[Tom Rini]

On Sun, Nov 27, 2011 at 2:58 PM, Frans Meulenbroeks
<fransmeulenbroeks at gmail.com> wrote:
> 2011/11/27 Tom Rini <tom.rini at gmail.com>
>
>> 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?
>>
>
> My whole point is that things should be easy for those who want to
> contribute.

Agreed.  And I think based on the volume going into
oe-core/meta-oe/etc today, folks have found the contrib tree model to
work.  And again, if it's not working, people need to be speaking up
:)

>> >> > 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.
>>
> I can't comment on that as I have no knowledge on the server side. I'm
> looking at it from a user/contributor perspective.

Yes, lets leave this part up to the admins, I'm just inferring from
how it's setup today.

>> >> > 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?
>>
> Sorry but since all my projects are still based upon oe-classic, I never
> bothered to peek at those.
>
> Anyway these are my opinions. There were some others that had concerns. Not
> sure how they feel about it.
> And it is good that we come to a plan and define a workflow and a migration
> path.

Yes, lets make sure everyone else has a chance to voice their opinion.
 And while the details are in various emails (and I should summarize
before we say this is it), at the high level:
- Be more like oe-core/meta-oe in that we have contrib repositories
(or self hosted or github or gitorious or ..) and pull requests for
changes going into 2011.03-maintenance (note that pull requests are
the rule today)
- Get everyone else who is doing projects based on OE classic 'master'
to either be fine with no more changes at some point OR migrate to
2011.03-maintenance and as always, I'm happy to review pull requests
of N commits worth of backports of changes from master, or wherever
else, to make that migration work for a given project.
- Get public documentation to reflect the reality of
oe-core+meta-oe+$stuff going forward, 2011.03-maintenance for OE
classic that's receiving some amount of updates and that master and
2011.03-maintenance are strongly cautioned against for new projects.
- Make sure meta-oe policy is documented in cases where it diverges
from oe-core, so everyone is clear.

> The original statement by someone saying "OE classic will be R/O soon", was
> a little bit too quick and too incomplete for the community I think. At
> least it was for me.

Yes, I agree this was a needed conversation.  With my TSC hat on, I
think we were just waiting to see if anyone needed more than notice of
a date in the future.

-- 
Tom