PPCGeeks Unified ROM Project: Task 1 (PROJECT TEAM ONLY)

Glossman · #1 (**permalink**) 02-24-2007, 11:15 AM

SINCE THIS IS AN OFFICIAL PROJECT "WORK" THREAD, PLEASE DO NOT RESPOND IF YOU ARE NOT A MEMBER OF THE UNIFIED ROM PROJECT TEAM. FEEL FREE TO START A NEW THREAD, OR PM ME IF YOU WANT TO COMMENT ON WORK DONE HERE.

Task 1 involves the selection of the base 3.5 ROM. During the planning phases, two ideas emerged for choosing a ROM: Selecting the "cleanest" ROM from all of those available, or starting with a brand new kitchen.

If an existing ROM is chosen, here is the likely process:

The team, led by the ROM Analysts, would begin looking at every existing 3.5 ROM. A list would be compiled of all known defects for each ROM. The best to way to this is to scour the boards, as well as discuss it with the author. Since many of the ROM authors are team members, it will be helpful if they "share their bugs" with the analysts. Once we have a good picture of all the ROMs in the wild, a choice can be made.

If we start with a brand new ROM, we'll still need to catalog the defects, but we would be in complete control of it's contents and can document every change along the way. This method will likely take longer than the other, but I believe it also ensures the best quality.

The choice is yours. Existing 3.5 ROM or brand new 3.5 ROM?

I will create Project Task 2 once a decision is made on how to proceed.

sfaure03 · #2 (**permalink**) 02-24-2007, 11:36 AM

as we,re doing 3.5 and its kitchen based, I say its a clean one.

custim roms are, or should be all done in oems the kitchens modularity gives us ease to take the best and most tested..

and, anyway, I have a decent environment to reverse out and diff roms anyway.. indeed that's how I attacked the issues I have up to now. and most o my personal roms tweaks are from tweaks I stole from the custom makers as well.

to me this s/b an easy one. imcokeman and I bboth worked hard to keepthe kitchen bare no tweaks.

the kitchen also enables us to keep work seperated and structured.

**schettj** · #3 (**permalink**) 02-24-2007, 11:50 AM

I think the helmi_c/ImCokeMan 1.1 (now 1.2?) is the cleanest base rom we've got - it's what every other 3.5 custom rom is based on, so any bugs in it are in them (unless fixed by those developers already, and if so those fixes should be easy to roll into the base)

But as you say, it's up to them. I'll identify the issues in any rom they tell me to look at

**luv2chill** · #4 (**permalink**) 02-24-2007, 01:38 PM

I say step even further back than 1.1. Let us start with the helmi 3.3 kitchen and completely re-create AKU 3.5, fully documenting every change made along the way. This way we have a complete "cookbook" (sorry) for how that kitchen was created, which folders are affected by which hacks/fixes, and a more standardized process for implementing said hacks/fixes.

For one (and I've said this before), I strongly suggest that nothing goes into/out of the OS and LOC folders unless it won't work as an OEM package. By doing this we make the changes much easier to manage for everyone and easier to keep track of (because they're in one place). If one of our fixes turns out to cause problems down the line it is easy to just remove that folder from OEM as opposed to having to hunt down individual files/modules inside OS or LOC and trying to replace them from an old kitchen. It just makes for a cleaner kitchen (sorry again).

There may very well be some fixes that must go in OS/LOC because they won't work properly in OEM or would take up much too much space otherwise. In those cases so long as we all agree that they're necessary for the base kitchen and are thoroughly tested they can go into OS/LOC.

Anyway those are just some thoughts. Call me an idealist (it's true), but even if it means a bit more work, I think we should truly start from the beginning and properly implement and document each and every change we make to get it to the proper 3.5 base kitchen. Then that info can go into the wiki for all to see.

**Maxx134** · #5 (**permalink**) 02-24-2007, 02:13 PM

When will be the deadline on this decision?
How much time do we have to voice our opinions?

Edit: had some spec info at home, but at work now that's why.

finster869 · #6 (**permalink**) 02-24-2007, 02:24 PM

I think that 1.2 kitchen rom that IMCOKEMAN and Sfaure03 just completed is pretty much as vanilla and close to stock as it gets (other than the .net2 folder being in the OEM). IMCOKEMAN can confirm, but if I recall, when he went from 3.3 to 3.5 he didn't do that much modification. I'd vote for using this one as the base, unless for some reason IMCOKEMAN or Sfauer03 feel a need to start totally over again.

**ImCoKeMaN** · #7 (**permalink**) 02-24-2007, 02:28 PM

Well, idealist or not luv2chill you do have a good point. I did try to document most of the changes i did, but it wouldn't hurt to start from scratch again. I started with the helmi BA aku 3.5 R0 (guaranteed no module conflicts) in the beginning and i think i could help guide someone to most of the steps required to get us back to where we are now using the helmi 3.3 apache OEMs and the fixes that have been added by everyone. I hope someone (an advanced developer/analyst etc. preferably) that didn't do this before could work through it and write the instructions from "tips" or a rough guideline and then revise the notes as needed. This really shouldn't set us back very far if i did my notes properly

although i can't walk through it to the point of flashing the rom myself at the moment. I have to at least wait til monday for the UTStarcom warranty support office to open before i even know if they'll look at it.

Finster,
I think the v1.2 should be the direction for the base essentially (hopefully fix a few more lurking issues though), but i agree with luv2chill that we should have a cookbook with step by steps to get the recipe right

Sogarth · #8 (**permalink**) 02-24-2007, 02:53 PM

I mostly agree with luv2chill, but with a slightly different perspective on some of the ideas here.

Quote:

Originally Posted by luv2chill

I say step even further back than 1.1. Let us start with the helmi 3.3 kitchen and completely re-create AKU 3.5, fully documenting every change made along the way. This way we have a complete "cookbook" (sorry) for how that kitchen was created, which folders are affected by which hacks/fixes, and a more standardized process for implementing said hacks/fixes.

Nothing to comment on here.... Starting with the only package that's completely verifiable as not having had undue modifications from the beginning would probably give us the cleanest start. Besides of which, all of the fixes have happened recently enough that we probably remember what changes we would need to duplicate.

Quote:

Originally Posted by luv2chill

For one (and I've said this before), I strongly suggest that nothing goes into/out of the OS and LOC folders unless it won't work as an OEM package. By doing this we make the changes much easier to manage for everyone and easier to keep track of (because they're in one place). If one of our fixes turns out to cause problems down the line it is easy to just remove that folder from OEM as opposed to having to hunt down individual files/modules inside OS or LOC and trying to replace them from an old kitchen. It just makes for a cleaner kitchen (sorry again).

There may very well be some fixes that must go in OS/LOC because they won't work properly in OEM or would take up much too much space otherwise. In those cases so long as we all agree that they're necessary for the base kitchen and are thoroughly tested they can go into OS/LOC.

This, I don't know if I would agree with in quite this way. I feel that any modifications we make to files in the OS/LOC directories should stay in the OS/LOC directories, since that's where they came from in the first place. Case in point: I would think that any of the changes we're making to the GAC_* .NET CF .dlls should stay in exactly the same directory. Outside of that, I don't think we need to worry about this problem until we hit the customization phase, and the majority of that will happen in OEM anyways. I'll leave aside those customizations that will need to alter OS/LOC for the moment....

Quote:

Originally Posted by luv2chill

Anyway those are just some thoughts. Call me an idealist (it's true), but even if it means a bit more work, I think we should truly start from the beginning and properly implement and document each and every change we make to get it to the proper 3.5 base kitchen. Then that info can go into the wiki for all to see.

Wiki? Bah, wiki.

Honestly? All changes should probably go through a source control system (yes, I'm bringing that up now). That would ensure that we would have a good history, file by file or change by change, and everything would end up being documented in a sense. It would give us the ability to know exactly what happened, who did it, and why.

**schettj** · #9 (**permalink**) 02-24-2007, 03:44 PM

Re Source Control

How about http://unfuddle.com/home - free, on the web, secure. Sounds like a winner.

Glossman · #10 (**permalink**) 02-24-2007, 04:10 PM

Quote:

Originally Posted by Maxx134

When will be the deadline on this decision?
How much time do we have to voice our opinions?

Edit: had some spec info at home, but at work now that's why.

We'll leave this open as long as there is debate. If you have something add that you won't be able to get to until tonight, it will still be open for you.