[RFC] renaming packages/ to recipes/

[RFC] renaming packages/ to recipes/

[Koen Kooi]

Hi,

I keep trying to teach people the difference between recipes (what's in 
OE) and packages (what you install on the target) and keep getting 
reactions like "ok, but why is the dir called packages?", which are 
completely valid.

Proposal:

mv packages recipes ; git commit .

While it would make setting up OE more intuitive, it does mean that 
people have to adjust local.conf and distro people need to update their 
installation instructions.

I have some other intrusive proposals about shuffling things around in 
TMP a bit (and out of TMP as well), standardizing on source locations 
for source_distribute and sourcepkg, etc, but let's start with this easy 
one.

The main motivation for all this is to make the next stable branch 
easier to grasp for newbies than the current OE structure.

regards,

Koen

Re: [RFC] renaming packages/ to recipes/

[Henning Heinold]

On Wed, Feb 25, 2009 at 09:21:32PM +0100, Koen Kooi wrote:
> Hi,
>
> I keep trying to teach people the difference between recipes (what's in  
> OE) and packages (what you install on the target) and keep getting  
> reactions like "ok, but why is the dir called packages?", which are  
> completely valid.
>
> Proposal:
>
> mv packages recipes ; git commit .
>
> While it would make setting up OE more intuitive, it does mean that  
> people have to adjust local.conf and distro people need to update their  
> installation instructions.
>
> I have some other intrusive proposals about shuffling things around in  
> TMP a bit (and out of TMP as well), standardizing on source locations  
> for source_distribute and sourcepkg, etc, but let's start with this easy  
> one.
>
> The main motivation for all this is to make the next stable branch  
> easier to grasp for newbies than the current OE structure.
>
> regards,
>
> Koen

+1 from me.

Bye Henning

Re: [RFC] renaming packages/ to recipes/

[Koen Kooi]

On 25-02-09 21:21, Koen Kooi wrote:

> I have some other intrusive proposals about shuffling things around in
> TMP a bit (and out of TMP as well), standardizing on source locations
> for source_distribute and sourcepkg, etc, but let's start with this easy
> one.

What I meant to say is:

Let's bunch up all the proposals that get approved so we can have a flag 
day in a week or 3 to minimize documentation churn.

regards,

Koen

Re: [RFC] renaming packages/ to recipes/

[Denys Dmytriyenko]

On Wed, Feb 25, 2009 at 09:21:32PM +0100, Koen Kooi wrote:
> Hi,
>
> I keep trying to teach people the difference between recipes (what's in OE) 
> and packages (what you install on the target) and keep getting reactions 
> like "ok, but why is the dir called packages?", which are completely valid.
>
> Proposal:
>
> mv packages recipes ; git commit .
>
> While it would make setting up OE more intuitive, it does mean that people 
> have to adjust local.conf and distro people need to update their 
> installation instructions.

+1 - the whole directory structure needs some revamping. There are also some 
inconsistencies with meta, images and tasks directories. But it is good to 
start with small and easy items first.

> I have some other intrusive proposals about shuffling things around in TMP 
> a bit (and out of TMP as well), standardizing on source locations for 
> source_distribute and sourcepkg, etc, but let's start with this easy one.

Speaking of TMP and outside of it - does it make sense to have DEPLOY outside 
of TMP by default in OE? I do it in Arago, but I had to make a small fix in 
base.bbclass though - see bug #4580.

-- 
Denys

Re: [RFC] renaming packages/ to recipes/

[Mike (mwester)]

Koen Kooi wrote:
> On 25-02-09 21:21, Koen Kooi wrote:
> 
>> I have some other intrusive proposals about shuffling things around in
>> TMP a bit (and out of TMP as well), standardizing on source locations
>> for source_distribute and sourcepkg, etc, but let's start with this easy
>> one.
> 
> What I meant to say is:
> 
> Let's bunch up all the proposals that get approved so we can have a flag
> day in a week or 3 to minimize documentation churn.

Good timing; I was just composing a separate RFC email, but instead I'll
add my thoughts to this thread, since what I will propose is very
similar to the "flag day" idea.

I'd like to propose that we adopt a monthly "Big Change Window" (insert
your favorite term instead, if you wish).  Many organizations do this to
manage changes to shared branches.  The idea is that non-critical, but
potentially disruptive, changes are all merged to the dev branch during
standard time-periods (e.g. the first week of each calendar month).

This would set expectations for all users and even the core developers;
don't sync during these periods if you aren't ready, or perhaps some
folks might make the decision about working on a branch or not based on
the proximity of the Big Change Window.

(BTW, +1 on the renaming of packages to recipes)

-Mike

Re: [RFC] renaming packages/ to recipes/

[Koen Kooi]

On 25-02-09 21:41, Denys Dmytriyenko wrote:

> Speaking of TMP and outside of it - does it make sense to have DEPLOY outside
> of TMP by default in OE? I do it in Arago, but I had to make a small fix in
> base.bbclass though - see bug #4580.

That's exactly what I'm talking about :) I was thinking of a structure 
like this:

/OE/org.openembedded.dev # metadate
/OE/conf # local.conf, auto.conf, site.conf
/OE/tmp # work/ stamps/ cache/ rootfs/
/OE/target # ipk,deb,rpm/ images/
/OE/build # staging, cross, pstage packages
/OE/downloads # DL_DIR

That just leaves finding a place for sdk output and things like 
sourcepkg and source_distribute.

This isn't an RFC yet, since I haven't worked it all out yet, but don't 
let that stop you from sending in an RFC :)

regards,

Koen

Merge windows, was: Re: [RFC] renaming packages/ to recipes/

[Koen Kooi]

On 25-02-09 21:48, Mike (mwester) wrote:

> I'd like to propose that we adopt a monthly "Big Change Window" (insert
> your favorite term instead, if you wish).  Many organizations do this to
> manage changes to shared branches.  The idea is that non-critical, but
> potentially disruptive, changes are all merged to the dev branch during
> standard time-periods (e.g. the first week of each calendar month).

I like the idea, but I'd like to change it slightly:

All disruptive changes that have been tested and review get merged 
during this window.

I can see it ending up as "commit random shit window", which we do not want.

What are your thought on keeping a document that lists the (planned) 
merge time of disruptive branches together with a short description of 
their aim and impact?

Related to that: a NEWS file would be neat as well, but that's only 
needed when we start doing releases based on the stable branch

regards,

Koen

Re: Merge windows, was: Re: [RFC] renaming packages/ to recipes/

[Michael 'Mickey' Lauer]

Sounds good for me on a stable branch, not so much on a development
branch. Or we might as well go with org.openembedded.{stable|testing|
unstable}...

-- 
:M:

Re: Merge windows, was: Re: [RFC] renaming packages/ to recipes/

[Koen Kooi]

On 25-02-09 22:15, Michael 'Mickey' Lauer wrote:
> Sounds good for me on a stable branch, not so much on a development
> branch.

A perptually broken development branch is no good. The current .dev is 
unbuildable literally every other day, so I'm not a fan of keeping .dev 
the free-for-all it is now.
And Mikes proposal was holding off *disruptive* changes, not *all* changes.

regards,

Koen

Re: Merge windows, was: Re: [RFC] renaming packages/ to recipes/

[Otavio Salvador]

Koen Kooi <k.kooi@student.utwente.nl> writes:

> On 25-02-09 22:15, Michael 'Mickey' Lauer wrote:
>> Sounds good for me on a stable branch, not so much on a development
>> branch.
>
> A perptually broken development branch is no good. The current .dev is
> unbuildable literally every other day, so I'm not a fan of keeping
> .dev the free-for-all it is now.
> And Mikes proposal was holding off *disruptive* changes, not *all* changes.

[...]

Yes from my POV it does make sense and it could also help derivatives to
plan their development according to it.

For example if you have a distro that is based on dev branch you should
avoid merging it at start of mounth since it has high risk to be broken
or with still unknown bugs.

With GIT it is quite easy to hold changes for a while and merge them all
together when done. We could even build a "oe-next" try that merges
automatically from people trees and catch conflicts. This could make
whole merging easier when next mounth arrives ;-)

Cheers,

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: [RFC] renaming packages/ to recipes/

[Sledz, Steffen]

> Speaking of TMP and outside of it - does it make sense to 
> have DEPLOY outside of TMP by default in OE? I do it in
> Arago, but I had to make a small fix in 
> base.bbclass though - see bug #4580.

+1

Re: [RFC] renaming packages/ to recipes/

[Martyn Welch]

Koen Kooi wrote:
> Hi,
> 
> I keep trying to teach people the difference between recipes (what's in 
> OE) and packages (what you install on the target) and keep getting 
> reactions like "ok, but why is the dir called packages?", which are 
> completely valid.
> 
> Proposal:
> 
> mv packages recipes ; git commit .
> 

+1

Martyn
-- 
Martyn Welch MEng MPhil MIET (Principal Software Engineer)   T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd,        |Registered in England and Wales
Tove Valley Business Park, Towcester,      |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB  VAT:GB 729849476

Re: Merge windows, was: Re: [RFC] renaming packages/ to recipes/

[Yuri Bushmelev]

Hello!

> Related to that: a NEWS file would be neat as well, but that's only
> needed when we start doing releases based on the stable branch

Look at FreeBSD UPDATING file too:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/UPDATING?rev=1.780;content-type=text%2Fplain

This file describes big changes in ports to warn users. It recommended to 
read this file before doing upgrade. We can use this idea too.

-- 
Yuri Bushmelev

Re: [RFC] renaming packages/ to recipes/

[Marcin Juszkiewicz]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

On Wednesday 25 of February 2009 21:21:32 Koen Kooi wrote:
> Proposal:
>
> mv packages recipes ; git commit .

+1 from me

My addition to this:

mkdir recipes-broken
git add  recipes-broken
git mv recipes/obsolete recipes-broken/obsolete
git mv recipes/nonworking recipes-broken/nonworking

As this will allow users to set:

BBFILES = "/somewhere/oe/recipes/"

which is supported by BitBake for years.

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 204 bytes --]

Re: [RFC] renaming packages/ to recipes/

[Robert Schuster]

[-- Attachment #1: Type: text/plain, Size: 107 bytes --]

Hi,

Koen Kooi schrieb:
> Proposal:
> 
> mv packages recipes ; git commit .
+1

Regards
Robert


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 268 bytes --]

Re: [RFC] renaming packages/ to recipes/

[Bernhard Guillon]

Marcin Juszkiewicz wrote:
> On Wednesday 25 of February 2009 21:21:32 Koen Kooi wrote:
>   
>> Proposal:
>>
>> mv packages recipes ; git commit .
>>     
>
> +1 from me
>
> My addition to this:
>
> mkdir recipes-broken
> git add  recipes-broken
> git mv recipes/obsolete recipes-broken/obsolete
> git mv recipes/nonworking recipes-broken/nonworking
>
>   
I like this idea. But we should add a description file to the recipe on 
which arch it is broken or why it is obsolete.
A package tested and working for arch x can break on arch y easily. E.g. 
if it uses netlib floating points.

Best regards
Bernhard Guillon

Re: [RFC] renaming packages/ to recipes/

[Leon Woestenberg]

Hello,

On Wed, Feb 25, 2009 at 9:21 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> mv packages recipes ; git commit .
>
if (i < MAX_INT) i++;

Regards,
-- 
Leon

Re: [RFC] renaming packages/ to recipes/

[Yuri Bushmelev]

В сообщении от Четверг 26 февраля 2009 Bernhard Guillon написал(a):
> Marcin Juszkiewicz wrote:
> > On Wednesday 25 of February 2009 21:21:32 Koen Kooi wrote:
> >> Proposal:
> >>
> >> mv packages recipes ; git commit .
> >
> > +1 from me
> >
> > My addition to this:
> >
> > mkdir recipes-broken
> > git add  recipes-broken
> > git mv recipes/obsolete recipes-broken/obsolete
> > git mv recipes/nonworking recipes-broken/nonworking
>
> I like this idea. But we should add a description file to the recipe on
> which arch it is broken or why it is obsolete.
> A package tested and working for arch x can break on arch y easily. E.g.
> if it uses netlib floating points.

Here is other example from FreeBSD project - MOVED file:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/MOVED?rev=1.1803;content-type=text%2Fplain

It contains information about package movement/removal in ports tree.

Just as example :)

-- 
Yuri Bushmelev

Re: [RFC] renaming packages/ to recipes/

[Rolf Leggewie]

Bernhard Guillon wrote:
>> mkdir recipes-broken
>> git add  recipes-broken
>> git mv recipes/obsolete recipes-broken/obsolete
>> git mv recipes/nonworking recipes-broken/nonworking

+1

> I like this idea. But we should add a description file to the recipe on 
> which arch it is broken or why it is obsolete.

Oh no, please no.  Not yet another file which people will ignore ;-) 
That is what the commit message and "git log 
recipes/obsolete/$somepackage" is for.

Re: [RFC] renaming packages/ to recipes/

[Koen Kooi]

On 25-02-09 21:21, Koen Kooi wrote:
> Hi,
>
> I keep trying to teach people the difference between recipes (what's in
> OE) and packages (what you install on the target) and keep getting
> reactions like "ok, but why is the dir called packages?", which are
> completely valid.
>
> Proposal:
>
> mv packages recipes ; git commit .

Only positive replies sofar, so when do we want to schedule this commit? 
My proposal is somewhere in april, since I'm too busy this month with 
bossaconference and university work to deal with the fallout properly.
Also, shall we restructure TMPDIR at the same time?

regards,

Koen

Re: [RFC] renaming packages/ to recipes/

[Andrea Adami]

>I have some other intrusive proposals about shuffling things around in TMP a bit (and out of TMP as well), standardizing on
> source locations for source_distribute and sourcepkg, etc, but let's start with this easy one.

+1

bump

Andrea

Re: [RFC] renaming packages/ to recipes/

[Tom Rini]

On Wed, Mar 04, 2009 at 12:16:48PM +0100, Koen Kooi wrote:
> On 25-02-09 21:21, Koen Kooi wrote:
>> Hi,
>>
>> I keep trying to teach people the difference between recipes (what's in
>> OE) and packages (what you install on the target) and keep getting
>> reactions like "ok, but why is the dir called packages?", which are
>> completely valid.
>>
>> Proposal:
>>
>> mv packages recipes ; git commit .
>
> Only positive replies sofar, so when do we want to schedule this commit?  
> My proposal is somewhere in april, since I'm too busy this month with  
> bossaconference and university work to deal with the fallout properly.

Fine with me.  Do I have a vote? :)

> Also, shall we restructure TMPDIR at the same time?

Yes, lets get that RFC out :)  FWIW, I think 'sdk' should be in the same
place as the other target oriented stuff.  Perhaps target/${host}/sdk/

-- 
Tom Rini

Re: [RFC] renaming packages/ to recipes/

[Koen Kooi]

On 04-03-09 16:30, Tom Rini wrote:
> On Wed, Mar 04, 2009 at 12:16:48PM +0100, Koen Kooi wrote:
>> On 25-02-09 21:21, Koen Kooi wrote:
>>> Hi,
>>>
>>> I keep trying to teach people the difference between recipes (what's in
>>> OE) and packages (what you install on the target) and keep getting
>>> reactions like "ok, but why is the dir called packages?", which are
>>> completely valid.
>>>
>>> Proposal:
>>>
>>> mv packages recipes ; git commit .
>> Only positive replies sofar, so when do we want to schedule this commit?
>> My proposal is somewhere in april, since I'm too busy this month with
>> bossaconference and university work to deal with the fallout properly.
>
> Fine with me.  Do I have a vote? :)

yes :)

>> Also, shall we restructure TMPDIR at the same time?
>
> Yes, lets get that RFC out :)  FWIW, I think 'sdk' should be in the same
> place as the other target oriented stuff.  Perhaps target/${host}/sdk/

Could you send that RFC as a new thread?

regards,

Koen

Re: [RFC] renaming packages/ to recipes/

[Otavio Salvador]

Koen Kooi <k.kooi@student.utwente.nl> writes:

> On 25-02-09 21:21, Koen Kooi wrote:
>> Hi,
>>
>> I keep trying to teach people the difference between recipes (what's in
>> OE) and packages (what you install on the target) and keep getting
>> reactions like "ok, but why is the dir called packages?", which are
>> completely valid.
>>
>> Proposal:
>>
>> mv packages recipes ; git commit .
>
> Only positive replies sofar, so when do we want to schedule this
> commit? My proposal is somewhere in april, since I'm too busy this
> month with bossaconference and university work to deal with the
> fallout properly.
> Also, shall we restructure TMPDIR at the same time?

[...]

Let's do it step by step. It is much easier and nicer to our users if
they don't have to handle a completely different tree to get theirs work
done.

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: [RFC] renaming packages/ to recipes/

[Rob Tow]

[...]
> 
> Only positive replies sofar, so when do we want to schedule this commit? 
> My proposal is somewhere in april, since I'm too busy this month with 
> bossaconference and university work to deal with the fallout properly.
> Also, shall we restructure TMPDIR at the same time?
[...] 
> Koen


Is there an RFC for reworking TMDIR? I'd love to read it - and even help. I've
been poking around on the directory structure & relocation; it would be great to
be on the same page with everyone on this.

-r-

Re: [RFC] renaming packages/ to recipes/

[Rolf Leggewie]

Marcin Juszkiewicz wrote:
> My addition to this:
> 
> mkdir recipes-broken
> git add  recipes-broken
> git mv recipes/obsolete recipes-broken/obsolete
> git mv recipes/nonworking recipes-broken/nonworking
> 
> As this will allow users to set:
> 
> BBFILES = "/somewhere/oe/recipes/"
> 
> which is supported by BitBake for years.

I'd like to revisit this suggestion from Marcin which came up during the 
discussion of the packages->recipes renaming.  I think the above makes 
sense and should be committed.  I think it would be nice if the folder 
was named broken-recipes instead of recipes-broken.  First of all, it 
sounds nicer IMHO ;-) but more importantly, this works better with 
bash-completion.

Reopening discussion for this change.

Re: [RFC] renaming packages/ to recipes/

[Tom Rini]

On Mon, May 18, 2009 at 01:35:07AM +0200, Rolf Leggewie wrote:
> Marcin Juszkiewicz wrote:
>> My addition to this:
>>
>> mkdir recipes-broken
>> git add  recipes-broken
>> git mv recipes/obsolete recipes-broken/obsolete
>> git mv recipes/nonworking recipes-broken/nonworking
>>
>> As this will allow users to set:
>>
>> BBFILES = "/somewhere/oe/recipes/"
>>
>> which is supported by BitBake for years.
>
> I'd like to revisit this suggestion from Marcin which came up during the  
> discussion of the packages->recipes renaming.  I think the above makes  
> sense and should be committed.  I think it would be nice if the folder  
> was named broken-recipes instead of recipes-broken.  First of all, it  
> sounds nicer IMHO ;-) but more importantly, this works better with  
> bash-completion.

I believe with the collection stuff we don't need to do this kind of
move for easier / smaller local.conf files.

I think what we really need to do (in part because I think there's some
bitbake changes needed for compelete functionality) we need to bump
dev's minimum bitbake and update local.conf.sample and the wiki.  Oh,
and check with Chris to make sure everything he's got in these areas is
in :)

-- 
Tom Rini

Re: [RFC] renaming packages/ to recipes/

[Frans Meulenbroeks]

2009/5/18 Rolf Leggewie <no2spam@nospam.arcornews.de>:
> Marcin Juszkiewicz wrote:
>>
>> My addition to this:
>>
>> mkdir recipes-broken
>> git add  recipes-broken
>> git mv recipes/obsolete recipes-broken/obsolete
>> git mv recipes/nonworking recipes-broken/nonworking
>>
>> As this will allow users to set:
>>
>> BBFILES = "/somewhere/oe/recipes/"
>>
>> which is supported by BitBake for years.
>
> I'd like to revisit this suggestion from Marcin which came up during the
> discussion of the packages->recipes renaming.  I think the above makes sense
> and should be committed.  I think it would be nice if the folder was named
> broken-recipes instead of recipes-broken.  First of all, it sounds nicer
> IMHO ;-) but more importantly, this works better with bash-completion.
>
> Reopening discussion for this change.

I think adding recipes-broken (or broken-recipes) is a bad idea.
It is quite possible that a recipe is broken only for some platforms
(e.g. because they use an older libc or gcc, or because functionality
is not working in the machine specific parts.
In that case I can image we end up in a recipe being shifted around.
Not really a good plan.
Unless of course we end up with some good rules on when a recipe
should be moved to broken.

If I look at tinderbox I see various recipes that do not build for
some archtectures or configurations.

Just my two cents

Frans

Re: [RFC] renaming packages/ to recipes/

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]

Frans Meulenbroeks wrote:
> 2009/5/18 Rolf Leggewie <no2spam@nospam.arcornews.de>:
>> Marcin Juszkiewicz wrote:
>>> My addition to this:
>>>
>>> mkdir recipes-broken
>>> git add  recipes-broken
>>> git mv recipes/obsolete recipes-broken/obsolete
>>> git mv recipes/nonworking recipes-broken/nonworking
>>>
>>> As this will allow users to set:
>>>
>>> BBFILES = "/somewhere/oe/recipes/"
>>>
>>> which is supported by BitBake for years.
>> I'd like to revisit this suggestion from Marcin which came up during the
>> discussion of the packages->recipes renaming.  I think the above makes sense
>> and should be committed.  I think it would be nice if the folder was named
>> broken-recipes instead of recipes-broken.  First of all, it sounds nicer
>> IMHO ;-) but more importantly, this works better with bash-completion.
>>
>> Reopening discussion for this change.
> 
> I think adding recipes-broken (or broken-recipes) is a bad idea.
> It is quite possible that a recipe is broken only for some platforms
> (e.g. because they use an older libc or gcc, or because functionality
> is not working in the machine specific parts.
> In that case I can image we end up in a recipe being shifted around.
> Not really a good plan.
> Unless of course we end up with some good rules on when a recipe
> should be moved to broken.
> 
> If I look at tinderbox I see various recipes that do not build for
> some archtectures or configurations.
A broken recipes directory sounds like a good idea, but I think it will 
not work well in practive. My concern is the history will be filled with 
people miving recipes in and out of the broken directory (for reasons 
mentioned by Frans)

ow about trying to generate a report from tinderbox that lists broken 
recipes?

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: [RFC] renaming packages/ to recipes/

[Koen Kooi]

On 19-05-09 15:02, Philip Balister wrote:
> Frans Meulenbroeks wrote:
>> 2009/5/18 Rolf Leggewie <no2spam@nospam.arcornews.de>:
>>> Marcin Juszkiewicz wrote:
>>>> My addition to this:
>>>>
>>>> mkdir recipes-broken
>>>> git add recipes-broken
>>>> git mv recipes/obsolete recipes-broken/obsolete
>>>> git mv recipes/nonworking recipes-broken/nonworking
>>>>
>>>> As this will allow users to set:
>>>>
>>>> BBFILES = "/somewhere/oe/recipes/"
>>>>
>>>> which is supported by BitBake for years.
>>> I'd like to revisit this suggestion from Marcin which came up during the
>>> discussion of the packages->recipes renaming. I think the above makes
>>> sense
>>> and should be committed. I think it would be nice if the folder was
>>> named
>>> broken-recipes instead of recipes-broken. First of all, it sounds nicer
>>> IMHO ;-) but more importantly, this works better with bash-completion.
>>>
>>> Reopening discussion for this change.
>>
>> I think adding recipes-broken (or broken-recipes) is a bad idea.
>> It is quite possible that a recipe is broken only for some platforms
>> (e.g. because they use an older libc or gcc, or because functionality
>> is not working in the machine specific parts.
>> In that case I can image we end up in a recipe being shifted around.
>> Not really a good plan.
>> Unless of course we end up with some good rules on when a recipe
>> should be moved to broken.
>>
>> If I look at tinderbox I see various recipes that do not build for
>> some archtectures or configurations.
> A broken recipes directory sounds like a good idea, but I think it will
> not work well in practive. My concern is the history will be filled with
> people miving recipes in and out of the broken directory (for reasons
> mentioned by Frans)
>
> ow about trying to generate a report from tinderbox that lists broken
> recipes?

Sounds like the coverage matrix I proposed at OEDEM 2006 :)

regards,

Koen

Re: [RFC] renaming packages/ to recipes/

[Elena of Valhalla]

On Tue, May 19, 2009 at 2:19 PM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> I think adding recipes-broken (or broken-recipes) is a bad idea.
> [...]

How is this different from having recipes/nonworking and
recipes/obsolete as it currently happens?

more visibility?

-- 
Elena ``of Valhalla''

homepage: http://www.trueelena.org
email: elena.valhalla@gmail.com

Re: [RFC] renaming packages/ to recipes/

[Frans Meulenbroeks]

2009/5/19 Elena of Valhalla <elena.valhalla@gmail.com>:
> On Tue, May 19, 2009 at 2:19 PM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
>> I think adding recipes-broken (or broken-recipes) is a bad idea.
>> [...]
>
> How is this different from having recipes/nonworking and
> recipes/obsolete as it currently happens?
>
> more visibility?
>
> --
> Elena ``of Valhalla''

You have a point.
Then again things in recipes/nonworking and recipes/obsolete are
generally considered as very broken.
I would not want the task to repair all packages that are outside
these dirs and also not working on some targets/situations.

That is why I mentioned that if we want such a dir, we need a policy
on what/when could go in there.
(e.g. by requiring that a move to broken is ack-ed by 2 other devs).

Frans