All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Peter A. Bigot" <pab@pabigot.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [meta-kde][PATCH 3/3] README: update contributor list
Date: Mon, 11 Mar 2013 07:34:55 -0500	[thread overview]
Message-ID: <513DCF6F.6070405@pabigot.com> (raw)
In-Reply-To: <1820544.NMbf1lmvlI@helios>

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



  reply	other threads:[~2013-03-11 12:54 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-07  9:50 [meta-kde][PATCH 1/3] packagegroup-kde-apps: remove multiline comment Koen Kooi
2013-03-07  9:50 ` [meta-kde][PATCH 2/3] ark, gwenview: fix RDEPENDS Koen Kooi
2013-03-07  9:50 ` [meta-kde][PATCH 3/3] README: update contributor list Koen Kooi
2013-03-07 12:09   ` Samuel Stirtzel
2013-03-07 13:04     ` Martin Jansa
2013-03-07 14:03       ` Koen Kooi
2013-03-07 14:35         ` Paul Eggleton
2013-03-07 14:41           ` Otavio Salvador
2013-03-07 14:50             ` Philip Balister
2013-03-07 15:05               ` Burton, Ross
2013-03-07 15:15                 ` Burton, Ross
2013-03-07 15:18                   ` Koen Kooi
2013-03-07 15:24                     ` Richard Purdie
2013-03-07 15:41               ` Paul Eggleton
2013-03-11 12:34                 ` Peter A. Bigot [this message]
2013-03-07 14:52             ` Martin Jansa
2013-03-07 15:30         ` Richard Purdie
2013-03-07 13:10     ` Paul Eggleton
2013-03-07 14:04       ` Samuel Stirtzel
2013-03-07 15:05     ` Martin Jansa
2013-03-07 15:20       ` Samuel Stirtzel
2013-03-07 15:56         ` Martin Jansa
2013-03-20 12:14           ` Samuel Stirtzel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=513DCF6F.6070405@pabigot.com \
    --to=pab@pabigot.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.