List of problems with Plasma Active on Mer

[Aaron J. Seigo]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/active/attachments/20120531/405f96a1/attachment.sig>