|
Just moving my comments from the other thread that was closed due to the immaturity of a certain person:
First of all this is coming from someone with no programming experience who thus far has contributed nothing and just taken advantage of the hard word of others... so take my friendly rant for what its worth. My vote is also to bring some organization to the kitchen approach. I think there is a critical mass of experts working on this stuff (not me) that we are at a point where some better organiation could accelerate development. (yes my lingo gives me away as one of those management consultants that tech folks hate because they dont understand technology -Im guilty!). The beauty (and danger) of the kitchen is that it gets a lot more of us involved in the experimentation and fun and hopefully helps the innovation. It makes us feel like we're developing! If nothing else even if boarder use of kitchens doesn't help develpoment I think it builds the enthusiast community... and I hope thats part of the reason we're all here. Forums like these are supposed to be sort of messy and confusing... thats part of their charm and what encourages people to learn on their own, so I guess the question is whether people are happy with the balance of solo effort vs cooperation vs confusion here... or do we want to shift the balance a little bit. I think its perfectly reasonable for the experts here to feel that they know what they're doing so everything is fine, and that any efforts to democratize these efforts will lead to the problems that XDA-developers is dealing with.
I've been playing with ImCokeman and Sfaures versions of helmi's 3.5 and its been frustrating but fun. In an ideal world here are some thoughts on organization. I'm not really adding anything new here just repeating a lot of what others have said and what many are already attempting to do:
1. Starting with helmi's 3.5 kitchen, document all that was done to get the basic OS working working. Here's I'm talking just about USB fix, bluetooth, vision connection...etc. I'm assuming Coke and the rest baked all these basic fixes into OS and didn't create OEMs. Here's there can be some debate as to what is considered basic and core to a vanilla ROM (ie. is Crossbow theme, netcf2, smartdialer...etc). Freeze such a vanilla kitchen version as a 1.0 (perhaps by carrier) and release for all to play with.
2. We all devote our energy to testing and developing OEM's. This is the hardest part. I think there are some good instructions out there for developing OEMs. I think they are still a bit confusing but I'm realizing that this is all more of an art than rote following of instructions and that there are probably only a handful of you guys out there who truly know how to do this well. The rest of us can try building OEMs and more importantly test. Regading the current OEM's on the ftp, I've used a lot of them sucecssfully, and others I think still have bugs. I think the FTP needs two folders for OEMs, one for those just created and being tested, and another for those that have graduated.
3. How do we decide when something is good enough to get to the second folder? I don't know. Perhaps we vote... but this would require some more thought on how to structure information exchange on this forum. Ie. when someone develops a new OEM perhaps it gets it own thread. People discuss for a period just in that thread and at some point the Original developer starts a poll to assess whether its ready.
4. All registry performance tweaks can be done in an OEM package (like Coke has been doing), via a well organized and documented .rgu file. That way someone can easily add to it or take out ones they dont want.
Perhaps in this same "registry tweak" OEM, or in a seperate one, someone can start an .rgu which compiles registry setting that customize personal settings after a hard reset, ie. fill in Owner name, device name,
turn today screen items on/off...etc. I've started doing this based on the registry hack thread and looking at others .rgu files but at this point I am so clueless that is mostly trial and error.
5. Revisions of baseic vanilla OS. Now this might be the hardest to manage. We all know that the OEM approach can wrongly simplify the nature of bugs we are dealing with because it assumes the basic kitchen is perfect, and that bugs can be isolated to specific OEMs. Obviously this isn't true (e.g. Windows live search contacts issue). We should try to do as many bug fixes through OEM's but if at some point there is a consensus that there are just too many basic OS fixes need, we can have a new vanilla rom kitchen release. I would suggest that this decision should reside with the handful of experts whose technical prowess we trust (we can all name them easily... colonel, sard, coke, sfaure, vboyz, schettj...i'm missing many).
As an aside... this assumes that the experts think the kitchen approach is superior. I would be the last one to suggest to colonel and sard that they abandon their great efforts using the other method. Their releases are great and I know in their threads they've made the valid point that even if people don't like every app they've included in theirROM, it doesn't haven any memory impact if someone decides not to use it and install their own apps over the ROM. I guess some of us would ideally like to put our own apps in the ROM to get those memory savings. Again, I don't feel any of us are entitled to this, it would just be nice. Again, I really appreciate everyone's hard work. I think the experts in this forum are some of the most patient and encouraging I've seen, and I hope you keep that up and dont let us dimwits get to you with our incessant demands. Yes, we are taking advantage of your efforts, but it is appreciated. If all this wasn't in a legal grey area I would be happy to put my money where my mouth is and pay to subscribe to such a forum.
-j
|