From: William Mills <wmills@ti.com>
To: Koen Kooi <koen@dominion.thruhere.net>
Cc: meta-ti@yoctoproject.org
Subject: Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay
Date: Fri, 27 Jan 2012 12:30:20 -0500 [thread overview]
Message-ID: <4F22DF2C.1090907@ti.com> (raw)
In-Reply-To: <27324814-C581-4BD9-92DF-68FC5CB4CECF@dominion.thruhere.net>
On 01/27/2012 06:50 AM, Koen Kooi wrote:
>
> Op 26 jan. 2012, om 23:44 heeft William Mills het volgende geschreven:
>
>> On 01/26/2012 01:46 PM, Chase Maupin wrote:
>>> * This package adds a simple web browser GUI application with
>>> no decorations used to display matrix on the local display.
>>> * Ported from arago overlay
>>>
>>
>> Sorry for hijacking your patch Chase but I have serious big picture questions about all this stuff going into meta-ti and especially all into one layer.
>>
>> meta-ti is suppose to be the TI specific stuff people need to support their platforms regardless of what layer stack they are using. I understand we are not layer stack independent yet but that needs to be the goal. Certainly adding a whole bunch of non-HW related stuff into the same layer is not going to move us any closer.
>>
>> When we talked about where matrix belonged before there was debate about meta-oe or meta-arago. When did I miss the memo that put it into meta-ti??
>
> Since meta-arago is supposed to be as empty as possible and matrix doesn't play well with others it's a bad fit for both meta-arago and meta-oe. Maybe we should split the meta-ti repo into 2 layers: one for BSP things (including sgx, dsp, etc) and one for 'sdk' things (matrix).
> The idea is to keep reusable TI deliverables together without forcing people to use arago. Putting matrix in meta-arago would mean you can only use it with DISTRO=arago, which is a huge step backwards from the current situation.
matrix does not play well with others so we should put it in the layer
that is suppose to work in as many layer stacks as possible??
Yes, this can be fixed by making a different layer (as I alluded to) in
meta-ti but the same can be said for meta-arago or (harder sell) for
meta-oe (a "staging" layer?). I agree the Arago _distro_ _layer_ needs
to be as thin as possible but that does not need to apply to the
meta-arago.git.
There is nothing "TI" about matrix other than we wrote it and are the
ones that use it most often. The same logic could apply to meta-arago.
Matrix originated in Arago related activities and is more closly
related to the Arago concept than the TI concept.
If lots of people pick up and want to use Matrix it would would need to
move out of either place (meta-ti or meta-arago) to somewhere more
neutral. However it would also need to more sophisticated in how it
"plays with others".
meta-ti should not be a dumping ground for all things that happened to
have originated at TI. meta-ti needs to be clean. meta-arago can be a
little messy if need be.
Regardless of who's opinion prevails it seems we agree that another
layer is needed. Agreed?
prev parent reply other threads:[~2012-01-27 17:30 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-26 18:46 [PATCH 1/3] matrix-gui-browser: port from arago overlay Chase Maupin
2012-01-26 18:46 ` [PATCH 2/3] refresh-screen: add package from arago Chase Maupin
2012-01-26 18:46 ` [PATCH 3/3] matrix-gui: update to latest version Chase Maupin
2012-01-26 22:44 ` [PATCH 1/3] matrix-gui-browser: port from arago overlay William Mills
2012-01-27 11:50 ` Koen Kooi
2012-01-27 12:09 ` Andreas Müller
2012-01-27 12:24 ` Koen Kooi
2012-01-27 17:38 ` William Mills
2012-01-27 19:39 ` Denys Dmytriyenko
2012-01-27 19:47 ` Koen Kooi
2012-01-27 20:09 ` Denys Dmytriyenko
2012-01-27 13:50 ` Maupin, Chase
2012-01-27 14:54 ` Philip Balister
2012-01-27 15:19 ` Maupin, Chase
2012-01-27 17:51 ` William Mills
2012-01-27 19:46 ` Maupin, Chase
2012-01-27 20:03 ` William Mills
2012-01-27 20:05 ` William Mills
2012-01-27 20:10 ` Tom Rini
2012-01-27 20:11 ` Denys Dmytriyenko
2012-01-27 20:19 ` Philip Balister
2012-01-27 20:24 ` Denys Dmytriyenko
2012-01-27 20:20 ` William Mills
2012-01-27 20:11 ` William Mills
2012-01-27 20:17 ` Maupin, Chase
2012-01-27 20:21 ` Denys Dmytriyenko
2012-01-27 20:24 ` William Mills
2012-01-27 20:29 ` Maupin, Chase
2012-01-27 20:34 ` Denys Dmytriyenko
2012-01-27 20:39 ` Maupin, Chase
2012-01-27 20:42 ` William Mills
2012-01-27 20:44 ` Maupin, Chase
2012-01-27 20:48 ` William Mills
2012-01-27 20:34 ` William Mills
2012-01-27 20:50 ` Philip Balister
2012-01-27 20:54 ` Koen Kooi
2012-01-27 20:57 ` Denys Dmytriyenko
2012-01-27 22:40 ` Philip Balister
2012-01-27 23:39 ` Denys Dmytriyenko
2012-01-27 20:53 ` Koen Kooi
2012-01-27 20:55 ` Maupin, Chase
2012-01-27 21:52 ` William Mills
2012-01-27 23:04 ` Koen Kooi
2012-01-28 3:23 ` Philip Balister
2012-01-27 17:30 ` William Mills [this message]
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=4F22DF2C.1090907@ti.com \
--to=wmills@ti.com \
--cc=koen@dominion.thruhere.net \
--cc=meta-ti@yoctoproject.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.