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

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15-03-11 16:53, Tom Rini wrote:
> On 03/15/2011 02:38 AM, Frans Meulenbroeks wrote:
>> 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.
> 
> Thanks.
> 
>>>> 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
> 
> One more agenda topic :)
> 
>>>> 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)
> 
> I don't see this happening as you don't use meta-oe by itself but
> oe-core + meta-oe (+ possibly more).
> 
>> 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).
> 
> Right.  The default case isn't "throw it in meta-oe" when there's a new
> version but "is someone volunteering to take this into meta-oe because
> they need it".
> 
>> 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
> 
> It's up to however meta-oe wants to run things.  It sounds like the
> desire is that if people are active and things work, it's fine to have
> things in meta-oe.
> 
>>>> 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.
> 
> So, using a recent example.  policykit dropped needing eggdus build.

FWIW, in the GNOME world anything with 'egg' in its name is a tech
that's in an incubation stage and scheduled to get merged into e.g.
libgnome, gtk, glib-2.0, etc. So if we stick to even releases we
shouldn't be needing any eggs. In a perfect world, that is :)

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFNf5JhMkyGM64RGpERAtQQAJ0fiVfoQgrwGsiv/IoJ0teB1qA76wCcDTAM
hHo9KrP5MvGUrs9tx6/gZCo=
=LMEy
-----END PGP SIGNATURE-----