From kde-active  Thu May 31 10:53:15 2012
From: "Aaron J. Seigo" <aseigo () kde ! org>
Date: Thu, 31 May 2012 10:53:15 +0000
To: kde-active
Subject: Re: List of problems with Plasma Active on Mer
Message-Id: <38249180.BXuWkyWab2 () freedom>
X-MARC-Message: https://marc.info/?l=kde-active&m=133846178527052
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============0734409409485988933=="


--===============0734409409485988933==
Content-Type: multipart/signed; boundary="nextPart1627834.hVOrNb2U8d"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7Bit


--nextPart1627834.hVOrNb2U8d
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="ISO-8859-1"

On Thursday, May 31, 2012 11:23:30 martin brook wrote:
> Carsten has been working on some architecture pages on the wiki which may
> help here,

while very nice and quite useful, that page unfortunately doesn't address my 
question at all.

i have a reasonably decent idea of what mer currently is.

i'm suggesting that that definition creates inneficiencies because it does not 
fully align with all needs associated with having a shared core. a shared core 
implies shared adaptations. and while mer core team does not need to work on 
those adaptations, it makes sense to host those adaptations.

adaptations can have maintainers that are not members of mer core, and 
probably should have to make maintenance, support and workload sensible.

right now putting the adaptations above the "individual users of mer core" 
line simply duplicates efforts. moving those adaptations above mer core but 
below the uses of (e.g. nemo, plasma active, etc) would resolve that.

to make it abundantly clear: nobody is expecting mer core to maintain or 
develop those adaptations, merely provide a well defined area for collaboration 
on such adaptations in a place they can be widely shared.

and as i noted in my previous email, either mer will provide this or we will. 
the latter solution is really sub-optimal, since collaboration on common core 
technology is supposed to be the point of mer as i understand it.

the diagram might look like:

	full products (e.g. vivaldi)
	-----------------
	mer based products (nemo, plasma active, etc..)
	-----------------
	adaptations (intel, $RANDOM_ARM_BOARDS, etc..)
	-----------------
	mer core

the corresponding maintainer layers might look like this:

	manufacturer (e.g. Make Play Live)
	-------------------
	UI community (nemo, kde, ..)
	------------------
	adaptation community (nemo, kde, $CORPORATION ..)
	------------------
	mer core team

right now what we have is:

	full products (e.g. vivaldi)
	-----------------
	mer based products (nemo, plasma active, etc..)
	-----------------
	mer core

with adaptations being insert somewhere in an ad-hoc fashion, which is leading 
to inneficiences.

please consider this as feedback from a concerned and highly vested user and 
fan of mer,, in the form of an appeal to the project leadership in mer :)

-- 
Aaron J. Seigo
--nextPart1627834.hVOrNb2U8d
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEABECAAYFAk/HTZsACgkQ1rcusafx20NqNQCdHtj1j1sVj25NBv3tZ333NjOV
ODoAniO2FwQKlkuO89c0D1TMv7bszLNz
=8W9Z
-----END PGP SIGNATURE-----

--nextPart1627834.hVOrNb2U8d--


--===============0734409409485988933==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Active mailing list
Active@kde.org
https://mail.kde.org/mailman/listinfo/active

--===============0734409409485988933==--