# The egocentric decisions of the CM team - why hurt independent devs and the community?



## Ezekeel

There are several kernel tweaks implemented by various devs that require/support adjustment of some sort of parameters. As an interface a dev usually adds some additional entries to the sysfs. When writing a GUI/frontend for this sysfs interface one simply reads/writes a value from/to these sysfs entries.

Around a year ago one CM team dev (which shall remained unnamed) did start to take kernel tweaks that are out there from other independent kernel devs and to re-implement them under an incompatible interface. His goal was to unify the sysfs interface across different devices so when implementing a GUI in the CM ROM Control the CM devs could use the same sysfs hook. This meant less work for the CM devs since they could use the same code in the ROM across different devices without modification.

However on the other hand that also meant that for each of those devices there now were two incompatible implementations for the same functionality which in most cases could not be both simultaneously added to the kernel. And while some kernel devs stuck to the original implementation, others adopted the CM version to be compatible with the CM ROM Controls. So this practice of CM did lead to an additional artificial fragmentation for those devices resulting in several negative consequences for both independent kernel devs and also the common users.

For kernel devs this means that they are forced to make a decision which implementation to support which practically means to decide which GUI tools to break since these are normally only compatible to one implementation. The original kernel dev of these ripped-off tweaks are hit the hardest since some of them have put out apps on the market to fund their work. So when other kernel devs adapt the CM flavor their apps will no longer work with these kernels.

On the other hand there is the common user which now has the additional problem to keep track which flavor is implemented in the kernel he is using and which GUI tools work with it. This results in unnecessary confusion which again leads to people complaining to the kernel devs that this or that GUI tool/ROM Control is not working.

As one can see the decisions CM has made work out fine for CM themself, however independent kernel devs and essentially the entire community gets the short end of the stick.

In February I contacted that one CM dev who was reponsible for these incompatible re-implementations and I explained my point of view, however he was not willing to cooperate. So early March Imoseyon, Francisco, Morfic and me contacted the CM team leaders. The reponse from the CM team was friendly, they seemed to be willing to cooperate and promises were made to get this problem resolved. Unfortunately it became clear that these promises were not sincere since after giving us a run-around for two entire month nothing at all has happened (http://h11.abload.de/img/cm11t89f.jpg).

At the end of these two month of fooling around with us and wasting our time the CM team did inform us that not only they will not revert the changes they made to fix the mess and confusion they caused but also that for the future they reserve the right to take kernel tweaks from other independent devs out there and re-implement them under incompatible interfaces (http://h11.abload.de/img/cm2evk65.jpg).

For kernel devs in practise this means that one cannot release a new tweak without fearing that CM takes it and reimplements it under an incompatible interface creating another mess. So for the future if one wants to implement a new functionality one better makes sure to use the same sysfs interface that CM has defined at standard. Whether this is intended or not by CM, this will be the practical end result. And having that threat always lingering in the background when one releases a new tweak is simply not acceptable.﻿

We tried to avoid the drama that comes with publicly critizing other developers and showed a lot of restraint and patience in working out a compromise with the CM team in private, however as anyone can see from the published communications our effort clearly have reached a dead end.

We strongly feel that this is an important issue not only for us but also other independent kernel devs and the entire community and we thus feel responsible to bring an end to this hurtful practise adopted by the CM team of creating additional unneccessary fragmentation. So we turn to you - the community - to ask you to voice your concerns to the CM team.


----------



## ThehulKK

If I cannot use my favorite kernel on CM9 then I'll just stop using their ROM. If they want to be egocentric pricks they can, Linux is open source, but it's not fair that they implement tweaks from other developers, not give them proper credit and then make their system incompatible to that same kernel. That's what I understood from reading the conversations, and they will get my email soon.

Sent from my Galaxy Nexus using Tapatalk 2


----------



## franciscofranco

ThehulKK said:


> If I cannot use my favorite kernel on CM9 then I'll just stop using their ROM. If they want to be egocentric pricks they can, Linux is open source, but it's not fair that they implement tweaks from other developers, not give them proper credit and then make their system incompatible to that same kernel. That's what I understood from reading the conversations, and they will get my email soon.
> 
> Sent from my Galaxy Nexus using Tapatalk 2


It's much worse than that a credit matter (I personally couldn't care less about credits). It's how it hurts the community.


----------



## samthe2can

Email sent. Its extremely sad to hear that this is happening in the Android community, it goes against what I believe android is really about.

Is there any other way we can help out?


----------



## phone_user

I remember Voodoo and BLN in NS. CM bah!

Color Control for GN,

*The Kernels using Ezekeel's Color Control*

GLaDOS / franco / Trinity / Lean / Popcorn / Air

*vs*

*The Kernels using CM's Color Control*

CM / CMPlus / faux123 / JameBond / FuguMod

Again, CM bah!


----------



## Ezekeel

Yeah it is really sad that it has come to this. The part that saddens me the most is that we were not able to work out a compromise with CM in private, but instead they chose to screw around with us for two month wasting our time. This is not the kind of respectful treatment I expect among Android devs. We should be working together instead of fighting over this.


----------



## nexus.prime

I will delete "CM" in my nandroid backup list


----------



## ThehulKK

nexus.prime said:


> I will delete "CM" in my nandroid backup list


Send them an email too

Sent from my Galaxy Nexus using Tapatalk 2


----------



## AshG

After a long discussion among members of the Administrative staff, we've decided to leave this thread open for discussion with the CM team member's email address removed. There were concerns brought up that some messages might be sent that approach the situation in a less constructive and informative manner than Ezekeel intended (i.e. obscenity-ridden tirades, insults, etc). This prompted the thread to be moved for review. Those of you so inclined to email members of the CyanogenMod team will do so whether or not their email address is listed here; it is our hope that having to go and find it for yourself will give you time to think calmly and rationally in composing your comments.

There are many people with strong feelings on both sides of this issue. We encourage you to find middle ground and discuss this in a mature and courteous manner.


----------



## franciscofranco

AshG said:


> After a long discussion among members of the Administrative staff, we've decided to leave this thread open for discussion with the CM team member's email address removed. There were concerns brought up that some messages might be sent that approach the situation in a less constructive and informative manner than Ezekeel intended (i.e. obscenity-ridden tirades, insults, etc). This prompted the thread to be moved for review. Those of you so inclined to email members of the CyanogenMod team will do so whether or not their email address is listed here; it is our hope that having to go and find it for yourself will give you time to think calmly and rationally in composing your comments.
> 
> There are many people with strong feelings on both sides of this issue. We encourage you to find middle ground and discuss this in a mature and courteous manner.


Seems reasonable. At least this is moved back to where it belongs so everyone can read and share to one another.


----------



## wiseguychacon

I will say that I have read what Ezeekel has said and I agree 100%. Now if im understanding correctly. It sounds like cm's kernel would not be where it is today if it had not borrowed certain tweaks from independent kernel devs. With that said I would think that they would be more willing to work something out that way there kernel can still borrow tweaks and also the independent devs can also still prosper from their individual apps for the efforts they put into said tweaks and so on. I for one gladly support indepedent devs they deserve it. Now for those that swear by cm and feel that they can do what ever they want cause they are cm. Which I've read in another site forum. Anyway those individuals should convert to iphonism and wait along with all of the other apple fan boys for there space ship to come along and take them to appleland.

Sent from a hole in the ground.


----------



## uproot

Forgive me, but I don't exactly understand what the issue is. If I use ezekeel's kernel, I buy his app, if I use francisco's, I buy his app, if I use CM's I use their controls. I don't expect any particular method to work on _every_ kernel, and if they don't implement correctly your features in their control, it just makes your app more necessary.

If they feel (even if it's for the dumbest reason) that your interface doesn't fit well with their project, then they're free to implement their own - i thought that was the point of the GPL. I mean, I've looked at code before and was like "this isn't organized enough, I'm going to rearrange how it's handled in my own project"; even if I was plain wrong, I still think it should still be OK for me to do that.

Edit: Is CM Rom control not working the only issue here? Or are there other problems that come from it?


----------



## samthe2can

Well I see it very simply, they won't support the community so I won't support them.


----------



## bmcclure937

Well, hate to say it... but that may be my last straw with CM. They have done a ton for the community (obviously) but they should not act like elitist dicks.

I will stick with AOKP on my Nexus.


----------



## jeagoss

All of our replies have been made over on the XDA thread. And as for "sparing ugly words in email", a bit too late folks. My personal email address as well my CM address both are flooded with emails I don't even care to share. But, I have a pretty awesomely thick skin, and know how to ignore such stuff. But I do have to say that the email barrage and what was actually said in the emails do not help the situation one bit. In part of caring for the community, I'd have to say there is a much better way of engaging the community that doesn't include obscenities, personal attacks, and veiled threats. And as for the threats, I'm a big boy who knows how to dance.

Want further discussion? Maybe tame the community a bit.

*Added* -- This is code people, nothing life threatening. Learn the difference.


----------



## jeagoss

In slightly more humorous news, I find it funny that I'm listed as a "Beginner". Silly forums and post counts.


----------



## yarly

Very few will ever be "done" with CM as nearly every ROM is a downstream source from it (aka, they either use it as a base or they take features from it). Unless you're compiling Android directly from the source given by google or you're using a pure OEM ROM that came with your phone, you're probably using something somehow that came from CM or was inspired by something in CM and will in the future.

You can use whatever you like, but most of the time, deep down, you're still using parts of CM or in the cases of phones like the Thunderbolt (for the groundwork of AOSP and the RIL) or devices like the Touchpad (for having Android at all) totally dependent on CM for what you have.

Also, it's a developer's right to do what they want, especially when they do it for free. Do you think Ubuntu sits around complaining to the world when Debian doesn't do something they like (because you know it happens)? No, they don't, and Ubuntu is dependant on Debian for its sources and gives nothing back to them directly. Ubuntu (Canonical) is a corporation making profits as well, while Debian is just a community developing in their spare time. Open source comes with no warranties and no guarantees, it even says so in most licenses (especially GPL).

From the Linux kernel:



> * This program is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU General Public License for more details.


In other words, you agree to use it without any expectation of support or any other help.

Sure, a developer can complain and drag it all over the forums, but what good will it do? Not too much. Just waste time they could be doing something more useful. Cyanogen isn't going to budge no matter how many claim they will never "touch" or "support" it again.


----------



## chadouming

jeagoss said:


> All of our replies have been made over on the XDA thread. And as for "sparing ugly words in email", a bit too late folks. My personal email address as well my CM address both are flooded with emails I don't even care to share. But, I have a pretty awesomely thick skin, and know how to ignore such stuff. But I do have to say that the email barrage and what was actually said in the emails do not help the situation one bit. In part of caring for the community, I'd have to say there is a much better way of engaging the community that doesn't include obscenities, personal attacks, and veiled threats. And as for the threats, I'm a big boy who knows how to dance.
> 
> Want further discussion? Maybe tame the community a bit.
> 
> *Added* -- This is code people, nothing life threatening. Learn the difference.


I do understand both point of view and find your e-mails address being flooded is completely stupid. This effectively won't change anything. I tought people were able, now, to know that this kind of stupidity won't make their cause go further. I'm sorry for you and happy from your answer. I'm still sad from community answer tho. Good luck with this.

Sent from my Galaxy Nexus using RootzWiki


----------



## OldManRiver

Is there an age limit on stupidity, most of the Adult's have enough "common" sense to discuss differences in a constructive manner. Can you imagine what would happen to our world if the leaders didn't negotiate in an equally open manner!


----------



## yarly

OldManRiver said:


> Is there an age limit on stupidity, most of the Adult's have enough "common" sense to discuss differences in a constructive manner. Can you imagine what would happen to our world if the leaders didn't negotiate in an equally open manner!


I think the last time something like that happened, this was the result:

(they really captured the expression of someone that was getting severely beaten with a cane







)


----------



## uproot

Ezekeel: if this post from the xda thread is not just bluster, it should assuage your earlier concern that "they will continue with their current practice of ripping-off other peoples' work when they see fit".



> [background=rgb(251, 248, 244)]From this point forward, CM will not be taking _ANY_ patches from the community. If a feature is liked by a user, it is now on the user to contact the author to submit the feature to CM's gerrit instance. This should prevent any 3rd party harm.[/background]


----------



## DarthG

phone_user said:


> I remember Voodoo and BLN in NS. CM bah!
> 
> Color Control for GN,
> 
> *The Kernels using Ezekeel's Color Control*
> 
> GLaDOS / franco / Trinity / Lean / Popcorn / Air
> 
> *vs*
> 
> *The Kernels using CM's Color Control*
> 
> CM / CMPlus / faux123 / JameBond / FuguMod
> 
> Again, CM bah!


Actually, imoseyons kernel is compatible with both versions of colorcontrol among other things, which is one of the reasons why its my fav.


----------



## Ezekeel

jeagoss said:


> All of our replies have been made over on the XDA thread. And as for "sparing ugly words in email", a bit too late folks. My personal email address as well my CM address both are flooded with emails I don't even care to share. But, I have a pretty awesomely thick skin, and know how to ignore such stuff. But I do have to say that the email barrage and what was actually said in the emails do not help the situation one bit. In part of caring for the community, I'd have to say there is a much better way of engaging the community that doesn't include obscenities, personal attacks, and veiled threats. And as for the threats, I'm a big boy who knows how to dance.
> 
> Want further discussion? Maybe tame the community a bit.
> 
> *Added* -- This is code people, nothing life threatening. Learn the difference.


First let me say that I think it is unfortunate and completely out of line when users attack you or any other CM team member on a personal level and even threaten you. That being said, let me also tell you that I frankly do not feel sorry for you since in my opinion you/CM brought this on yourself. We patiently tried for over two month to reason with CM in private. However, instead of actually working with us on a resolution you just gave us a run-around for two month jerking us around - I think anyone who actually took the time to read the original communications would agree. We told you explicitly that we plan on going public with this issue if we could not come to an agreement in private. What did you expect would happen then? That people would send your flowers for this? No, you knew exactly what the consequences would be and you made your decision. So please stop acting like you/CM are the victims here that are hustled by the mean kernel devs - again anyone that read the original communications know that this is not true.

I am out of time and got to go, but I will write more later concerning your posts in the XDA thread which unfortunately got locked. Yeah for RW for keeping the discussion open.


----------



## cybik

[background=rgb(251, 248, 244)]So let me get this straight.[/background]

The CM project takes some GPL code (and keeps it GPL'd so people can still take it back and improve upon it if they so desire), use it and improve it (to their view, but improvements are improvements), makes it "neutral" in order to make it usable on many devices (and yet STILL keep the code open), and CM gets blamed for it?

Seriously?


----------



## uproot

cybik said:


> The CM project takes some GPL code (and keeps it GPL'd so people can still take it back and improve upon it if they so desire), use it and improve it (to their view, but improvements are improvements), makes it "neutral" in order to make it usable on many devices (and yet STILL keep the code open), and CM gets blamed for it?


To be fair, it'd be illegal to non-GPL it, so they hardly get brownie points for that.

The sole issue is the "neutral" bit.


----------



## Ezekeel

cybik said:


> [background=rgb(251, 248, 244)]So let me get this straight.[/background]
> 
> The CM project takes some GPL code (and keeps it GPL'd so people can still take it back and improve upon it if they so desire), use it and improve it (to their view, but improvements are improvements), makes it "neutral" in order to make it usable on many devices (and yet STILL keep the code open), and CM gets blamed for it?
> 
> Seriously?


What the hell is a 'neutral' kernel tweak?

CM did not take a tweak and made it work on multiple devices. How is that supposed to work for a kernel tweak for different hardware? They did take a tweak and duplicated it under a different sysfs interface.

And I never said they did break any license. But just because something is allowed that does not mean it is a good idea to do so. The GPL never was intended as a replacement for common sense when dealing with the real world.


----------



## cybik

uproot said:


> What the hell is a 'neutral' kernel tweak?
> 
> CM did not take a tweak and made it work on multiple devices. How is that supposed to work for a kernel tweak for different hardware? They did take a tweak and duplicated it under a different sysfs interface.
> 
> And I never said they did break any license. But just because something is allowed that does not mean it is a good idea to do so. The GPL never was intended as a replacement for common sense when dealing with the real world.


By that I mean that the tweaked version is less device-dependant and the structure of it can be applied to multiple devices.

Also, come on, is it that hard to modify code to make it point to another sysfs structure and do conditional statements to detect if it's a CM kernel or not? If I had to do it, I'd do that in accessors by calling a utility method that verifies kernel structure.


----------



## chadouming

cybik said:


> I know people who take GPL code as their own and are huge douches about it.
> 
> By that I mean that the tweaked version is less device-dependant and the structure of it can be applied to multiple devices.
> 
> Also, come on, is it that hard to modify code to make it point to another sysfs structure and do conditional statements to detect if it's a CM kernel or not? If I had to do it, I'd do that in accessors by calling a utility method that verifies kernel structure.


That is not the point of it. If CM are taking stuff from Dev, why would the dev have to adapt to CM because they change how it's made ?


----------



## PacerguyDon

chadouming said:


> That is not the point of it. If CM are taking stuff from Dev, why would the dev have to adapt to CM because they change how it's made ?


Exactly! That is what I have taken from all of this, especially after reading the Gplus transcript between Ezekeel, Franco and the Cm guys.

Also, CM's stating that they changed the code to work with all the devices they support... Really... as Ezekeel pointed out, the code is hardware specific. How will the color control in Cm's rom work on a phone or tab that isn't running the same hardware? Does it? I've noticed that the Cm9 rom I had been using on my Xoom doesn't even have the color control installed (official nightlies).

I have to stand by the Kernel Devs on this... I appreciate all that CM has done over the years for us, but this episode just feels like a big step backwards.


----------



## cybik

PacerguyDon said:


> Exactly! That is what I have taken from all of this, especially after reading the Gplus transcript between Ezekeel, Franco and the Cm guys.
> 
> Also, CM's stating that they changed the code to work with all the devices they support... Really... *as Ezekeel pointed out, the code is hardware specific.* How will the color control in Cm's rom work on a phone or tab that isn't running the same hardware? Does it? I've noticed that the Cm9 rom I had been using on my Xoom doesn't even have the color control installed (official nightlies).
> 
> I have to stand by the Kernel Devs on this... I appreciate all that CM has done over the years for us, but this episode just feels like a big step backwards.


That's kind of the point: they abstracted it and made it hardware-unspecific.


----------



## yarly

uproot said:


> The GPL never was intended as a replacement for common sense when dealing with the real world.


I agree, but then again, everyone has to agree, because that's a tautology. Thus, that statement is always true (and makes for a weak argument) as nothing replaces common sense. It may not replace common sense, but it does come with explicit agreement that the software licensed under GPL comes with no warranty or implied support. In other words, use it at your own risk and don't expect it to stay compatible with everything one does.

Good example of this are the Gnome developers for the GTK and the Gnome desktop. They are assholes (just in case anyone isn't aware) and those that work with GTK (I feel sorry for them) are constantly screwed over by them, because they do not care what others think. They generally do the same with their desktop (as seen with those that refuse to use Gnome 3). Is it right they do that? No, but that's an opinion (well one I share, but I don't use Gnome/GTK either [prefer QT]). Does it win them points in the community...well not not really, except for the fanboys.

However, my point is, those that work with maintaining open source code can do what they want in the end (as long as the license allows) whether one group likes it or not. Sometimes this is for valid reasons (like Android letting go of some nasty SDK crap in Android 1.x → 2.x and then in 2.x → 4.x), sometimes for questionable reasons (like Guido van Rossum breaking tons of crap in Python 2 to Python 3), and sometimes for really stupid reasons (like Gnome).

In the end, when software changes, there's always someone who's never happy. Sometimes they're just crybabies...other times, they have some good reasons to be complaining. Regardless of which anyone believes, we're unfortunately seeing it here.


----------



## yarly

PacerguyDon said:


> Also, CM's stating that they changed the code to work with all the devices they support... Really... as Ezekeel pointed out, the code is hardware specific. How will the color control in Cm's rom work on a phone or tab that isn't running the same hardware? Does it? I've noticed that the Cm9 rom I had been using on my Xoom doesn't even have the color control installed (official nightlies).


As pointed out, software development has these wonderful things called "abstraction" and "polymorphism" which C (the language of the Kernel) does through using struct types and pointers. Those won't make much sense to you or the topics if you don't do software development, but I can assure that not writing code that is reusable is just asinine and real developers don't do it.

Basically they make the code that's specific for one platform or device work the same from the perspective of the user of the code by layering hardware/platform specific code at the bottom and then layers of code that are not hardware specific on top of those so the user of the code generally stays away from the bottom where things might be subject to change at times.

To use a metaphor, if someone were able to swap out your air conditioner with an air conditioner of another manufacturer and you never worked on anything yourself under the hood, would you really notice as the user driving the car? That's what software abstraction kind of is. It's the core fundamental to software development. Good software design you basically swap out code in the same way you swap out parts of a car with little to no impact. Bad software design and you need to replace half of the stuff under your hood just to change the air filter or it breaks everything.



> Also, CM's stating that they changed the code to work with all the devices they support... Really... as Ezekeel pointed out, the code is hardware specific. How will the color control in Cm's rom work on a phone or tab that isn't running the same hardware? Does it? I've noticed that the Cm9 rom I had been using on my Xoom doesn't even have the color control installed (official nightlies).


Because technically CM9 is still at the Alpha stage regardless of its current stability. Features are subject to not being fully supported until the hardware level code is integrated into the abstracted code for the color control. When CM9 is released for stable and still does not have it for it, then you can complain. If you ever used a piece of software that was still in development and had to for example, work on Linux, OSX and Windows, you would encounter the same sort of things where some parts are not added in for certain platforms until the project is totally synced up.

However, it might not even be for that reason at all. The person that maintains that device may not have chosen to add it in yet for whatever reason he feels. That's something you would have to ask him if your really really want to know.


----------



## chadouming

cybik said:


> That's kind of the point: they abstracted it and made it hardware-unspecific.


Explain me how do you want to make something that is hardware specific hardware-unspecific ?


----------



## chadouming

yarly said:


> Because technically CM9 is still at the Alpha stage. When CM9 is released for stable and still does not have it for it, then you can complain.


He will have to complain, well, complain is a strange term for this. How can you complain about something that is free and offered to you not forced ? My point is that this won't be available to his device. It's not the same screen, not the same driver. You can't simply move these "Hack" around.


----------



## yarly

chadouming said:


> He will have to complain, well, complain is a strange term for this. How can you complain about something that is free and offered to you not forced ? My point is that this won't be available to his device. It's not the same screen, not the same driver. You can't simply move these "Hack" around.


1) CM writes a generalized specification for what needs done in each device to interface with their abstracted color control
2) maintainer of device uses the specific API for the drivers of the device they maintain to do such specific interfacing from the very bottom of the C kernel code so that the end result from someone looking at code layer above, the code acts the same way as it should on any other device. Basically they're writing a middleware abstraction layer between the driver and the color control based on the specifications that CM told them to do so that the functionality is the same on all devices. To software developers, this is called the adapter pattern. In short, it's used to make a "square peg" fit a "round hole"
3) maintainer pushes changes into git.
4) voila, color control code works the same on every device because it was abstracted out by the maintainer of each device.

Don't believe me? Then learn to read C code and go look at the Cyanogen Kernel, because this is what has happened since the very first Cyanogen was put on more than one device. Because simply replying back saying "no they don't" is not a valid counter argument until you can show me how they don't in the source itself.

Concrete (core) code changes per device. The layers on top of that which control the features found in apps and settings all use the same code provided by the magic of abstraction.


----------



## chadouming

yarly said:


> 1) CM writes a generalized specification for what needs done in each device to interface with their abstracted color control
> 2) maintainer of device uses the specific API for the drivers of the device they maintain to do such specific interfacing from the very bottom of the C kernel code so that the end result from someone looking at code layer above, the code acts the same way as it should on any other device. Basically they're writing a middleware abstraction layer between the driver and the color control based on the specifications that CM told them to do so that the functionality is the same on all devices. To software developers, this is called the adapter pattern. In short, it's used to make a "square peg" fit a "round hole"
> 3) maintainer pushes changes into git.
> 4) voila, color control code works the same on every device because it was abstracted out by the maintainer of each device.
> 
> Don't believe me? Then learn to read C code and go look at the Cyanogen Kernel, because this is what has happened since the very first Cyanogen was put on more than one device. Because simply replying back saying "no they don't" is not a valid counter argument until you can show me how they don't in the source itself.
> 
> Concrete (core) code changes per device. The layers on top of that which control the features found in apps and settings all use the same code provided by the magic of abstraction.


w/e, They might have fun with abstraction layer, this is not the problem. All of this is still software related. When it come to hardware, i'm sorry, but i doubt they will be able to correct the color of Amoled, Amoled+, Super Amoled+, TFT-LCD and SuperLCD the same way simply because they do an api for this. For sure, this is supposing that they can make an api for the whole. Again, color correction is simply an example.


----------



## uproot

yarly said:


> There are plenty of GPL projects out there that the developer meant to only run on one OS such as Linux, UNIX, OSX or even windows. Perhaps we should go complain to them for not being "neutral" as well and supporting every OS because they added in source code that is only compatible with a certain system because it makes calls directly to certain APIs only available on a certain platform?


Perhaps but not necessarily (I can imagine exceptions where it would be just dumb not to make cross-platform), and I really don't see what the analogy is to this scenario. If it's GPL then, as I pointed out before, anyone has the _right _to make changes to the interface so that it'd work on all platforms, or indeed whatever changes they'd like. Having the right does not always make it a good idea, however.


----------



## JS0724

IMHO, Ezekeel, this whole thing is childish and uncalled for. This does not hurt the community at all in my opinion. Honestly, the way it looks to me is that you developed something. CM liked it, but chose to implement it differently. Big deal. You aren't being forced to adhere to their implementation. And if CM users want to use your different implementation, then rom control will step out of the way to let your paid app control your kernel. Profit?

So please, maybe I'm missing something, but explain how this decision is directly going to affect me, the user. I personally like to have choices. That's what I like about Android. Again, maybe I'm mistaken, but it seems like you are just upset that your implementation was not made the CM standard.

The above is MY opinion. Take it for what it's worth.


----------



## franciscofranco

cybik said:


> That's kind of the point: they abstracted it and made it hardware-unspecific.


What? The code doesnt work unless we're sporting an AMOLED device. Im not even sure it will work on a AMOLED Plus.


----------



## franciscofranco

JS0724 said:


> IMHO, Ezekeel, this whole thing is childish and uncalled for. This does not hurt the community at all in my opinion. Honestly, the way it looks to me is that you developed something. CM liked it, but chose to implement it differently. Big deal. You aren't being forced to adhere to their implementation. And if CM users want to use your different implementation, then rom control will step out of the way to let your paid app control your kernel. Profit?
> 
> So please, maybe I'm missing something, but explain how this decision is directly going to affect me, the user. I personally like to have choices. That's what I like about Android. Again, maybe I'm mistaken, but it seems like you are just upset that your implementation was not made the CM standard.
> 
> The above is MY opinion. Take it for what it's worth.


This actually hurts our direct app sales because if CM gives the same interface as us and its compatible with our implementation people wont waste money on a 3rd party app as long as CM features it. But because CM decided to change the original implementation, like it was explained 30 million times already, the users will have to choose either use cm stock kernel with rom control, or use our kernels and are bound to either buy our apps to change color on the fly, or use/learn linux terminal commmands.

In the end we, devs, are going all for the comunity and not thinking of supposed profit loss (yes we have to rely on app profit to fund our development) if we all had the same interface. I dont give a rats ass about credits or about losing a few bucks over less app sales, I just want the community not to have fragmentation and be happy, no more, no less.


----------



## jeagoss

At this point, there is no making the situation better. The only real way to "fix" the situation is to completely remove the code.

Why is this the only option? Well, we took code and made it work across multiple devices in the same architecture. There was no "purposeful" breakage of anything. We didn't see something and say "We like this, but lets change everything about it just because we can." We do have technical reasoning behind our changes. Reasoning that was explained. Reasoning that is also just not being accepted.

Technical reasoning? We are moving to a unified kernel amongst our like architecture devices. We don't want to maintain 5 different kernels. We want to maintain one kernel for 5 devices. It is much easier to do. It also takes up far less space in our github organization; takes up less space in our gerrit instance; and takes less time to download through repo. It reduces the amount of time we have to spend on each device, allowing us to spend more time on actually developing CM.

As this has been demonstrated, not everyone can be happy with everything. We made what we thought was a good call. People are unhappy. If we switch implementations, people will still be unhappy because now they have to work to switch and adapt.

So, the only real option is to completely remove and not support the feature. But this will make people who use the feature unhappy. No matter what, we will be the bad guys. Either we will be bad guys for changing something, for not changing something, or for not using something. And this isn't some "boo hoo, feel sorry for us." We are perfectly fine with taking heat from people. We are quite used to it actually. We have thick skins.

So, this is where we are left. We want to support the feature as is because in the long run, it makes sense to us in every technical aspect. It is quite easy to maintain in the current form with the plans we have as a group. It fits into our grand scheme of things. But, if the community doesn't want this, then we won't support the feature at all. We'll allow someone else to support it (which we already do, and have repeatedly told everyone we already do)

User confusion? Simply averted by stating "use this kernel with this control program". We do it all of the time. We trust that our users are smart enough to read. Several of our own maintainers have kernels they maintain with different features than CM's kernels. And they point it out to their user base.

This is where we stand. We either maintain an implementation that is easy for us to work on with multiple devices, or we don't use the feature at all. We aren't being cocky. We aren't being heavy handed. It's just how it is. We don't get paid to do this. We all have jobs we do, families to be with, and hobbies we like. So anything we can do to make life easier on ourselves we will try to do.


----------



## JS0724

franciscofranco said:


> This actually hurts our direct app sales because if CM gives the same interface as us and its compatible with our implementation people wont waste money on a 3rd party app as long as CM features it. But because CM decided to change the original implementation, like it was explained 30 million times already, the users will have to choose either use cm stock kernel with rom control, or use our kernels and are bound to either buy our apps to change color on the fly, or use/learn linux terminal commmands.
> 
> In the end we, devs, are going all for the comunity and not thinking of supposed profit loss (yes we have to rely on app profit to fund our development) if we all had the same interface. I dont give a rats ass about credits or about losing a few bucks over less app sales, I just want the community not to have fragmentation and be happy, no more, no less.


So the real problem is you can't profit monetarily without fragmentation? If you want app sales, use your current implementation. If you want less fragmentation, use CM's. Am I right?

This really sounds like you are blaming CM for the moral dilemma you are facing.


----------



## franciscofranco

JS0724 said:


> So the real problem is you can't profit monetarily without fragmentation? If you want app sales, use your current implementation. If you want less fragmentation, use CM's. Am I right?
> 
> This really sounds like you are blaming CM for the moral dilemma you are facing.


I want the best for the users (I believe I can speak up for Ezekeel, Morfic and Imo as they want the best for the users as well) I have said that a hundred times. And dont put shit on my mouth that I didnt say.

I give up trying to explain the same over and over. Go read the OP.


----------



## Ezekeel

cybik said:


> At this point, there is no making the situation better. The only real way to "fix" the situation is to completely remove the code.
> 
> Why is this the only option? Well, we took code and made it work across multiple devices in the same architecture. There was no "purposeful" breakage of anything. We didn't see something and say "We like this, but lets change everything about it just because we can." We do have technical reasoning behind our changes. Reasoning that was explained. Reasoning that is also just not being accepted.
> 
> Technical reasoning? We are moving to a unified kernel amongst our like architecture devices. We don't want to maintain 5 different kernels. We want to maintain one kernel for 5 devices. It is much easier to do. It also takes up far less space in our github organization; takes up less space in our gerrit instance; and takes less time to download through repo. It reduces the amount of time we have to spend on each device, allowing us to spend more time on actually developing CM.
> 
> As this has been demonstrated, not everyone can be happy with everything. We made what we thought was a good call. People are unhappy. If we switch implementations, people will still be unhappy because now they have to work to switch and adapt.
> 
> So, the only real option is to completely remove and not support the feature. But this will make people who use the feature unhappy. No matter what, we will be the bad guys. Either we will be bad guys for changing something, for not changing something, or for not using something. And this isn't some "boo hoo, feel sorry for us." We are perfectly fine with taking heat from people. We are quite used to it actually. We have thick skins.
> 
> So, this is where we are left. We want to support the feature as is because in the long run, it makes sense to us in every technical aspect. It is quite easy to maintain in the current form with the plans we have as a group. It fits into our grand scheme of things. But, if the community doesn't want this, then we won't support the feature at all. We'll allow someone else to support it (which we already do, and have repeatedly told everyone we already do)
> 
> User confusion? Simply averted by stating "use this kernel with this control program". We do it all of the time. We trust that our users are smart enough to read. Several of our own maintainers have kernels they maintain with different features than CM's kernels. And they point it out to their user base.
> 
> This is where we stand. We either maintain an implementation that is easy for us to work on with multiple devices, or we don't use the feature at all. We aren't being cocky. We aren't being heavy handed. It's just how it is. We don't get paid to do this. We all have jobs we do, families to be with, and hobbies we like. So anything we can do to make life easier on ourselves we will try to do.


Ah, you came up with a new reason to justify what CM did. The technical reason that CM is going to do what Google, all hardware manufacturers and the entire kernel dev scene has longed for since day one: You gonna unify the Android kernel to make it work across different hardware devices. Well in that case it of course makes sense.

I do not want to be rude, but the only answer to that I can think of is: Are you fucking kidding me? And who from the CM team is going to accomplish this glorious feat? Lord Chaos?

I do not know how much coding experience with the Linux/Android kernel you have, but I am in serious doubt you know what you are claiming there.

I see the headlines 'CM unifies Android kernel. Community ecstatic. Steve Kondik sworn in as chancellor of the Republic.'

Please, do not kid yourself! CM is never ever gonna accomplish that! NEVER! There are higher chances that some deity reaches down from the sky and hands us a unified Android kernel than CM actually doing this.

Let us be honest here. This is just another evasive move, so CM does not have to come clean and say it out clear: 'Yeah, in this case we fucked up.'. This is what happened and what the first two posts on XDA actually conveyed to me. Then Steve K. started to try to weasel out of this. First by playing the blame and victim game, then playing the greedy (from now on know as brainfart, see above) card. How about CM starts to act like a man and stands by the decisions they made which lead to this mess.

So back to the core topic: If CM actually stands by its word and in the future will not simply take kernel patches, but instead ask the original devs to submit it to gerrit, trouble like this could be avoided. It is a good decisions and I support that. It does not rectify the damage done since we are still left with duplicate interfaces on several devices, however it is more important that such mess will not be repeated in the future.


----------



## PonsAsinorem

I don't have the time right now to write a long winded post, so here's my thoughts in a nutshell:

If all we're worried about is fragmentation, why doesn't everyone pick a standard and use that. Since CM (my thoughts and are not backed by any proof) is the largest aftermarket ROM in terms of devices supported, maintainers, and users, doesn't it make sense to follow their standard? Plus they said they won't change their stance, so that's a strong albeit cheap point to adopt. Last question: How many independent kernel devs with a substantial user base are actually hurt by this? Do they outnumber CM's 50+ maintainers and however large their user base is? I highly doubt it, but I could be wrong.

This thread was useful, but it's starting to live past it's prime. Nothing they did was illegal. CM has already said they aren't changing it, so this thread is degrading into a bunch of complaining directed at a wall.


----------



## abbofro

PonsAsinorem said:


> I don't have the time right now to write a long winded post, so here's my thoughts in a nutshell:
> 
> If all we're worried about is fragmentation, why doesn't everyone pick a standard and use that. Since CM (my thoughts and are not backed by any proof) is the largest aftermarket ROM in terms of devices supported, maintainers, and users, doesn't it make sense to follow their standard? Plus they said they won't change their stance, so that's a strong albeit cheap point to adopt. Last question: How many independent kernel devs with a substantial user base are actually hurt by this? Do they outnumber CM's 50+ maintainers and however large their user base is? I highly doubt it, but I could be wrong.
> 
> This thread was useful, but it's starting to live past it's prime. Nothing they did was illegal. CM has already said they aren't changing it, so this thread is degrading into a bunch of complaining directed at a wall.


Because cm isn't god. The independent devs create this work, therefore cm should honor this and use their interfaces. 
The exact same courtesy other devs give cm when implementing their work.
Sound fair? Yes. 
Sent from my Galaxy Nexus using Tapatalk 2


----------



## PonsAsinorem

abbofro said:


> Because cm isn't god. The independent devs create this work, therefore cm should honor this and use their interfaces.
> The exact same courtesy other devs give cm when implementing their work.
> Sound fair? Yes.
> Sent from my Galaxy Nexus using Tapatalk 2


That doesn't make sense to me. Correct, CM isn't God. Never said they were. And furthermore they didn't steal code or do anything illegal (so there's no real case) , they took open source and adapted it to their needs. That's the whole point of open source. Can you fault them for doing what works for them? No, but some people are trying.

And most, not all, devs who took CM code (my assumption) didn't implement CM code the way they did out of respect, but out of complacency. It works out of the box, so they didn't change anything. What they do out of respect is give credit.


----------



## JBowdacious

PonsAsinorem said:


> I don't have the time right now to write a long winded post, so here's my thoughts in a nutshell:
> 
> If all we're worried about is fragmentation, why doesn't everyone pick a standard and use that. Since CM (my thoughts and are not backed by any proof) is the largest aftermarket ROM in terms of devices supported, maintainers, and users, doesn't it make sense to follow their standard? Plus they said they won't change their stance, so that's a strong albeit cheap point to adopt. Last question: How many independent kernel devs with a substantial user base are actually hurt by this? Do they outnumber CM's 50+ maintainers and however large their user base is? I highly doubt it, but I could be wrong.
> 
> This thread was useful, but it's starting to live past it's prime. Nothing they did was illegal. CM has already said they aren't changing it, so this thread is degrading into a bunch of complaining directed at a wall.


A simple fact, they may have 50 devices "maintained" but VERY few have been considered stable. Many users don't find that acceptable, including myself. They aren't the ONLY AOSP based ROM, so they shouldn't isolate other developers just because they aren't part of this now overly massive project.


----------



## nexus.prime

CM is the fount of Custom ROMs but not one of kernels, at least Nexus Phones

Sent from my Galaxy Nexus


----------



## Ezekeel

PonsAsinorem said:


> That doesn't make sense to me. Correct, CM isn't God. Never said they were. And furthermore they didn't steal code or do anything illegal (so there's no real case) , they took open source and adapted it to their needs. That's the whole point of open source. Can you fault them for doing what works for them? No, but some people are trying.
> 
> And most, not all, devs who took CM code (my assumption) didn't implement CM code the way they did out of respect, but out of complacency. It works out of the box, so they didn't change anything. What they do out of respect is give credit.


It is not a GPL issue. This had been explained a gazillion times already. You apparently did not bother to read any post in this thread. Otherwise you would have realized that CM already has agreed to handle implementation of other dev's works differently in the future.


----------



## bmcclure937

jeagoss said:


> At this point, there is no making the situation better. The only real way to "fix" the situation is to completely remove the code.
> 
> Why is this the only option? Well, we took code and made it work across multiple devices in the same architecture. There was no "purposeful" breakage of anything. We didn't see something and say "We like this, but lets change everything about it just because we can." We do have technical reasoning behind our changes. Reasoning that was explained. Reasoning that is also just not being accepted.
> 
> Technical reasoning? We are moving to a unified kernel amongst our like architecture devices. We don't want to maintain 5 different kernels. We want to maintain one kernel for 5 devices. It is much easier to do. It also takes up far less space in our github organization; takes up less space in our gerrit instance; and takes less time to download through repo. It reduces the amount of time we have to spend on each device, allowing us to spend more time on actually developing CM.
> 
> --cut--


That is the major problem. Who says that people want unified kernels across multiple devices of similar architecture?! (not the users, the devs) The best part about kernel development is the ability to write/use a kernel tailored for a specific device to milk every ounce of performance and efficiency possible. If you begin to recycle kernels across devices then you will lose out on this benefit. Yeah, yeah... I understand that the devs may want this because it is "easier to maintain" or "easier to organize on GitHub", but is that really a major concern?!

Leave the kernel development to the experienced kernel devs. The "functionality" you are worried about CM users missing if you revert these changes is a non-argument since it is available from any third-party kernel dev in some way, shape, or form.

Also, ROMs like AOKP offer basic kernel (CPU) control that works across all kernels. CM can do the same and then offer an additional app that can be used to control "CM Kernels" if the user wishes to use the stock CM kernel. The end-user should have choice and not be pigeon-holed into using the stock CM kernel if they want to have kernel control functionality built directly into the OS.

Finally, for those saying that the kernel devs are only making a fuss because they will miss out on app sales... yes, their kernel control apps help to support their development. *But this is not the point!!* For example, IMoseyOn does not sell an app on the market or make $$ on kernel development (besides donations). He supports multiple devices. There are some scripts available to control his ROM and app in the works.


----------



## bigeyes0x0

Reading this thread I wonder if some of you have ability to read and comprehend what the original poster or other independent devs involved want. The problem they had with CM is not GPL, or in this case about CM took their code and implemented it, it is how they implemented it and made it incompatible with the original implementation thus caused actual fragmentation in user experience when users ever use CM and it had nothing to do with these devs' paid apps that some said or whatever software development terms that another thought to be related.
IMO, is it so hard for CM to wrote another 2 or 3 lines of code for each conflicted sysfs from the ROM-side to create a unified experience for users? Is it the less they can do for the community to unify the experience? is it just a little courtesy to the devs that they borrowed the code? I guess they found it too hard and instead choose to let everything goes through gerrit which didn't fix the issue that had happened.

My personal feeling: Thanks for nothing CM you solved null of what happened and gave us a big FU on this, it's really sad as you have done a lot of great things.


----------



## blowtorch

To the kernel devs, first of all good job and thank you for developing all these kernel tweaks we all love them. Again I thank you for your innovation and hard work that improve our devices.

Now having said that, if your devs really want whats best for users than you should stop all this whining and squash this already. This is whats hurting the community. If cm decides to remove these features (that we know you worked hard to develop) because of all this ranting and public witch hunt than how is that beneficial to users? ... ... Its not!

I will continue to support both individual developers as well as the cm team but we need to stop all this childish whining because in the end all cm did was use gpl code in the way they saw fit.


----------



## Ezekeel

blowtorch said:


> If CM actually stands by its word and in the future will not simply take kernel patches, but instead ask the original devs to submit it to gerrit, trouble like this could be avoided. It is a good decisions and I support that. It does not rectify the damage done since we are still left with duplicate interfaces on several devices, however it is more important that such mess will not be repeated in the future.


was so hard to understand.

Read, think, write - in that order. That is how a forum works.


----------



## chadouming

bigeyes0x0 said:


> Reading this thread I wonder if some of you have ability to read and comprehend what the original poster or other independent devs involved want. The problem they had with CM is not GPL, or in this case about CM took their code and implemented it, it is how they implemented it and made it incompatible with the original implementation thus caused actual fragmentation in user experience when users ever use CM and it had nothing to do with these devs' paid apps that some said or whatever software development terms that another thought to be related.
> IMO, is it so hard for CM to wrote another 2 or 3 lines of code for each conflicted sysfs from the ROM-side to create a unified experience for users? Is it the less they can do for the community to unify the experience? is it just a little courtesy to the devs that they borrowed the code? I guess they found it too hard and instead choose to let everything goes through gerrit which didn't fix the issue that had happened.


I agree with all you said up to here and wan't to congradulate you. You are one of the few who really read and understood the questions. No, cm team does not deserve a big FU. They solved a lot of problem and helped us with a lot of thing. I appreciate CM a lot and thing it's probably the biggest android project. It didnt became that big with nothing behind.

Sent from my Galaxy Nexus using RootzWiki


----------



## bigeyes0x0

Nah, I didn't mean it like that, what I meant was the way they did it felt like they, CM, gave us the community a big ... like they don't care and when people put the issue to public their action was just like: ok, then we do this but that actually wasn't done to fix the damage only to prevent it to ever happen again. For the latter I commend them, but still it put a sour note on me about them.

EDIT: To clarify: what I said in your quote is from my rationale mind and not my personal feeling as explicitly said. You can disagree with my personal feeling all you want .


----------



## jeagoss

Unifying kernels across devices of like architecture makes maintenance much easier on the CM team. It also reduces the amount of space we have to pay for on a monthly basis. A kernel for each and every device takes a lot of room. It also gets very expensive. While we do get donations, it isn't at a rate that pays for all of this. And since we make it a point to actually ask for donations only when they are REALLY needed, we end up paying for this out of pocket. While the common thought is that we are massively rich, it just isn't true.

And maintaining a single kernel is much easier than maintaining multiple kernels. In our minds, it works to the communities benefit by allowing us to reduce maintenance time on one item, which in turn allows us to work on other items. We are trying to make the most out of our limited time.

Once again, we are not trying to be bullies or destroy people. We are trying to work on something we like to work on and give the product of our work to the community. Yes, some things don't work as planned.

No matter what, someone will be unhappy. We will always be the bad guy, no matter how much we try not to be. We've known this for a while. But we will continue pushing forward doing the work we enjoy giving away. And as things come up, we will learn from them and change accordingly. We've already made changes to avoid situations like this one in the future. I'm sure something else will come along that we will have to learn from. It is the nature of the beast.


----------



## jeagoss

Also, while CM and Ezekeel and other devs have been in this rift, I'd like to point out that Ezekeel has been nothing but respectful. People need to take note of this. You can disagree with something and not be a complete [insert your favorite insult here]. And while we disagree on our positions, I'd like to thank Ezekeel.


----------



## bigeyes0x0

Yeah and then you/CM chose a path that is practically can be compared to the decision MS did for Windows 8 on ARM and API for third party browser in your email with Ezekeel. Just that I don't know what to say considering Windows is a close source product and yours specifically the parts causing problems are based on community source.

I am really thankful to Ezekeel and other devs had brought this to public attention so we don't have to see another "evil empire" emerge, especially one from the FOSS community. Now that every 3rd party codes have to go through gerrit this aren't going to happen again, my wish is just that CM just go the extra length of actually fixing what damage they have dealt. This for me at least will fix CM reputation entirely in my heart. Yeah I do love CM ROM.


----------



## abbofro

jeagoss said:


> Also, while CM and Ezekeel and other devs have been in this rift, I'd like to point out that Ezekeel has been nothing but respectful. People need to take note of this. You can disagree with something and not be a complete [insert your favorite insult here]. And while we disagree on our positions, I'd like to thank Ezekeel.


Couldn't agree more.
Sent from my Galaxy Nexus using Tapatalk 2


----------



## Ezekeel

jeagoss said:


> Also, while CM and Ezekeel and other devs have been in this rift, I'd like to point out that Ezekeel has been nothing but respectful. People need to take note of this. You can disagree with something and not be a complete [insert your favorite insult here]. And while we disagree on our positions, I'd like to thank Ezekeel.


Thank you. I can only pass that compliment back to you. While I am not happy of how things went down and still a bit grumpy when I think about it, I am aware that you neither did cause that issue in the first place nor made the decisions that lead to this drama. You were just in the unlucky position to be the CM public relations guy when this happened. And shooting the messenger is always a bit unfair for the messenger.

Since some people might have missed it once more in big letters:
CM has suggested a workable solution for avoid similar issues in the future and we have accepted that.
You can still have your opinion on the issue and are allowed to say it, but consider whether from this point forward it will do any good.


----------



## jt1134

Ezekeel said:


> As I said before I am still more than skeptical about this unified kernel you are talking about. This would be pretty much the holy grail of Android kernel development and I am always careful when people promise wonders. But we will see how this works out. I am definitely very curious.


He's not talking about a unified kernel for *all* devices, but a unified kernel for ~5 similar devices, another kernel for another ~5 similar devices, etc. There are many kernel trees on cm's git that could be merged with a little work and reduce fragmentation. Note from jeagoss quote: "devices of like architecture"

Sent from my Galaxy Nexus using RootzWiki


----------



## Ezekeel

jt1134 said:


> He's not talking about a unified kernel for *all* devices, but a unified kernel for ~5 similar devices, another kernel for another ~5 similar devices, etc. There are many kernel trees on cm's git that could be merged with a little work and reduce fragmentation. Note from jeagoss quote: "devices of like architecture"
> 
> Sent from my Galaxy Nexus using RootzWiki


Still not gonna happen.


----------



## jt1134

Ezekeel said:


> Still not gonna happen.


Um, some folks have already done things like that. See the Aries kernel tree for instance. 5+ devices merged into a single common base.

Sent from my Galaxy Nexus using RootzWiki


----------



## Ezekeel

jt1134 said:


> Um, some folks have already done things like that. See the Aries kernel tree for instance. 5+ devices merged into a single common base.
> 
> Sent from my Galaxy Nexus using RootzWiki


My assessment was not based on the believe that it cannot be done, but on the understanding that it is a ton of work and we are talking about CM here - a dev group which is not exactly renown for their great kernel development.


----------



## jt1134

Ezekeel said:


> My assessment was not based on the believe that it cannot be done, but on the understanding that it is a ton of work and we are talking about CM here - a dev group which is not exactly renown for their great kernel development.


Um, WOW

On behalf of myself and dozens of other CM contributors who had no part in this situation here, I'll leave you be on your elitist pedestal, and just go back to working on our "not-so-great" development work.

Good day.


----------



## Ezekeel

jt1134 said:


> Um, WOW
> 
> On behalf of myself and dozens of other CM contributors who had no part in this situation here, I'll leave you be on your elitist pedestal, and just go back to working on our "not-so-great" development work.
> 
> Good day.


CM has released a lot of great ROM work, but how often you hear someone say: 'Wow that CM kernel is so amazing'?


----------



## jt1134

Ezekeel said:


> CM has released a lot of great ROM work, but how often you hear someone say: 'Wow that CM kernel is so amazing'?


I'm sorry, but that's about the lamest response you could have given.

User responses to the built-in kernel has no bearing whatsoever on individual contributors drive and talent in regards to consolidating code. There are plenty of folks that work on that daily that you have likely never interacted with, probably never even heard of, and a lot of them never even post on the forums.

Your generalized attacks on the character, talent, etc of cm contributors based on your interactions with a small group of cm's members only shows a lack of understanding on how this works as a whole, and succinctly justifies my previous "elitist pedestal" comment. Thanks.

Sent from my Galaxy Nexus using RootzWiki


----------



## Ezekeel

jt1134 said:


> I'm sorry, but that's about the lamest response you could have given.
> 
> User responses to the built-in kernel has no bearing whatsoever on individual contributors drive and talent in regards to consolidating code. There are plenty of folks that work on that daily that you have likely never interacted with, probably never even heard of, and a lot of them never even post on the forums.
> 
> Your generalized attacks on the character, talent, etc of cm contributors based on your interactions with a small group of cm's members only shows a lack of understanding on how this works as a whole, and succinctly justifies my previous "elitist pedestal" comment. Thanks.
> 
> Sent from my Galaxy Nexus using RootzWiki


I did not attack anybody. I just voiced my opinion which is based on my experience with the CM team so far and on the development work of the CM team I have seen so far. I am quite aware that this information is limited and does not properly reflect the whole truth about CM. But unfortunately I am not all-knowing and this limited information is all I got. What do you want me to do? Do I have to read every line of code CM has published and talk to every member of the CM team before I am allowed to make an assessment on something CM has claimed it will do.

So what do you think, how long it will take until we see the first unified CM kernel working for let us say at least four different hardware devices? Two month? Three month? Six month?


----------



## jt1134

Ezekeel said:


> I did not attack anybody. I just voiced my opinion which is based on my experience with the CM team so far and on the development work of the CM team I have seen so far. I am quite aware that this information is limited and does not properly reflect the whole truth about CM. But unfortunately I am not all-knowing and this limited information is all I got. What do you want me to do? Do I have to read every line of code CM has published and talk to every member of the CM team before I am allowed to make an assessment on something CM has claimed it will do.
> 
> So what do you think, how long it will take until we see the first unified CM kernel working for let us say at least four different hardware devices? Two month? Three month? Six month?


You dont have to come right out and say "f you" to someone to get the same point across. My six year old is already a master at such wordsmithing









With that in mind reread your replies to me, and the attacks are not difficult at all to spot.

And why would anyone read all of cm's source code? Of course that's ridiculous and impractical. I would simply ask you refrain from ill-informed negative responses to anything someone from cm says. In a thread with the words "egocentric" and "community" in the title, I'm saddened to see a well respected and talented developer as yourself speak in such a manner in such a thread.

As far as the eta question, I can't answer that as I contribute only to 1 device directly at the moment, and everyone knows the first rule of cyanogenmod









Sent from my Galaxy Nexus using RootzWiki


----------



## Ezekeel

jt1134 said:


> You dont have to come right out and say "f you" to someone to get the same point across. My six year old is already a master at such wordsmithing
> 
> 
> 
> 
> 
> 
> 
> 
> 
> With that in mind reread your replies to me, and the attacks are not difficult at all to spot.
> 
> And why would anyone read all of cm's source code? Of course that's ridiculous and impractical. I would simply ask you refrain from ill-informed negative responses to anything someone from cm says. In a thread with the words "egocentric" and "community" in the title, I'm saddened to see a well respected and talented developer as yourself speak in such a manner in such a thread.
> 
> As far as the eta question, I can't answer that as I contribute only to 1 device directly at the moment, and everyone knows the first rule of cyanogenmod
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Sent from my Galaxy Nexus using RootzWiki


Please do you not tell me what I try to say with the things I do say. What are you - a freaking mind-reader? Everything I said was meant exactly the way I said it. There is no hidden message. This is not the Da Vinci Code.

And sorry, but I have to decline your request. I will continue to voice my doubt when I hear someone making claims about things I find not believable - and I do not care if this person is a member of the Vatikan, the Imperial Guard, the Denver Broncos, the CM team or of some other group.


----------



## jt1134

Ezekeel said:


> Please do you not tell me what I try to say with the things I do say. What are you - a freaking mind-reader? Everything I said was meant exactly the way I said it. There is no hidden message. This is not the Da Vinci Code.
> 
> And sorry, but I have to decline your request. I will continue to voice my doubt when I hear someone making claims about things I find not believable - and I do not care if this person is a member of the Vatikan, the Imperial Guard, the Denver Broncos, the CM team or of some other group.


Sigh

Its obvious you don't get it. I'll make it obvious that I don't care by not responding any more. Theres obviously no point. Have a good day.

Sent from my Galaxy Nexus using RootzWiki


----------



## Ezekeel

jt1134 said:


> Sigh
> 
> Its obvious you don't get it. I'll make it obvious that I don't care by not responding any more. Theres obviously no point. Have a good day.
> 
> Sent from my Galaxy Nexus using RootzWiki


Ah come on. Don't be a sissy. It just started to be fun.

To spice things up a bit how about a little wager? If CM manages to release a unified kernel within the next three month merging at least four different kernel trees I will donate 100$ to a project of my choice on DonorsChoose.org - if CM fails to do so you will donate these 100$.

Deal? This is your chance to put your money where your mouth is. Show the people how much you believe in your CM team.


----------



## Droidlovinyogi

Ezekeel said:


> Ah come on. Don't be a sissy. It just started to be fun.
> 
> To spice things up a bit how about a little wager? If CM manages to release a unified kernel within the next three month merging at least four different kernel trees I will donate 100$ to a project of my choice on DonorsChoose.org - if CM fails to do so you will donate these 100$.
> 
> Deal? This is your chance to put your money where your mouth is. Show the people how much you believe in your CM team.


And the plot thickens!

Sent from my Galaxy Nexus using RootzWiki


----------



## blowtorch

ezekeel this thread sure makes you look like a jackass ... *observation*


----------



## jt1134

Ezekeel said:


> Ah come on. Don't be a sissy. It just started to be fun.
> 
> To spice things up a bit how about a little wager? If CM manages to release a unified kernel within the next three month merging at least four different kernel trees I will donate 100$ to a project of my choice on DonorsChoose.org - if CM fails to do so you will donate these 100$.
> 
> Deal? This is your chance to put your money where your mouth is. Show the people how much you believe in your CM team.


Momma always said, don't blow smoke when money is involved.

https://github.com/CyanogenMod/android_kernel_samsung_smdk4210/tree/ics/arch/arm/configs
https://github.com/CyanogenMod/android_kernel_samsung_p1/tree/android-samsung-2.6.35/arch/arm/configs
https://github.com/CyanogenMod/android_kernel_samsung_aries/tree/android-samsung-3.0-ics/arch/arm/configs
https://github.com/CyanogenMod/lge-kernel-msm7x27/tree/android-msm-2.6.35/arch/arm/configs
https://github.com/CyanogenMod/android_kernel_acer_t20-common/tree/2.6.39/arch/arm/configs
https://github.com/CyanogenMod/android_kernel_samsung_p4/tree/ics/arch/arm/configs

You said 4, I stopped counting at 6. There's probably more examples. Note the defconfigs marked as cyanogenmod_* for each individual device, except for p4 which is marked as pershoot_* for each device.

Have a good day, and try growing up a little while you're at it


----------



## Ezekeel

jt1134 said:


> Momma always said, don't blow smoke when money is involved.
> 
> https://github.com/CyanogenMod/android_kernel_samsung_smdk4210/tree/ics/arch/arm/configs
> https://github.com/CyanogenMod/android_kernel_samsung_p1/tree/android-samsung-2.6.35/arch/arm/configs
> https://github.com/CyanogenMod/android_kernel_samsung_aries/tree/android-samsung-3.0-ics/arch/arm/configs
> https://github.com/CyanogenMod/lge-kernel-msm7x27/tree/android-msm-2.6.35/arch/arm/configs
> https://github.com/CyanogenMod/android_kernel_acer_t20-common/tree/2.6.39/arch/arm/configs
> https://github.com/CyanogenMod/android_kernel_samsung_p4/tree/ics/arch/arm/configs
> 
> You said 4, I stopped counting at 6. There's probably more examples. Note the defconfigs marked as cyanogenmod_* for each individual device, except for p4 which is marked as pershoot_* for each device.
> 
> Have a good day, and try growing up a little while you're at it


And these are unified kernels that were merged by CM from previously separate kernel trees? Why does it say 'forked from teamhacksung'?


----------



## marleyinoc

CM is legion.


----------



## jt1134

Ezekeel said:


> And these are unified kernels that were merged by CM from previously separate kernel trees?


uh, yes


> Why does it say 'forked from teamhacksung'?


Because it was forked from teamhacksung's github. Work in progress or unstable/unusable development does not typically occur directly on cm's github. Frequently it's done using other repos, and later forked to cm when it's stable so that future submissions will go through gerrit review. Teamhacksung is made up of a few cm contributors that work on Samsung devices. The people that contributed to those changes, are members and direct contributors to cm as a whole, not some other group that cm just forked code from.

Not quite the response you expected, eh?


----------



## Ezekeel

jt1134 said:


> uh, yes
> 
> Because it was forked from teamhacksung's github. Work in progress or unstable/unusable development does not typically occur directly on cm's github. Frequently it's done using other repos, and later forked to cm when it's stable so that future submissions will go through gerrit review. Teamhacksung is made up of a few cm contributors that work on Samsung devices. The people that contributed to those changes, are members and direct contributors to cm as a whole, not some other group that cm just forked code from.
> 
> Not quite the response you expected, eh?


No. Actually I expected some more rhetoric.

Now that I am at home and had time to look through the teamhacksung gits in detail for more than an hour now I realize that teamhacksung in a large part actually is comprised of CM team members. Also I learned that pawitp and codeworkx are CM team members and both are very capable kernel devs that have released good work before that I know of (and also have used in my NS kernel). I guess with these guys CM actually has the right people on board that are not only capable but also willing to go through that painful mammoth task of merging different kernel trees. Kudos to that! I looked on some commits in detail and the work of these guys paints a completely different picture than everything I have seen from CM so far regarding kernel development.

You definitely have made a convincing case and with this new information the likely-hood of seeing one the reimplemented tweaks being integrated in a unified kernel seems actually realistic to me - instead of just some empty rhetoric to justify the things that went wrong which I suspected it to be.

I hope you can excuse my previous skepticism, but maybe you understand that after two month of fruitless discussion with CM I am cautious about every claim or promise (you know what they say: Fool me once...).


----------



## ArmanUV

jt1134 said:


> ezekeel this thread sure makes you look like a jackass ... *observation*


I think he's actually quite rational and respectful. Just look at the original discussion screenshots in OP. Also look at his last post: It takes courage to admit you were wrong.


----------



## Nrgaway

Post Deleted by User.


----------



## Ezekeel

Nrgaway said:


> This thread seems to be stupid to be started by a kernel dev. I have only read page one so far cause there seems to be so many kernel supporters.
> 
> I PERSONALLY feel that CM is the BEST out there so far. Are the kernel developers are too lazy to support both versions? If so, I want I want an app refurd from franco and ez.
> 
> I am in another industry and have to work with OVER 7 implementations of the same standard. Its just he way it is. Kernel devs need to understand there is more than just the Nexus.
> 
> EZ, I really respected you until ths post; hope you change your tune. I could have understood this if Franco did it (10,000 + downloads; getting rich now), but you????
> 
> Remember, ROM first; kernel next. CM9 seems to be most popular with AOKP.


Send me a PM with your name and other details and I send you a refund.


----------



## Nrgaway

Ezekeel said:


> Send me a PM with your name and other details and I send you a refund.


I apologise, I came on way too strong. I was just upset and should have waited to cool off.

No need for a refund; I have already got my money worth to date and always preferred your kernel over the others.

I wish you luck with the CM team in the future since it will be sad not to have the use of your kernel.


----------



## uproot

Nrgaway said:


> I wish you luck with the CM team in the future since it will be sad not to have the use of your kernel.


No reason GLaDOS won't continue working with cm (unless someone makes a gamebreaking change), Ezekeel and the other devs are just tired of ppl asking why cm color control doesn't work all the time.


----------



## ArmanUV

Interesting turn of events : http://review.cyanogenmod.com/#/c/16991/

If I remember correctly morfic was the the person who came up with vibration control for tuna. Didn't CM promise not to take kernel features from community?


----------



## yarly

ArmanUV said:


> Interesting turn of events : http://review.cyanog....com/#/c/16991/
> 
> If I remember correctly morfic was the the person who came up with vibration control for tuna. Didn't CM promise not to take kernel features from community?


Accept != submit

Anyone can submit to gerrit and that was only submitted today by whomever felt like submitting (they don't even have to be a part of the Cyanogen team). When something passes review and merged into github that looks questionable, then you can let everyone know.

Please don't stir up more flames in a thread that is finally dead. Instead of drama posting, go to the Gerrit and point it out.


----------



## ArmanUV

yarly said:


> Accept != submit
> 
> Anyone can submit to gerrit and that was only submitted today by whomever felt like submitting (they don't even have to be a part of the Cyanogen team). When something passes review and merged into github that looks questionable, then you can let everyone know.
> 
> Please don't stir up more flames in a thread that is finally dead. Instead of drama posting, go to the Gerrit and point it out.


Your argument is invalid because the guy who submitted this is Rafael (Kalim) who is a CM team member and the same guy who submitted colour control that started all this mess.


----------



## yarly

ArmanUV said:


> Your argument is invalid because the guy who submitted this is Rafael (Kalim) who is a CM team member and the same guy who submitted colour control that started all this mess.


No, it's not. If you have an issue with it, go post your problems with it on the Gerrit or I'm going to close the thread. No more drama here. If you want my support (and that of probably any other Mod that pays attention to the issues), you have to make an attempt to point it out to the CM team on their Gerrit and wait for a reply.

I don't care who's right or wrong in the issue when there is no attempt to try to remedy the situation outside of rootzwiki before complaining about it here. I know for a fact you know how to use Gerrit.

If they remove your comment or ignore it, then you can post about it here. Until you show me that you actually posted there about it as a comment and get a reply, your comments are the invalid ones. It's up to the community to police itself, which includes you (and in this case, especially you, since you pointed it out).

I say that because the CM team generally doesn't read anything here and the only way they're going to notice anything is if you bring it to their attention. It's about as useless as complaining about AT&T or Verizon when you post about it here.

EDIT: Oh, look, they already noticed, issue closed. Person that pointed it out happens to be jeagoss of the CM team that posted in this very thread.

Next time point it out to the CM team before you complain or your post will be removed for being one-sided flamebait.


----------



## ArmanUV

yarly said:


> No, it's not. If you have an issue with it, go post your problems with it on the Gerrit or I'm going to close the thread. No more drama here. If you want my support (and that of probably any other Mod that pays attention to the issues), you have to make an attempt to point it out to the CM team on their Gerrit and wait for a reply.
> 
> I don't care who's right or wrong in the issue when there is no attempt to try to remedy the situation outside of rootzwiki before complaining about it here. I know for a fact you know how to use Gerrit.
> 
> If they remove your comment or ignore it, then you can post about it here. Until you show me that you actually posted there about it as a comment and get a reply, your comments are the invalid ones. It's up to the community to police itself, which includes you (and in this case, especially you, since you pointed it out).
> 
> I say that because the CM team generally doesn't read anything here and the only way they're going to notice anything is if you bring it to their attention. It's about as useless as complaining about AT&T or Verizon when you post about it here.
> 
> EDIT: Oh, look, they already noticed, issue closed. Person that pointed it out happens to be jeagoss of the CM team that posted in this very thread.
> 
> Next time point it out to the CM team before you complain or your post will be removed for being one-sided flamebait.


Haha at first time I didn't notice you were a mod. You're right that I should have posted on gerrit first. I was pointing out that the "anyone can submit to gerrit" argument doesn't apply here because the submitter wasn't just anyone, he was a CM maintainer and the same person who started this situation in the first place.
This whole thing reflects badly on this person , not the CM team as a whole. I have nothing against CM (I actually use CM nightlies) and I understand their side of the argument (kernel unification and all that) as well as Ezekeel's side (user confusion, independent development, etc).


----------



## abbofro

CM have really took in to account what people have discussed to prevent further problems. Hats off to them.

Google Galaxy Nexus (GSM)
ROM: AXIOM HYBRYD B6
Kernel: GLaDOS 1.34


----------



## reference.phone

fragmentation - no more *CM vs Ezekeel* - now *CM vs Ezekeel vs morfic*

*Vibrator Control*

http://rootzwiki.com...733#entry700733

morfic still use /sys/vibe/pwmduty (not /sys/class/misc/vibratorcontrol/vibrator_strength)

*Contrast*

morfic use his own and the values not the same (not /sys/devices/platform/omapdss/manager0/gamma)

/sys/module/panel_s6e8aa0/parameters/contrast

*WiFi PM*

morfic use "Y" / "N" instead of "0" / "1"

There is no cooperation! There's not much community spirit around here. Every dev goes separate ways.


----------



## Ezekeel

reference.phone said:


> fragmentation - no more *CM vs Ezekeel* - now *CM vs Ezekeel vs morfic*
> 
> *Vibrator Control*
> 
> http://rootzwiki.com...733#entry700733
> 
> morfic still use /sys/vibe/pwmduty (not /sys/class/misc/vibratorcontrol/vibrator_strength)
> 
> *Contrast*
> 
> morfic use his own and the values not the same (not /sys/devices/platform/omapdss/manager0/gamma)
> 
> /sys/module/panel_s6e8aa0/parameters/contrast
> 
> *WiFi PM*
> 
> morfic use "Y" / "N" instead of "0" / "1"
> 
> There is no cooperation! There's not much community spirit around here. Every dev goes separate ways.


There is no Ezekeel vs Morfic. But I agree we have to cooperate better on this. I will talk to Morfic.


----------



## morfic

reference.phone said:


> fragmentation - no more *CM vs Ezekeel* - now *CM vs Ezekeel vs morfic*
> 
> *Vibrator Control*
> 
> http://rootzwiki.com...733#entry700733
> 
> morfic still use /sys/vibe/pwmduty (not /sys/class/misc/vibratorcontrol/vibrator_strength)
> 
> *Contrast*
> 
> morfic use his own and the values not the same (not /sys/devices/platform/omapdss/manager0/gamma)
> 
> /sys/module/panel_s6e8aa0/parameters/contrast
> 
> *WiFi PM*
> 
> morfic use "Y" / "N" instead of "0" / "1"
> 
> There is no cooperation! There's not much community spirit around here. Every dev goes separate ways.


What is your intend with this post?

About the interfaces:

Vibrator control: I'm waiting to hear back from CM, based on that i will use CM's or Eze's interface, no need to change now where things are not settled.

Contrast: so what? I am not using predefined gamma tables like the "Omap Gamma" patch. It's not the same, it's something i liked the outcome of. Once i hear back from CM i will make this a more robust active (instead of passive) implementation. Which might eliminate or augment Eze's gamma control. At which point I'll see what he thinks about that (I like to show something working, as Eze is the better coder, so a solution will make more impact (if any))

Wifi PM: I noticed Franco added checks to prevent user errors, since it is a bool toggle, i change int to bool, Franco picked up my change. So what's the problem?

Sorry we do not get things done in absolute unison, that there are delays between people in different timezones should be quite obvious.
From my side of the screen it doesn't look like you care about that though, from here it seems you are solely out to sensationalize this.

Sorry, that i am not changing things i already agreed to with Eze, it is worth more to me to create a working solid solution that works for a project as large as CM and still encourages individuals like Eze, Franco, Imoseyon, Ogdobber or me to contribute to CM in a fast and efficient manner.

So a few days here or there i couldn't care less about, if in the long run we could achieve something great that gets everyone back to working on useful stuff instead of this interface bickering.
Now stop wasting Eze's time, stop this A vs B vs C vs D, right now is not the time and you really get to him about this and you are not helping, it's disruptive and non constructive.
We know where we differ, at this point us differing hurts noone. Things are too much in flux today that a fix today could require another fix tomorrow.

Thanks for your cooperation on this, i am looking forward to not hearing from you until after talks with CM are over,

Daniel


----------



## morfic

Ezekeel said:


> There is no Ezekeel vs Morfic. But I agree we have to cooperate better on this. I will talk to Morfic.


It's your thread, right? close it.


----------



## yarly

reference.phone said:


> fragmentation - no more *CM vs Ezekeel* - now *CM vs Ezekeel vs morfic*
> 
> *Vibrator Control*
> 
> http://rootzwiki.com...733#entry700733
> 
> morfic still use /sys/vibe/pwmduty (not /sys/class/misc/vibratorcontrol/vibrator_strength)
> 
> *Contrast*
> 
> morfic use his own and the values not the same (not /sys/devices/platform/omapdss/manager0/gamma)
> 
> /sys/module/panel_s6e8aa0/parameters/contrast
> 
> *WiFi PM*
> 
> morfic use "Y" / "N" instead of "0" / "1"
> 
> There is no cooperation! There's not much community spirit around here. Every dev goes separate ways.


If you bothered to follow the CM gerrit, you would notice that Morfic (though it's not exactly obvious by the names) is one of the ones in the conversation already on the issue. As Morfic also said, please stay out of the issue. We don't really need every user finding this thread and using it as their soap box to stir up drama.

Unless anyone has any objections (if Ezekeel or Morfic have any objections to that, just PM me), I am going to close the thread. It's outlived its purpose.


----------

