[oe] TSC Meeting 2010/03/02

[Frans Meulenbroeks]

2010/3/5 Rolf Leggewie <no2spam at nospam.arcornews.de>:

[...]
>
> Frans, I hope I did not paraphrase your sentiments incorrectly.  Feel
> free to correct me if I did.

You didn't :-)

I've indeed come to the conclusion that apparently OE has come to a
point where it is very hard to move forward.
One of the reasons is the perception of quality for some people.

Quality to me does not mean having 26 glib recipes around or 8 abiword
ones or whatever most of which are likely to be unused and even more
likely to be unmaintained.
We currently have close to 9000 recipes, 3000+of which are older versions.
I understand why people feel they should keep old versions, but that
is where a version control system is for.

Development head should reflect the latest state-of-the-art, and
probably should have only one version per recipe.
(probably with the exception of things like gcc, linux and u-boot).
If things do not work with a version, they should be fixed. Keeping
the old version around and pin it, means that in the end you end up
with a system which is lagging behind.

If you want stability use a stable branch. head should focus on moving forward.

Some people seem to think differently about it. As an alternative an
obsolete directory has been proposed.
The latter does not really help. It gives the crud a home, but it does
not really solve the problem.

However as discussions on what to remove are time consuming and
progress is hard, I have abandoned that path.

Instead I decided to create a branch called sanity (for now local, but
once it is more reliable I'll probably push it)
In this branch I intend to
- remove all old versions of recipes (sometimes tough as there are
recipes that have both numbered and cvs/svn/git variants (I believe
there is a case where there is even cvs and svn for package))
  exceptions: gcc (but some versions will go there), linux, u-boot)
- crude convert to BBCLASSEXTEND="native". I feel this should in
general work. (btw and I noticed we have packaged that do have native
variants for older versions but not for the recent one, and I have
even seen a case where the native recipe is newer than the target
one).
Plan was also to remove all do_deploy stuff, but apart from
u-boot/linux this is nearly done.

Note that the above edits may sound harsh, but frankly I doubt that
anyone will ever convert those 3000 legacy devices, and even if they
are converted, I strongly doubt that they are tested.
This seems to be a better way forward.

After that I have some ideas for further improvements, but let's get
this started first.

If anyone wants to work with me on this, feel free to get in touch with me.
And for those who feel that effort should be directed elsewhere. Make
me an interesting offer and we can talk. But until that it are my
weekends and evenings I am spending on this, and I'll spend them as I
see fit, not as someone else sees fit (ok, with the exception of the
Mrs :-) )

Have fun!
Frans