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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active