Re: Yocto Project and OE - Where now?

[Frans Meulenbroeks <fransmeulenbroeks@gmail.com>]

2011/1/18 Mark Brown <broonie@sirena.org.uk>:
> On Tue, Jan 18, 2011 at 06:05:41AM -0200, Otavio Salvador wrote:
>> On Tue, Jan 18, 2011 at 05:21, Graeme Gregory <dp@xora.org.uk> wrote:
>
>> > OE is not a distro so this is a non starter already, please don't bog
>> > down this discussion by re-opening this again. Angstrom 2008, Angstrom
>> > 2010, kaelios and slugos are all released distributions with different
>> > versions of apps just as a starter and they arent even near the total
>> > number of distros in OE.
>
>> I disagree. I think having too many versions of a package just makes
>> difficult to get things done:
>
>>  - it increases the amount of maintainence work;
>>  - has a bigger time to get bugs spoted;
>
>> Users of old distros ought to use a specific repository and branch.
>> Master ought to be kept clean for 'next distro release'.
>
> I don't think there's a massive conflict between the idea that it's a
> good idea to keep the number of versions that are maintained limited and
> the idea that the limit on the number of versions being maintained
> should be greater than one which seems to be all that's being said here.

To make things a little bit clearer.
I am not opposed to multiple versions per se.
I have a concern wrt maintenance though, and that is one of the
reasons I prefer a limited number of recipes.

As a recipe maintainer I feel that I do not need to carry the burden
caused by a decision of a distro for a specific version of a recipe.
E.g. if I maintain package foo, and that package is at version X and
upstream moves to version Y, I think it is part of the responsibility
of the recipe maintainer to move to Y (after testing of course).
However if Y is proven to be stable, generally as a maintainer I want
to retire X (unless there are compelling reasons to keep it, e.g.
because heavily changed functionality or incompatible api's or so).
If a distro feels it wants to stay at X, I have no problem with that,
but I feel that distro should also take over the maintenance
responsibility (and retire X if it is not used any more). Don't put
the burden of your choices onto someone else!
I have neither the time or the interest to support a substantial
number of variants that IMHO are outdated. If someone else feels (s)he
wants to keep using them, feel free, but then also please take the
maintenance burden.

Unfortunately some of our developers have a habit of creating lots of
new recipes but rarely clean up (but also do not maintain the old
stuff), leaving a trail of undefined/orphaned recipes.
I think we should try to avoid having those orphaned recipes.

Wrt the example of Graeme on abiword (not sure if it was here or on
irc). His reasoning was that he wanted to keep an older version
because it was much smaller. Being in the business of resource
constrained embedded systems I clearly understand this. However I feel
it is better to make that explicit, e.g. by introducing a recipe
foo-small_X.bb adjacent to foo_Y.bb (or maybe even foo_X.bb), than to
have it implicit (like in the case foo_X.bb and foo_Y.bb).
In a few cases we already do so, but typically then it is
function/interface driven. bluez vz bluez4 comes to mind.

Thinking of it, we could also go for a "previous" layer or so where we
move older versions to. Those who want them then can add that layer,
those who do not want them do not include that layer.

Frans.