--===============6733010078113059744==
Content-Type: multipart/signed; boundary="nextPart1524951.sKysKqon0B"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7Bit


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

On Thursday, May 31, 2012 11:04:34 martin brook wrote:
>From my view there is a place for the x86 adaptations and this is in the
> Nemo project and Mer people contribute there. 

why does this, or any adaptation, belong to a specific mer based project?

hardware adaptations are sharable artifacts that ride alongside the core, as 
opposed to being tightly coupled to presentation layer. well, they CAN be 
tightly coupled to a presentation layer, but that seems conterproductive, 
given your statement here:

> In my view its the number of resources available to work these adaptations
> which is the problem just as in all software development projects I've been
> involved in.

the way to incrase the # of people working on an adaptation is to de-couple 
the adaptations from the presentation layer and make them shared projects.

which implies an area that we can point to such adaptations from, instead of 
having to search through each mer based project to see what they are up to.

this is not a change in maintainership (e.g. expecting mer core team to take 
on adaptations or even provide support for them) but a canonicalization of 
where adaptation efforts can take place for the purpose of cross-product 
sharing.

here's a copy and paste from an email i sent to only the active@ list a few 
minutes ago, but may be of interest to mer-general too:


either mer will provide a place for adaptation collaborations or the projects 
working with mer 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 projects (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 inserted 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
--nextPart1524951.sKysKqon0B
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/HUAUACgkQ1rcusafx20PVHgCeJwbuSpRsWNwR+2xKRik6fi65
g00Amwb2KMzNQwByt3CpjoUkaRyh85P0
=YnP4
-----END PGP SIGNATURE-----

--nextPart1524951.sKysKqon0B--


--===============6733010078113059744==
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

--===============6733010078113059744==--