[Touch HD Windows Mobile ROM Development] the-equinoxe:
My rant (as a user)

I have been amazed with this whole soap opera, and wanted to reply to many threads, but decided that my response wasn't always the most political thing to say, so most of my comments haven't been posted at all (sometimes I simply closed the browser after writing a reply instead of actually sending the message).

firstly, I can't leave this remark unanswered:

As you may not have noticed: XDA-developers.com is a DEVELOPERS forum, it's not a helpdesk, or a place to get your "cewl romz"..

Because this is a forum by developers FOR developers, its only natural to have Cooks, Proggers, Graphic Artists, and Hackers(read ASM-wizards) etc etc as Mods or even as Admin.

To rant on:

Chefs have been the back-bone @ xda-developers since the early beginning, they where here earlier than kitchens, and before all those nice tools that make the todays cooking more like reheating microwave TV-diners.

Don't get fooled by the odd fast-food"cook" that only have been here for a few months and has to use a sock-puppet account to accuse other people. (you know who you are, so do I)

To proceed the rant, since I am on the subject of fast-food cooks:

Let me rant about the curse of the kitchens..

People like this (reheaters, or fast-food cooks) have no idea how to cook ROMs "old-school", without kitchen, without packages.

With manualy editing HV files and having to patch nb files with an hex editor to insert a splash (in hex), with only a few perl scripts (thanks maimach) to decode, and some rudimentary tools to upload them to a device (thanks Itsme). (and all the other real devs out there who spend countless hours analyzing the devices, reversing, making all those amazing and useful tools hardly anybode seems to know they are actually using them nowadays)

Cooking a ROM isn't just trowing a few packages, and some registry fixes in a kitchen and press build..

It's knowing why a ROM behaves in a certain way, and fixing unwanted behaviour.

It's knowing what happens when you cook a ROM, what the scripts in your kitchen are supposed to do, and what the are actually doing(!!).

It's knowing this and so much more..

I have seen ROMs released lately where the XIP wasn't rebased, where the rgu's were contradicting the hv files and worse: where RGU from package a was contradicting the RGU from package B. (and even worse: A contradicting B but both contradicting HV..).

Why not simply import the RGU's into the HV files first? and check the rgu files, or for fraks sake, merge them!

Some had added certificates, but the cook didn't knew that the base he was using was already patched to ignore all certificates.

Why on earth clutter the ROM with unnecessary certificates? Really WHY?

I have seen cooks adding XIP of a higher build but using the OS of a lower build, just to get a high build number. (some just plain hexedit the build number :s )

This simply makes me puke, why on earth would you add an UNMATCHING XIP in another OS? You would think that that unmatched part was the cause of some unexpected bugs, wouldn't you..

Or massive amounts of files that are moved from root (=\\windows) to some kind of subdirectory, it seems that the chefs who are doing this are unaware that they aren't MOVING but COPYING the files (jups, that was bad design from microsoft)

Why concentrate on the build number?

A higher build number doesn't make a better ROM.

Focus on making a ROM BETTER, fix those contradicting registry entries, there are plenty of tools out there to ease your work nowadays, it can be done in hours instead of weeks.

Rebase those files that are supposed to be XIP, don't leave it unaltered and most certainly don't make it a PE-file (like dll or EXE), you will have unpredictable occurrences of drivers unloading from memory when doing this, and other crazy bugs that are hard to pinpoint.

And if another chef removes those dsm files and replaces all RGU's with one (or just simply stay with the HV) ,it's mostly not to piss off other chefs so it can't be shared, but to make the ROM better and faster.

Etc etc etc etc.. (I could go on and on.. really ! The curse of the kitchens I called it)

This is not a Flame to a certain Chef, or even directed at this particular Forum, I have many devices, and I have flashed them a lot, sometimes I take the time to analyze a ROM, and I have been amazed what junk has been produced by some..

The main idea of a cooked ROM is to have a better device with fewer bugs, not a fancy picture, nor to have the highest number..

So in some cases the cure is worse than the problem..

I am not going to single out a bad cook, nor a good cook, there are plenty of both..

Some will see this as a personal attack, personally: I don't care, if you claim to be a Top-chef, but don't know the basics of cooking, call yourself what you want, but don't expect me (or others) to be fooled.

I am just saying: instead of focusing on a high build number, or a (bug ridden) beta, focus on what you are actually doing.

Take a stable ROM, and make that one better, most AKUs are intended to support newer devices, and newer hardware, a higher AKU doesn't mean the ROM is better (it could have new bugs to deal with).

Guys and galls keep doing what you like to do, keep developing, keep cooking, learn from others, but please, please stop this soap opera.

No one is perfect, lets keep working on making our devices perfect!

The tools are there, the knowledge has been shared, it just needs to be implemented.

Regards,

EqX