Tom, thanks for the reply. 2011/3/15 Tom Rini <[email protected]>: > 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 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
