[HTC Pico (Explorer)] thewisenerd:
I'm sorry, but I meant no offense. Hope you took that in a sportive spirit.

Here, I'd like to highlight some points on why I said what I said.

"Betterbatterystats doenst help in anything."

Of course it doesn't. As mirhl said: "If you have high battery drain use betterbattetystats to take accurate information. Nothing says it couldn't be just a problem of yours". The OP doesn't really know whether the wakelock that's being held; is caused by either the kernel, or the ROM, or because of G-Apps, or because of some other app that the user installed.

" Its better to use rom toolbox pro and unnistall some system apps."

Again, this amounts to nothing. Randomly uninstalling system apps is not a very recommended practice. You'd need to be sure of what you are un-installing. If this is an indicator to the "slimming of ROMs" concept, then, I'd not be with your idea on that one. As galaxyfreak sometime said: "even if I slimmer the ROMs, people will complain "where's this, where's that""(sic). And, as a ROM builder myself, I know that it is hard to kick out features; that is like: taking a freshly packed package of cheese, messily cut off parts of it at random places, repackage it, and try to sell it. Frankly speaking, I've done it, and won't do it before. Know, that ROM builders aren't porters, and don't necessarily have to be good with the "repackaging", unlike the latter.

"galaxyfreak should have fixed the camera and browser only on the rc2"

mostly, this; depends on people's mindset. the camera fix was fairly simple (though I would not like to stress on the complexity of the patch which is 'simply' applied), and the browser fix was only a two commit revert. The question of what you asked: galaxyfreak should've fixed the camera and browser only on the RC2. But then, that isn't real "development".

"but instead it fixed bunch of other stuff that didnt need fix and created other issues."

looking at this again, from different perspectives; fixing a bunch of other stuff that didn't need fixing.

"Updated QDSP5 driver": and along with it the usage of new audio libs; which I'm guessing will support hardware playback audio, much more efficiently, than just effectively. If that isn't "development", or what?

"Updated libhtc_acoustic library": this plays a hell of an important role, and IMO, could be the 'primary' fix for the robotic voice call bug. Though the bug itself maybe caused by a variety of other factors, I remember that calling this library (in the libaudio used with OmniROM) was what fixed the robotic voice call bug in OmniROM.

"Various updates to framebuffer": some of which potentially increased the stability of the framebuffer, and also, not to mention; disabling hardware vsync BECAUSE the users "would" complain about slow waketimes (as they will NOT understand that it takes considerable time for a 600MHz CPU and a 220MHz GPU to sync 3 framebuffers)

talking of the framebuffer updates, etc, I would think of them, as an essential step. How many of the users would really care about how many patches it takes for a ROM to be "built", in the first place? Thanks to the guys at TeamHackLG, and some of the guys from LegacyXperia, a considerable number of commits were merged with the 'official' cyanogenmod sources, which means that the developers now have a lesser headache, since the number of patches reduce.

This reminds me of the times when UMS support was highly debated. I remember Andrew Dodd saying (in the OmniROM gerrit):

"I question whether we want to keep spending time on UMS or just kill it with fire at this point.

It's been deprecated for years and requires a lot of effort to keep it alive."

So, should the developers be moving forward, or put in a lot of effort to keep 'zombie's?

Developers are the 'smart'er group of people, so; they'd rather get stuff working, than carry around dead weight.

So, what I'm trying to say is: there is no development that is useful, or non-useful. Only thing that matters is, if it is efficient enough.

"And what it made it even worst was the useless awesom3 recovery support without giving an alternative non awesom3."

I can't comment much on this, as me trying to defend my works would surely be a biased view (in public opinion) regardless of what. Still, awesom3 was 'created' to re-create the custom mtd_parts functionality that many devices like HTC G1, MT3G, Hero, Evo4G, Desire, some of the LegacyXperia devices, etc. This was intentionally made (for this device), to provide full functionality (of the ROM) for the users, considering they had (mostly) been using memory increasing scripts by default, and had an sd-ext partition (in general).

"Most users that have rooted this phone, still have the yannou recovery, they will only need to flash the twrp to create 1gb ext4, 0 swap partition, and then going back to yannou."

what can the developers do, if they do not want to move beyond yannou, but want to flash kitkat? may I remind you that you do need an updated recovery for the update-binaries of later ROMs, so, most probably your ROM won't be flashed on older recoveries, even on TWRP 2.4.x.x should I say.

"Because booting the phone to recovery when turned off while charging is not a normal behavior."

no, it is not? let me make some things clear. offmode charging, as you know of it, is simply a program, that takes over the entire screen, when it is turned off, and if the charger is connected, it reads from a few files, and shows the images on your screen. this is the same process that goes on with yannou's and derivatives (how I know? I've studied them). As these programs are being called at init, they take over the functionality of the framebuffer, displaying the charging images, and leave you nothing but one choice: long press the power button, and parse the event as a reboot (a normal reboot). The same is the case with Sense ROMs too. When you turn them off, they aren't really turned off. How do you think Sense ROMs boot up so fast, that only the bootanimation, sound is played once, and the phone boots? The phone is put in a sort-of hibernation state, while the phone still remains fully functional (how else do you think the alarms ring?). So, the phone isn't really turned off in all these cases. only, their functionality restricted.

OFC, no one expects a normal user to know about all this, and not that they care anyways. Just saying that this shows the mindset of the users. Something doesn't go the way they have usually experienced, they think something is wrong; and 'abandon' it. This xkcd says I'm right (to an extent).

" Thus the high chance of getting nand recovery burned with twrp."

"Holy cow... You can't burn nand if it's not even mounted by default !! ://"

actually, I don't think that's what he's talking about. when the drivers/mtd is loaded, and yaffs2 drivers load, reading from the NAND device, they try to read most of the disk and quickly allocate the 'bad' sectors. the start of partitions have 'magic' bytes, so, they are recognized as 'bad' sectors, and thus it gives the impression that NAND is burnt, when it actually isn't. This is fully recoverable, with a flash_erase (which is included in superwipe_v0.5)

"Then, you should realize that we reached the point where even removing useless app... I couldn't still get to install slimmed gapps without running out of space. "

True this. Gapps is another highly debatable topic, and as far as the end user is concerned, Gapps is always a necessity, than an option.

"Am I happy for this? No, since I have a damn slow class ½ sdcard, and I would have really loved if a transparent-compression capable file system had got its way in, so that at least I could sync my contacts with google and make some calls (and pretty much nothing else) without slowdowns due to crappy I/O"

This is the exact reason why galaxyfreak and I have had differences in opinion about. While galaxyfreak feels that 120 mB is "enough" for the user to 'be', I on the contrary, am against it, as even 150 mB has never been enough for me, from the 'user' point of view. I think it is this tiny little difference that is causing that "there are so many awesom3 recoveries to choose from", for which my response would be: "your dilemma has been solved." I will henceforth, use the 120 mB /data, 10 mB /cache, and the rest for /system partitioning format, should that please all the users. And yes, good things are never easy. If both parties are benefitted, why the conflict?

finally, some harsh truths.

"If you go read others theads, you'll see many users complaining on how to flash a recovery. "

its the users who need to change their mindsets on what's difficult and what's not. If they thought that flashing a recovery was dagerous, they should've probably stuck with a locked bootloader. If they aren't willing to experiment by themselves and learn, it's their problem, NOT ours.

"And even I have once burned recovery partition while using twrp"

what I said above, if you have read, would answer your question.

"also if I have some issue with the rom or sdcard, I need to flash the yannou or other cwm recovery so the computer can recognize the storage Well but that only happens with the latest 2.8.0.0."

I pretty much think that that's an error with the operating system/drivers that you are using. twrp 2.8.0.0. has mtp working flawlessly, even on ubuntu (the surprise) (thanks to Sachin Thomas for the updated mtp configs). so, this point is invalid. Also, I don't think someone flashes an older recovery to simply connect their phones to their PCs.

"Still,

developers

needs come first. Then, light years ahead there are ours"

you will find that you stand corrected. there is a group which says: "without the users, the developers are nothing"; while there's another saying: "without the developers, the users are nothing". I feel that it's a subtle equilibrium between the two keeps forums like these going, with the testers as peace-keepers in between, where there's a win-win situation for both the developers, and the users. if you stand to be a user, you don't expect anything. just in case, take a timeout, read this, decide for yourself who you want to be: a mere user, or a tester?