PPCGeeks Group Project Proposal: The Traditional ROM Kitchen

[jamesus]

I think this is a wonderful idea and would love to help out in any capacity that I can.

And thank you to everyone who has helped in the development of the custom ROMs. And of course to you Helmi!!!

All of the various "fixes"is what is keeping me from releasing my own ROM, since I am not yet experienced enough to change all of the things that needed fixing from the base ROM. So right now I use what is available and what meets my needs the most!

[Sogarth]

Originally Posted by luv2chill

Some very nice sentiments in here (and long posts!) and a great vision for where we should go. But before we can get there the base kitchen needs to be fully functional. The basic bugs all need to be fixed first (some already are).

I agree with the sentiment that before we really unleash this, things ought to be more stable, but as things go, there's enough to work with that this other project could start. I expect that it will take a while for it to be in a form ready for public consumption, so this work could go on in parallel, rather than serially.

The other thing I would point out, though, is that for better or for worse, there are plenty of users who are downloading and installing all of these OS images that have those "basic bugs" you've pointed out, and I doubt they're going to stop anytime soon. Anything we would be pulling together from this route would arguably still be an improvement (in customization terms) over what they have now.

Originally Posted by luv2chill

1. Take the stock AKU 3.5 kitchen (I believe this was created by Imcokeman based on helmi's AKU 3.3 kitchen).

I wish it were stock. It's not quite (although I believe it's fairly close). Take, for example, this post here where one user tells another that some of the MSN apps have been taken out of the kitchen (which is true).

Originally Posted by luv2chill

2. Using the Wiki, compile a list of all bugs present in that kitchen. This gives a master list of the problems. For the ones that have been fixed already, provide a detailed description of the fix, cab or OEM of the fix, and credit where due). Unfixed bugs should have the names of people working on them (links to thread topics with discussion?). We don't move beyond this step until all of the known bugs are fixed or reasonably worked around (general consensus?).

Not a bad idea. I suppose if nobody else will, I could probably start up a wiki page (although it'd mean crawling through some of the really long threads I've already read... ). Things being what they are, I'd probably need help from some other people to list what all of the true HTC-based issues are (as versus some of the OEM-based issues like anything to do with MS VC).

Originally Posted by luv2chill

3. Once all of the known issues are fixed, an OEM package for each fix is created and sufficiently tested. Then it is moved into the kitchen, but still in the OEM folder (I strongly suggest the OS and LOC folders are not ever touched). This will become the final "vanilla" kitchen for this AKU, at which point it can be plugged into that cool web page idea, and be used as the basis for everybody and their mother's own custom ROM.

Mostly true. I would recommend that this would be the point where the majority of users would have an opportunity to really dig in and start mucking with the system. I would have to slightly disagree with the point about the OS and LOC folders, though, particularly since users may decide to perform certain actions which have effects on these folders. Take, for example, removing elements of the Pocket Office suite, the MSN integration, or even the default ringtones (in order to recover space to add alternative programs instead). Large pieces of those elements reside in the OS and LOC folders, so those (by definition) would need to be altered in order to achieve the desired results.

What would probably need to happen would be some form of very basic scripting system so that those developing for the system would be able to dictate what would need to happen for various pieces to be added (particularly those that affect multiple folders). Note that this wouldn't be necessary for anybody developing their own personal OEM package, and I would imagine that the majority of OEM packages wouldn't need to affect the existing folders, but there would be a handful that would need to perform special operations like this.

Originally Posted by luv2chill

As it has developed now, people are moving on to step 3 without step 2 having been completed (not that this paradigm even exists--I'm just making an observation), and that accounts for a lot of the confusion here. Whose custom ROM fixes which bugs? At this point in time we need to concentrate not on adding apps and making OEMs, but fixing all of the existing bugs! Once they are fixed, then we truly have a functional kitchen and can proceed with all the app OEMs and custom rom business.

QFT. Although everybody still wants to jump into the pool, so they want everything now. Oh, and stable, too.

Originally Posted by luv2chill

There's my two pennies anyway. We need to walk before we can run.

I suppose my comment on the whole thing is that although I agree with the gist of all this, I still think that we can start setting up the framework for the next step while we're still working on this step. That'll allow for the overall project to complete in a shorter time span, and if we keep pretty tight controls on it, we should be able to retain control and stability of the final product as well.

[schettj]

Not a bad idea. I suppose if nobody else will, I could probably start up a wiki page (although it'd mean crawling through some of the really long threads I've already read... Crying or Very sad). Things being what they are, I'd probably need help from some other people to list what all of the true HTC-based issues are (as versus some of the OEM-based issues like anything to do with MS VC).

Short list I know of
(1) smart dialing broken (not speed dialer!, freeware replacement app available)
(2) ## shortcuts not working in stock phone app (easy workaround with shortcuts)
(3) still no BT PAN - Connection Sharing works for USB though
(4) wmodem app still in kitchen, only works for USB and IRDA not BT DUN (normal, probably could remove it from kitchen and just use Internet Sharing)
(5) some problems with .NETCF1 and/or contacts OLE interface (and other apps, apparently? Breaks contacts in Windows Live Search)
(6) USB Serial Mode for ActiveSync broken (unchecking 'use advanced networking ' option in settings/connections/activesync errors)


That's the list in mine, anyway, based on the "stock" Helmi_C 3.5 + USB fixes off the ppcgeeks ftp.

Nice to haves (ie, not broken, just would be nice)
Crossbow theme by default (not even in kitchen)
Several missing but standard (at least to me) registry tweeks for performance
Speed dialer button not in default phone skin

For me, the only killer in the problem list (and no different then 3.3) is no BT PAN or DUN. The .NET issue is somewhat problematic, as it is looking more like an OLE issue and less like a .NET issue - I've cooked up one w/o any NET in it, installed .net1.0 manually, and tied live search - same error. The USB Serial Mode workaround not working is less of a problem if you apply a registry setting to fix RNDIS to use smaller packets (I posted that one in one of the other 3.5 threads)

[Sogarth]

Originally Posted by Sogarth

I wish it were stock. It's not quite (although I believe it's fairly close). Take, for example, this post here where one user tells another that some of the MSN apps have been taken out of the kitchen (which is true).

Uh... this bit is false, actually.

MSN is there, but I have noticed that some of the help files have disappeared. It looks like Helmi's Blue Angel AKU 3.5 ROM kitchen doesn't have those files, although his Himalaya AKU 3.5 ROM kitchen does (I wonder why the difference). I suppose we can yank whatever files we want/need from the Himalaya ROM, since it's also a QVGA Pocket PC.

[Glossman]

Hello All!

I just registered here with in the last few days, but I've been lurking for quite a while.

What I'd like to suggest is, a process for completing this project. I've read the posts above, and I think everyone has an idea of what needs to be done. What I propose is a quasi-SDLC where each build is developed, QA tested by the members, then released as a "production" version. Many of the general requirements have been defined above. Perhaps a specification can be specifically written for the basic vanilla ROM. The spec would outline all known defects, and those defects would be addressed by our "ROM guys". These fixes could be compiled into builds once, maybe even twice a week. These builds could then be released and QA'd by the members en masse. As issues are found, they are submitted by a defect report thread for that particular build. These defects would then be focused on and addressed, hopefully in time for the next build. After the initial set of requirements are met, we would have our version 1.0. A new set of requirements would then be created for the next "release".

I know this sounds very structured, but it allows everyone to focus their resources on a common goal. The key to this taking place in a reasonable time period would be to have some members creating the spec for the next "release" while our ROM developers are working on the current one.

I would be willing to help coordinate this process, as well as compile the specs provided by the members, catalog defects, and create release notes.

Just my 2.5 cents!

Mike

[luv2chill]

Originally Posted by Sogarth

Uh... this bit is false, actually.

MSN is there, but I have noticed that some of the help files have disappeared. It looks like Helmi's Blue Angel AKU 3.5 ROM kitchen doesn't have those files, although his Himalaya AKU 3.5 ROM kitchen does (I wonder why the difference). I suppose we can yank whatever files we want/need from the Himalaya ROM, since it's also a QVGA Pocket PC.

Great... it looks like you've been diffing various ROM dumps against our Kitchen v1.1. If you can make a list of the files that are missing in our kitchen then we can look at each of them to see if they are worth putting in (maybe we can also ask helmi to see if their omission was deliberate or accidental). Assuming we decide some or all of them should go into the kitchen we can make an OEM with them, or if people agree that they're better off in OS/LOC then I'll go on board with that (since they were files that were supposed to be there in the first place).

Glossman - If you have the knowhow to construct that kind of versioning system then I say go for it. I know it works very well for the various open source projects out there (and in a sense what we are working on is analogous to those).

SchettJ - Thanks for actually compiling the list... it looks pretty complete to me. Nice work!

[Glossman]

[quote="luv2chill"]

Originally Posted by Sogarth

Glossman - If you have the knowhow to construct that kind of versioning system then I say go for it. I know it works very well for the various open source projects out there (and in a sense what we are working on is analogous to those).

I'll put on my project management cap and see what I can do. If the principals agree that a process is needed, I'll start a thread with a process proposal so all interested parties can have input. After we've all agreed on a process, I can start a thread that will be the basis of the vanilla ROM 1.0 specification. Development can begin from there.

I'd love to get started, but I need buy-in from everyone that is going to work on it.

[Sogarth]

Originally Posted by Glossman

What I'd like to suggest is, a process for completing this project. I've read the posts above, and I think everyone has an idea of what needs to be done. What I propose is a quasi-SDLC where each build is developed, QA tested by the members, then released as a "production" version. Many of the general requirements have been defined above. Perhaps a specification can be specifically written for the basic vanilla ROM. The spec would outline all known defects, and those defects would be addressed by our "ROM guys". These fixes could be compiled into builds once, maybe even twice a week. These builds could then be released and QA'd by the members en masse. As issues are found, they are submitted by a defect report thread for that particular build. These defects would then be focused on and addressed, hopefully in time for the next build. After the initial set of requirements are met, we would have our version 1.0. A new set of requirements would then be created for the next "release".

I know this sounds very structured, but it allows everyone to focus their resources on a common goal. The key to this taking place in a reasonable time period would be to have some members creating the spec for the next "release" while our ROM developers are working on the current one.

I would be willing to help coordinate this process, as well as compile the specs provided by the members, catalog defects, and create release notes.

Wow... just... wow. I hope you don't mind me saying this, but almost from the moment I started reading this, I'd have to say that it just screamed "project manager." There's just... something about it.

[Glossman]

Originally Posted by Sogarth

Wow... just... wow. I hope you don't mind me saying this, but almost from the moment I started reading this, I'd have to say that it just screamed "project manager." There's just... something about it.

I knew you guys would figure me out. My current role is that of a release manager for a large company.

Anyway, my services are at your disposal. Just say the word, and I'll get started!

[luv2chill]

Word! Word! Word! Does that count as three votes?

Although I agree you should seek a consensus from the board (or at least the members who are actively involved in this effort), I would be very surprised if you don't see near unanimous support for your ideas. A fairly rigid structure to this system can only help us keep things straight, reduce duplication of work, and make it easier for everyone to see where we're at and where we're going at any given moment in time.

And I don't know how big of a job this is, but you should seek out volunteers you can delegate various tasks to if you would find it helpful. I'm sure there are users here who don't know so much about the ROM side of things but would like to contribute in other ways.

I really look forward to seeing what comes out of this. I'm glad we've got a few "natural born organizers" among us... because I'm someone who sees a ton of value in order, but just can never seem to get there. Judging from the discombobulated mess this forum has become, I gather I'm not the only one.