On the speed of removing ecipes

[Richard Purdie]

On Sat, 2010-08-21 at 13:17 +0200, Frans Meulenbroeks wrote:
> 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).

Please understand what the TSC asked - slow down a bit with the commit
process, let changes be exposed to more review and testing. We did not
say don't do it, just to please be careful.

In the openssl case there are issues switching to 1.x.y compared to the
0.9.x series and there is a very good reason to keep the last 0.9.x
version around and removing it caused a lot of work for others.

> 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.

Creating a branch is fine, you then let it wait for review and testing,
say two weeks, you then merge. "two weeks" is a guideline only. Some
changes take longer, it depends how invasive they are.

If the changes are bad, it may be it doesn't merge but there would be a
good reason for that. Most of the time we learn from branches even if
they don't merge.

> (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).

The TSC is not here for guidance on every specific detail to do with
development. If you've asked and didn't hear objections, you can proceed
with caution. Both these issues sound like sensible things to address
with caution. One large block commit might not be the best way - perhaps
start on some recipes and work though a list over a period of a few
weeks. Any issues that are seen as you go and then be learnt from in the
latter commits.

Cheers,

Richard