[oe] Plans for OE classic future

[Frans Meulenbroeks]

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.
And it should be clear what goes in and how it should be done (and not like
in some other place where it seems to be left to the discretion of the pull
god, note that I am quite happy with the way you do your job).

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

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

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.

Frans