On the speed of removing ecipes

[Frans Meulenbroeks]

2010/8/21 Holger Hans Peter Freyther <holger at freyther.de>:
> Hi Frans,
>
> to make this really short. We got a complain about the speed of removals (e.g.
> the lack of time to review, test). RP, mickeyl and me were able to assemble
> (simple majority) and we would like to ask you to allow some more review to
> happen before pushing removals.
>
> The way you could do it:
>        - Post the patches...
>        - Post the URL to the branch
>        - Update removal.txt with the recipes you will remove and wait..
>        - something else appropriate...
>
> thanks a lot for all your efforts
>
>        holger
>

Hi Holger, TSC,

Thanks for your email.

I already understood that maybe I was too enthousiast.
I started removing stuff about two weeks ago, no one complained, so I moved on.
As last sunday the weather here was not too good, and I had a long
build running, I gave it a bigger stab, and unfortunately there was
some fallout (which I repaired as soon as I could).

Anyway, although I did my best to stay within the guidelines of the
TSC from may, I can understand that the massiveness created some
dismay.

The issue wrt removal is (imho) that a few people seem to mistake
quantity for quality and feel that having many recipes (whether or not
maintained and whether or not they build) is good.

The TSC has decided that we should work to merging target and native
recipes and to remove legacy staging.
However if you ask the people who are against removal of old recipes
whether they are willing to remove legacy staging and merge recipes,
the answer is a deafening silence :-(

I hope the TSC will allow me to do small scale removal of recipes (in
compliance with the may guidelines, if it contributes to the goal of
reducing the number of native recipes and removing legacy staging.
I'd rather do that without publishing patches and reviewing (as that
makes the already quite boring and timeconsuming process substantailly
more boring and timeconsuming).

Making a branch is possible, but before working in that direction  I
would like to have some understanding that at some point in time the
branch will be merged (or at least cherry-picked).
I have already tried to make such a branch in march, but apparently at
that point in time there was little to no interest.

(and on a personal note: I'd say that if we want something that is
maintainable we should limit the # of variants for each recipe (and
e.g. having 12 or so versions of abiword does not really seem useful).
(although I fully understand we have quite some versions of gcc,
kernel, u-boot, glibc etc around) )

While going off my soapbox, I want to take the opportunity to ask the
TSC on suggestions on how to proceed wrt 2 issues I raised on the
mailing list. Issues that hardly got any feedback.

The first one is the removal of unused files in conf/distro/include.
See http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-August/022696.html
Martin already did the X11 includes. Also I got indications that a few
ones are better kept. What about the other ones?
It is mainly preferred-gpe-versions-2.6.inc,
preferred-gpe-versions-2.7.inc and maemo-preferred.inc. These are > 4
year old, not used by any distro and apparently not maintained.

The second one is the removal of unused files in the recipes
directory. http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-August/022849.html
I'm not sure how to to proceed here. I've posted the list, got hardly
feedback, should I go ahead and rm these files (after double checking
that they are unused)?
If so, in one batch? file by file? dir by dir? If not, what is the
preferred way forward?
(btw copying to obsolete is somewhat tricky due the the directory
names involved).

Please advise.
Frans (and don't forget: have fun!)