Patchwork [meta-kde,3/3] README: update contributor list

login
register
mail settings
Submitter Koen Kooi
Date March 7, 2013, 9:50 a.m.
Message ID <1362649839-9160-3-git-send-email-koen@dominion.thruhere.net>
Download mbox | patch
Permalink /patch/45627/
State Accepted, archived
Headers show

Comments

Koen Kooi - March 7, 2013, 9:50 a.m.
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
 README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Samuel Stirtzel - March 7, 2013, 12:09 p.m.
2013/3/7 Koen Kooi <koen@dominion.thruhere.net>:
> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> ---
>  README | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/README b/README
> index 0635e10..cab1e21 100644
> --- a/README
> +++ b/README
> @@ -10,7 +10,7 @@ Samuel Stirtzel <s.stirtzel@googlemail.com>
>  Contributors:
>  Copyright 2012 - Kai Kang
>  Copyright 2013 - Khem Raj
> -Copyright 2012 - Koen Kooi
> +Copyright 2012, 2013 - Koen Kooi
>  Copyright 2012 - Robert Yang
>  Copyright 2011, 2012 - Samuel Stirtzel
>
> --
> 1.8.1.4
>

Thanks for your patches,
I applied them all.


Unrelated to your patches:
There are some upcoming changes, but they don't fit into yocto 1.4
(assumed that yocto is the orientation point for third-party OE-layer
releases).
So there will be a yocto-1.4 branch in advance and the development
will continue on master.

Hopefully meta-angstrom + meta-oe + oe-core + <bsp-layer> is a
supported use case in yocto ...
Martin Jansa - March 7, 2013, 1:04 p.m.
On Thu, Mar 07, 2013 at 01:09:38PM +0100, Samuel Stirtzel wrote:
> 2013/3/7 Koen Kooi <koen@dominion.thruhere.net>:
> > Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> > ---
> >  README | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/README b/README
> > index 0635e10..cab1e21 100644
> > --- a/README
> > +++ b/README
> > @@ -10,7 +10,7 @@ Samuel Stirtzel <s.stirtzel@googlemail.com>
> >  Contributors:
> >  Copyright 2012 - Kai Kang
> >  Copyright 2013 - Khem Raj
> > -Copyright 2012 - Koen Kooi
> > +Copyright 2012, 2013 - Koen Kooi
> >  Copyright 2012 - Robert Yang
> >  Copyright 2011, 2012 - Samuel Stirtzel
> >
> > --
> > 1.8.1.4
> >
> 
> Thanks for your patches,
> I applied them all.
> 
> 
> Unrelated to your patches:
> There are some upcoming changes, but they don't fit into yocto 1.4
> (assumed that yocto is the orientation point for third-party OE-layer
> releases).
> So there will be a yocto-1.4 branch in advance and the development
> will continue on master.

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.

> Hopefully meta-angstrom + meta-oe + oe-core + <bsp-layer> is a
> supported use case in yocto ...
> 
> -- 
> Regards
> Samuel
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Paul Eggleton - March 7, 2013, 1:10 p.m.
On Thursday 07 March 2013 13:09:38 Samuel Stirtzel wrote:
> Unrelated to your patches:
> There are some upcoming changes, but they don't fit into yocto 1.4
> (assumed that yocto is the orientation point for third-party OE-layer
> releases).
> So there will be a yocto-1.4 branch in advance and the development
> will continue on master.

FYI, the layer index web interface I'm putting together [1] will understand 
certain branch names across all layers, and the convention so far has been to 
use the release names i.e. denzil, danny, etc. If you are able to follow this 
as well once the 1.4 codename has been announced then your branch will show up 
correctly in the new interface.

Cheers,
Paul

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=3272
Koen Kooi - March 7, 2013, 2:03 p.m.
Op 7 mrt. 2013, om 14:04 heeft Martin Jansa <martin.jansa@gmail.com> het volgende geschreven:

> On Thu, Mar 07, 2013 at 01:09:38PM +0100, Samuel Stirtzel wrote:
>> 2013/3/7 Koen Kooi <koen@dominion.thruhere.net>:
>>> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
>>> ---
>>> README | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/README b/README
>>> index 0635e10..cab1e21 100644
>>> --- a/README
>>> +++ b/README
>>> @@ -10,7 +10,7 @@ Samuel Stirtzel <s.stirtzel@googlemail.com>
>>> Contributors:
>>> Copyright 2012 - Kai Kang
>>> Copyright 2013 - Khem Raj
>>> -Copyright 2012 - Koen Kooi
>>> +Copyright 2012, 2013 - Koen Kooi
>>> Copyright 2012 - Robert Yang
>>> Copyright 2011, 2012 - Samuel Stirtzel
>>> 
>>> --
>>> 1.8.1.4
>>> 
>> 
>> Thanks for your patches,
>> I applied them all.
>> 
>> 
>> Unrelated to your patches:
>> There are some upcoming changes, but they don't fit into yocto 1.4
>> (assumed that yocto is the orientation point for third-party OE-layer
>> releases).
>> So there will be a yocto-1.4 branch in advance and the development
>> will continue on master.
> 
> 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.
Samuel Stirtzel - March 7, 2013, 2:04 p.m.
2013/3/7 Paul Eggleton <paul.eggleton@linux.intel.com>:
> On Thursday 07 March 2013 13:09:38 Samuel Stirtzel wrote:
>> Unrelated to your patches:
>> There are some upcoming changes, but they don't fit into yocto 1.4
>> (assumed that yocto is the orientation point for third-party OE-layer
>> releases).
>> So there will be a yocto-1.4 branch in advance and the development
>> will continue on master.
>
> FYI, the layer index web interface I'm putting together [1] will understand
> certain branch names across all layers, and the convention so far has been to
> use the release names i.e. denzil, danny, etc. If you are able to follow this
> as well once the 1.4 codename has been announced then your branch will show up
> correctly in the new interface.
>
> Cheers,
> Paul
>
> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=3272
>

Good to know,
so layers like meta-qt5 [1] for example will be found more easily.

I will rename the branch after the codename has been announced,
but yes it would be easier if the name could get announced long before
the release.


[1] https://github.com/meta-qt5/meta-qt5


--
Regards
Samuel
Paul Eggleton - March 7, 2013, 2:35 p.m.
On Thursday 07 March 2013 15:03:17 Koen Kooi wrote:
> Op 7 mrt. 2013, om 14:04 heeft Martin Jansa <martin.jansa@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.

Cheers,
Paul
Otavio Salvador - March 7, 2013, 2:41 p.m.
On Thu, Mar 7, 2013 at 11:35 AM, Paul Eggleton
<paul.eggleton@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@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.
Philip Balister - March 7, 2013, 2:50 p.m.
On 03/07/2013 09:41 AM, Otavio Salvador wrote:
> On Thu, Mar 7, 2013 at 11:35 AM, Paul Eggleton
> <paul.eggleton@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@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.

Philip
Martin Jansa - March 7, 2013, 2:52 p.m.
On Thu, Mar 07, 2013 at 11:41:07AM -0300, Otavio Salvador wrote:
> On Thu, Mar 7, 2013 at 11:35 AM, Paul Eggleton
> <paul.eggleton@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@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.

Yes I usually need to use both names, because some people want to hear
"Yocto". 

But "Yocto 1.3" alone sometimes does not work in sentences like 
"Update oe-core to latest revision in danny branch (Yocto 1.3)"
"Update bitbake to latest revision in 1.16 branch which is compatible with danny branches (Yocto
1.3)"

So I agree it's confusing, like in this pull-request
https://github.com/openwebos/build-webos/pull/25

Yes, I always forget to add "Project" :/.
Ross Burton - March 7, 2013, 3:05 p.m.
On 7 March 2013 14:50, Philip Balister <philip@balister.org> wrote:
>> 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.

We really need a table on the wiki page listing all of them - I can
easily remember the current/previous/next names but after that I don't
remember them.

Ross
Martin Jansa - March 7, 2013, 3:05 p.m.
On Thu, Mar 07, 2013 at 01:09:38PM +0100, Samuel Stirtzel wrote:
> 2013/3/7 Koen Kooi <koen@dominion.thruhere.net>:
> > Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> > ---
> >  README | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/README b/README
> > index 0635e10..cab1e21 100644
> > --- a/README
> > +++ b/README
> > @@ -10,7 +10,7 @@ Samuel Stirtzel <s.stirtzel@googlemail.com>
> >  Contributors:
> >  Copyright 2012 - Kai Kang
> >  Copyright 2013 - Khem Raj
> > -Copyright 2012 - Koen Kooi
> > +Copyright 2012, 2013 - Koen Kooi
> >  Copyright 2012 - Robert Yang
> >  Copyright 2011, 2012 - Samuel Stirtzel
> >
> > --
> > 1.8.1.4
> >
> 
> Thanks for your patches,
> I applied them all.

Can you update status on:
http://patches.openembedded.org/bundle/jama/meta-kde/?archive=both

To keep patchwork clean?
Ross Burton - March 7, 2013, 3:15 p.m.
On 7 March 2013 15:05, Burton, Ross <ross.burton@intel.com> wrote:
> We really need a table on the wiki page listing all of them - I can
> easily remember the current/previous/next names but after that I don't
> remember them.

JFDI.

https://wiki.yoctoproject.org/wiki/Releases

Only goes back to Poky 4/oe-core 0.9 at the moment, I'll fill in the
pre-Yocto names later.

Ross
Koen Kooi - March 7, 2013, 3:18 p.m.
Op 7 mrt. 2013, om 16:15 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven:

> On 7 March 2013 15:05, Burton, Ross <ross.burton@intel.com> wrote:
>> We really need a table on the wiki page listing all of them - I can
>> easily remember the current/previous/next names but after that I don't
>> remember them.
> 
> JFDI.
> 
> https://wiki.yoctoproject.org/wiki/Releases
> 
> Only goes back to Poky 4/oe-core 0.9 at the moment, I'll fill in the
> pre-Yocto names later.

I asked this earlier in jest, but it requires a real response in this day and age:

	Are those yocto project releases or poky releases?

I get the feeling the codenames are only for poky releases, so I strongly prefer using the numbers releases in branch names.
Samuel Stirtzel - March 7, 2013, 3:20 p.m.
2013/3/7 Martin Jansa <martin.jansa@gmail.com>:
> On Thu, Mar 07, 2013 at 01:09:38PM +0100, Samuel Stirtzel wrote:
>> 2013/3/7 Koen Kooi <koen@dominion.thruhere.net>:
>> > Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
>> > ---
>> >  README | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/README b/README
>> > index 0635e10..cab1e21 100644
>> > --- a/README
>> > +++ b/README
>> > @@ -10,7 +10,7 @@ Samuel Stirtzel <s.stirtzel@googlemail.com>
>> >  Contributors:
>> >  Copyright 2012 - Kai Kang
>> >  Copyright 2013 - Khem Raj
>> > -Copyright 2012 - Koen Kooi
>> > +Copyright 2012, 2013 - Koen Kooi
>> >  Copyright 2012 - Robert Yang
>> >  Copyright 2011, 2012 - Samuel Stirtzel
>> >
>> > --
>> > 1.8.1.4
>> >
>>
>> Thanks for your patches,
>> I applied them all.
>
> Can you update status on:
> http://patches.openembedded.org/bundle/jama/meta-kde/?archive=both
>
> To keep patchwork clean?
>

I would, but unfortunately I have no Patchwork account.
Also there seems to be no possibility to register a new account.
Richard Purdie - March 7, 2013, 3:24 p.m.
On Thu, 2013-03-07 at 16:18 +0100, Koen Kooi wrote:
> Op 7 mrt. 2013, om 16:15 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven:
> 
> > On 7 March 2013 15:05, Burton, Ross <ross.burton@intel.com> wrote:
> >> We really need a table on the wiki page listing all of them - I can
> >> easily remember the current/previous/next names but after that I don't
> >> remember them.
> > 
> > JFDI.
> > 
> > https://wiki.yoctoproject.org/wiki/Releases
> > 
> > Only goes back to Poky 4/oe-core 0.9 at the moment, I'll fill in the
> > pre-Yocto names later.
> 
> I asked this earlier in jest, but it requires a real response in this day and age:
> 
> 	Are those yocto project releases or poky releases?
> 
> I get the feeling the codenames are only for poky releases, so I
> strongly prefer using the numbers releases in branch names.

They're stable release series codenames use by the Yocto Project,
OpenEmbedded Core, Poky and anyone else who wishes to.

Cheers,

Richard
Richard Purdie - March 7, 2013, 3:30 p.m.
On Thu, 2013-03-07 at 15:03 +0100, Koen Kooi wrote:
> Op 7 mrt. 2013, om 14:04 heeft Martin Jansa <martin.jansa@gmail.com> het volgende geschreven:
> 
> > On Thu, Mar 07, 2013 at 01:09:38PM +0100, Samuel Stirtzel wrote:
> >> 2013/3/7 Koen Kooi <koen@dominion.thruhere.net>:
> >>> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> >>> ---
> >>> README | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>> 
> >>> diff --git a/README b/README
> >>> index 0635e10..cab1e21 100644
> >>> --- a/README
> >>> +++ b/README
> >>> @@ -10,7 +10,7 @@ Samuel Stirtzel <s.stirtzel@googlemail.com>
> >>> Contributors:
> >>> Copyright 2012 - Kai Kang
> >>> Copyright 2013 - Khem Raj
> >>> -Copyright 2012 - Koen Kooi
> >>> +Copyright 2012, 2013 - Koen Kooi
> >>> Copyright 2012 - Robert Yang
> >>> Copyright 2011, 2012 - Samuel Stirtzel
> >>> 
> >>> --
> >>> 1.8.1.4
> >>> 
> >> 
> >> Thanks for your patches,
> >> I applied them all.
> >> 
> >> 
> >> Unrelated to your patches:
> >> There are some upcoming changes, but they don't fit into yocto 1.4
> >> (assumed that yocto is the orientation point for third-party OE-layer
> >> releases).
> >> So there will be a yocto-1.4 branch in advance and the development
> >> will continue on master.
> > 
> > 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.

That is just going to cause even more confusion. That branch is for
Angstrom 1.4, right?

It was never intended to inflict any specific version onto any specific
project which is why the names are versionless. We do need to show what
is compatible with what hence the codenames. I've long since decided
this is a topic there is no one right answer to though so we'll just
have to live with where we are and make the most of it. I've sent out
emails about this before too.

If we need to know the name of the branch more in advance, that is
straight forward to arrange, I just need to pick the next one.

Cheers,

Richard
Paul Eggleton - March 7, 2013, 3:41 p.m.
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@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@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
Martin Jansa - March 7, 2013, 3:56 p.m.
On Thu, Mar 07, 2013 at 04:20:42PM +0100, Samuel Stirtzel wrote:
> 2013/3/7 Martin Jansa <martin.jansa@gmail.com>:
> > On Thu, Mar 07, 2013 at 01:09:38PM +0100, Samuel Stirtzel wrote:
> >> 2013/3/7 Koen Kooi <koen@dominion.thruhere.net>:
> >> > Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> >> > ---
> >> >  README | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/README b/README
> >> > index 0635e10..cab1e21 100644
> >> > --- a/README
> >> > +++ b/README
> >> > @@ -10,7 +10,7 @@ Samuel Stirtzel <s.stirtzel@googlemail.com>
> >> >  Contributors:
> >> >  Copyright 2012 - Kai Kang
> >> >  Copyright 2013 - Khem Raj
> >> > -Copyright 2012 - Koen Kooi
> >> > +Copyright 2012, 2013 - Koen Kooi
> >> >  Copyright 2012 - Robert Yang
> >> >  Copyright 2011, 2012 - Samuel Stirtzel
> >> >
> >> > --
> >> > 1.8.1.4
> >> >
> >>
> >> Thanks for your patches,
> >> I applied them all.
> >
> > Can you update status on:
> > http://patches.openembedded.org/bundle/jama/meta-kde/?archive=both
> >
> > To keep patchwork clean?
> >
> 
> I would, but unfortunately I have no Patchwork account.
> Also there seems to be no possibility to register a new account.

Adding khem to CC: I guess he can arrange account for you.
Peter Bigot - March 11, 2013, 12:34 p.m.
On 03/07/2013 09:41 AM, Paul Eggleton wrote:
> 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@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@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.
A comment on that from up here in the peanut gallery: I don't personally 
find codenames valuable, but if they're used it would be nice if they 
were selected using a policy that allowed at least their relative order 
to be determined by inspection.  That danny=1.3 sorts lexicographically 
before denzil=1.2 is confusing.

Peter
Samuel Stirtzel - March 20, 2013, 12:14 p.m.
2013/3/7 Martin Jansa <martin.jansa@gmail.com>:
> On Thu, Mar 07, 2013 at 04:20:42PM +0100, Samuel Stirtzel wrote:
>> 2013/3/7 Martin Jansa <martin.jansa@gmail.com>:
>> > On Thu, Mar 07, 2013 at 01:09:38PM +0100, Samuel Stirtzel wrote:
>> >> 2013/3/7 Koen Kooi <koen@dominion.thruhere.net>:
>> >> > Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
>> >> > ---
>> >> >  README | 2 +-
>> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/README b/README
>> >> > index 0635e10..cab1e21 100644
>> >> > --- a/README
>> >> > +++ b/README
>> >> > @@ -10,7 +10,7 @@ Samuel Stirtzel <s.stirtzel@googlemail.com>
>> >> >  Contributors:
>> >> >  Copyright 2012 - Kai Kang
>> >> >  Copyright 2013 - Khem Raj
>> >> > -Copyright 2012 - Koen Kooi
>> >> > +Copyright 2012, 2013 - Koen Kooi
>> >> >  Copyright 2012 - Robert Yang
>> >> >  Copyright 2011, 2012 - Samuel Stirtzel
>> >> >
>> >> > --
>> >> > 1.8.1.4
>> >> >
>> >>
>> >> Thanks for your patches,
>> >> I applied them all.
>> >
>> > Can you update status on:
>> > http://patches.openembedded.org/bundle/jama/meta-kde/?archive=both
>> >
>> > To keep patchwork clean?
>> >
>>
>> I would, but unfortunately I have no Patchwork account.
>> Also there seems to be no possibility to register a new account.
>
> Adding khem to CC: I guess he can arrange account for you.
>

Hi, so far I did not receive any info on how to create / access a
patchwork account.
Maybe something went wrong / got lost in transmission?


--
Regards
Samuel

Patch

diff --git a/README b/README
index 0635e10..cab1e21 100644
--- a/README
+++ b/README
@@ -10,7 +10,7 @@  Samuel Stirtzel <s.stirtzel@googlemail.com>
 Contributors:
 Copyright 2012 - Kai Kang
 Copyright 2013 - Khem Raj
-Copyright 2012 - Koen Kooi
+Copyright 2012, 2013 - Koen Kooi
 Copyright 2012 - Robert Yang
 Copyright 2011, 2012 - Samuel Stirtzel