[oe] Discussion: Version retention policy in oe-core

[Frans Meulenbroeks]

Tom, thanks for the reply.

2011/3/15 Tom Rini <tom_rini at mentor.com>:
> On 03/14/2011 11:52 AM, Frans Meulenbroeks wrote:
>>

[cut out large part of text]

>> Overall this seems like a fine proposal to me. Thanks a lot for drafting
>> it.
>>
>> There are a few minor suggestions I would like to make.
>>
>> First is to define which components are considered to be critical, as
>> for what is non-critical for one person might be critical for someone
>> else.
>> Leaving this open is bound to lead to discussion and disagreement
>> later on, perhaps better be clear about it upfront.
>
> We see that as outside of the scope of this policy but I agree it needs to
> be settled up, at least as a starting point sooner rather than later.  So
> that we don't forget, please ask us to put this on the agenda.

I agree that that is outside the policy (but within the TSC domain).
I'll bring it up when I see the agenda.
Note that I am quite busy tomorrow so it might be (my) thursday
morning before I get to that.
>
>> Second is the location of deprecated recipes.
>> As far as I know we haven't clearly defined what goes into meta-oe.
>
> Well, that's up to OE at large, including how it's run.  We're just setting
> out how the core should work right now.

I understand, but as said before this is also a topic for the TSC
>
>> I have assumed that this is one layer that will (also) contain recipes
>> that are not part of oe-core.For example a recipe for a UPnP server or
>> a CD recording program.
>
> Correct.  We expect meta-oe to continue to hold things that are not
> essential but are useful and not distribution specific.
>
>> Mixing deprecated oe-core and mainline non-core recipes in the same
>> tree will probably lead to confusion and perhaps even to people trying
>> to upgrade deprecated recipes in meta-oe.
>
> Why?  If meta-oe doesn't need something that's deprecated in the core it
> shouldn't take it on.  If it does need something deprecated, we should try
> and figure out what can be done about that in order to fix that, or live
> with it (which is to say, if package A depends on package B no newer than
> version 2.0 and package B is now up to 3.2, is package A something that's
> really worth keeping?  Or should it perhaps go away?

Well there are two things I like to avoid.
First one is someone seeing a deprecated OE-core recipe in meta-oe.
Say this recipe is at 1.X. The person seeing this knows that upstream
is at 1.Y (Y > X), but is not aware that this recipe (and maybe 1.Y)
is in oe-core and starts to work at it.
Only later (e.g. when submitting changes) (s)he learns that actually
the newer version is in OE-core, and that all the work is wasted
timel. This is not an encouraging experience).
I think it would help if people are alerted that a newer version
exists in oe-core)

The second one is that we have many versions of the same recipe and no
one really cares or maintains these old versions. (if they are
maintained and used I have no objections against multiple versions,
but I am somewhat allergic to recipes that are kinda orphaned and
sometimes do not even build).

Btw that raises the following question: if a distro wants to pin (for
whatever reason) a certain recipe, but that version is not really
needed by other packages or so, does it still live in meta-oe? or
should it then eventually move into a distro specific overlay? I'm
especially thinking about distro's that are not too active in updating
their pinnings
>
>> In order to avoid that confusion is is probably better to give the
>> deprecated oe-core recipes their own layer (e.g. old-oe-core).
>
> If something isn't needed, we don't want to have to carry it anywhere other
> than in the scm history.  If it's needed, it should be somewhere active so
> it can be used.  We can re-evaluate this at a later point in time if it's
> not working, but we discussed this and that was our conclusion (that's my
> recollection at least, the log can be checked over if needed).

I'm not sure if I saw the last log.
Key in your remark is what defines "needed".
Also what I often see is that things are needed, but after a while
become unneeded and become somewhat orphaned.
>
>> Apart from the above I feel it would be good if the TSC would discuss
>> the location of OE recipes that are non-core, and also draft a
>> retention policy for that location.
>
>> This might of course be similar or identical to the oe-core one.
>
> So that we don't forget, please reply to the next TSC meeting agenda (which
> should be sent out sometime Wednesday, iirc) and it'll get put on the list.

will do.

Thanks for your reply.
Frans