[oe] [meta-kde][PATCH 3/3] README: update contributor list

[Paul Eggleton]

On Thursday 07 March 2013 09:50:21 Philip Balister wrote:
> On 03/07/2013 09:41 AM, Otavio Salvador wrote:
> > On Thu, Mar 7, 2013 at 11:35 AM, Paul Eggleton
> > 
> > <paul.eggleton at linux.intel.com> wrote:
> >> On Thursday 07 March 2013 15:03:17 Koen Kooi wrote:
> >>> Op 7 mrt. 2013, om 14:04 heeft Martin Jansa <martin.jansa at gmail.com> het
> >>> 
> >>> volgende geschreven:
> >>>> It would be nice to know yocto-1.4 release name in advance and name it
> >>>> the same as branch in oe-core/meta-oe will be (denzil, danny, ...), but
> >>>> I guess it can be renamed later.
> >>> 
> >>> For angstrom I'm going to use 'yocto-1.4' in the branch name, I have
> >>> trouble remembering which names maps to which release. And the Yocto
> >>> compliance program talks about 1.3, .14 etc, not about codenames.
> >> 
> >> Wouldn't it be worth us trying to standardise rather than all doing our
> >> own
> >> thing and users having to figure out what matches up between different
> >> layers? If others feel the same as you, then maybe we should all be
> >> using that schema.> 
> > Or we use a codename or we don't.
> > 
> > For me, codenames work fine but for users it is sometimes confusing as
> > the website and marketing people talk about Yocto 1.3 or 1.4 while the
> > involved people talk about codenames. So I find myself explaining it
> > over and over again.
> 
> Add me to the list of people that find codenames confusing. I can't
> reliably list releases in order by name.

FWIW, in the layer index web app against each branch I have a field for a short 
description (e.g. denzil could have something like "old stable" or whatever is 
helpful to explain it to people) and a sort order so that they can be sorted 
correctly where listed. 

That doesn't take away the need to resolve this issue of branch names across 
layers, but it may help users to understand what these codenames mean if they 
continue to be used, at least when they see them in the layer index at least.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre