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!

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. :wink:

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).

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... :cry:). 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).

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.

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

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.

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)

Uh... this bit is false, actually. :oops:

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.

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

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!

[quote="luv2chill"]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.

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. :wink:

:D
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!

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. ;)