Database Info

How would you guys like a Bugtracker?

I'm currently working on a Bugtracker for the xda-developers (my own project - wasn't asked by anybody)
The idea behind it is to allow:
The Developers to see what bugs are outstanding
The user to submit their problems
The curious to see which ROM has less bugs
The n00bs to do research before asking questions (and have more places to spam)
I'm not planning to replace the forums, I just want to make an extra tool that can be used along side the forums - but is neater for bug reporting
Feel free to post your thoughts on if you like it (and so what should be included) or if you don't like it (and so what should replace it, if anything)
Thanks!

Hey, that's very nice.
But.. Are we talking about a new website? or just a new thread?

DaVince said:
Hey, that's very nice.
But.. Are we talking about a new website? or just a new thread?
Click to expand...
Click to collapse
Entirely new website.
It will be hosted on my http://www.vidmes.com webserver

i voted approving the bugtracker but i like the idea of all the information about universal development being centralized in one only location.
so, i think it would be interesting to keep it in this forum.

It's ok, we'll just have a sticky thread that has a link to TehPenguin's site.
I vote you go for it TehPenguin.

DaVince said:
It's ok, we'll just have a sticky thread that has a link to TehPenguin's site.
I vote you go for it TehPenguin.
Click to expand...
Click to collapse
Well, I've done some tentative work on it - and its looking good (if a little bare - I'm a software developer, not a web designer )
I'm a little busy this week, so its going to be about 2 weeks before I announce the link for the Beta
In the mean time, I'd like suggestions as to what people want in it
(Also, I notice one negative vote - I'd like to see their argument....)
Thanks!

Great Idea
I think mandatory information should be
1) Device Vendor...ie Imate, XDA etc
2) Radio stack in use
3) OS Rom in use
4) Third party software installed ( I know this list can be big, I myself have well over 100 apps as std) but is important for diagnosing bugs. Perhaps we could get an AppMgr listing from each system, not too hard to obtain.
You could also go overboard a little and have a PDA page, browseable from our Uni's so nothing graphics intensive or fancy. A simple login dialogue ( Can we port XDA-Dev user accounts?) once the user has logged in, they fill in a basic form with the bug description, click on submit and we could pull the information in points 1 to 4 above off of the device with a script.
Just my 50pence worth.
Great idea m8, hope it gets somewhere.............let me know if I can help with anything.
Cheers,
Beast

yes! would be really helpful for cooks

beast0898 said:
I think mandatory information should be
1) Device Vendor...ie Imate, XDA etc
2) Radio stack in use
3) OS Rom in use
4) Third party software installed ( I know this list can be big, I myself have well over 100 apps as std) but is important for diagnosing bugs. Perhaps we could get an AppMgr listing from each system, not too hard to obtain.
Click to expand...
Click to collapse
What I was planning to do with this is to have them describe a "Bug" in very generic terms as the Bug's description. Then they are required to add a comment (which other people may add) - this comment would have a "template" which would have things such as vendor, radio (I didn't actually think of this one), etc...
beast0898 said:
You could also go overboard a little and have a PDA page, browseable from our Uni's so nothing graphics intensive or fancy. A simple login dialogue ( Can we port XDA-Dev user accounts?) once the user has logged in, they fill in a basic form with the bug description, click on submit and we could pull the information in points 1 to 4 above off of the device with a script.
Click to expand...
Click to collapse
Some good ideas but....
I can't actually get info from the xda-developer's forums database - this may be a security risk on their behalf and would require far to much messing around to organise (as much as I would like to do it)
You will be able to view the page on your PDA's - its _very_ basic and I'll try to keep it xHTML complaint and do fanciness with CSS (though at the moment it does use some table hax)
Pulling info out of the PDA is virtually impossible (unless I build an app for the PDA's.... maybe later ) since the pda only tells me what browser version it is using
Either way - these are the things I like to see - Ideas!!!!
Keep them coming!

DaVince said:
It's ok, we'll just have a sticky thread that has a link to TehPenguin's site.
I vote you go for it TehPenguin.
Click to expand...
Click to collapse
I totally agree with DaVince, having a bug tracking website would be cool and having a link directly to the site via xda-developers is a good idea. Keeping everything centralised and available for use by everyone who uses xda-developers.
You have my vote! Would be a great tool...
gsmknight

TehPenguin said:
What I was planning to do with this is to have them describe a "Bug" in very generic terms as the Bug's description. Then they are required to add a comment (which other people may add) - this comment would have a "template" which would have things such as vendor, radio (I didn't actually think of this one), etc...
Some good ideas but....
I can't actually get info from the xda-developer's forums database - this may be a security risk on their behalf and would require far to much messing around to organise (as much as I would like to do it)
You will be able to view the page on your PDA's - its _very_ basic and I'll try to keep it xHTML complaint and do fanciness with CSS (though at the moment it does use some table hax)
Pulling info out of the PDA is virtually impossible (unless I build an app for the PDA's.... maybe later ) since the pda only tells me what browser version it is using
Either way - these are the things I like to see - Ideas!!!!
Keep them coming!
Click to expand...
Click to collapse
Hi TehPenguin,
Surely we can run a JScript or Vbs through the PPC Browser to get the required data from the Reg, only a couple of RegReads!
Just another thought............... I prefer accurate information, the reg is less likely to make mistakes than a user!! (No offence intended to anyone)
L8r,
Beast

Bugtracker
Hi,
Would be great to have this.
Looking forward
Leo

Why not use one of the many bugtrackers already out there? I prefer Flyspray (http://www.flyspray.org/) since it's as mighty as Mantis, but more Web 2.0 ... and you should be able to browse it on your PPC, although I don't think anybody really wants this ...
Cheers,
-mARKUS
P.S.: As for getting registry stuff through the PPC ... I doubt you can read out the registry by a JavaScript running on the page itself. Also there are many geeks out there who use Resco so they could easily export a .reg-file and attach it to the report.

mbirth said:
Why not use one of the many bugtrackers already out there? I prefer Flyspray (http://www.flyspray.org/) since it's as mighty as Mantis, but more Web 2.0 ... and you should be able to browse it on your PPC, although I don't think anybody really wants this ...
Cheers,
-mARKUS
Click to expand...
Click to collapse
I've had a look at at a number of bug reporting systems - the problem with them is that I'd have to end up customising it quite a bit anyway. For instance, they are typically designed for one program, possibly with options to support different parts\plug-ins for these programs. My design involves having multiple "Devices" each with multiple "ROMs", which may be deprecated, and each of these ROMs have multiple bugs - thats a couple more levels of complexity than the average bug tracker can handle.
Although they are more "Web 2.0" the Javasript\other fanciness would make it difficult to view on a PDA. Personally I prefer the old style Web 1.0 and a PHP back end
The other advantage of me making it is that you guys can have, almost, anything you want - and it should be done as soon as I have time, seeing as I know the code intimately.
And the point I really like - I love coding
mbirth said:
P.S.: As for getting registry stuff through the PPC ... I doubt you can read out the registry by a JavaScript running on the page itself. Also there are many geeks out there who use Resco so they could easily export a .reg-file and attach it to the report.
Click to expand...
Click to collapse
Exporting a reg file is the only possibility. Due to "security" problems, no script can actually see the registry of the device (or your PC for that matter), except what is in the "User Agent" key.
I'll put it on the "TODO" list to make a .NET program that automatically dumps your settings and creates a bug report
Given time, this can become quite beautiful. And time is now something that I will have - since I'm on holidays for the next few weeks!! (Yay for no more exams!!)

The alpha version is almost finished
I'll put a link up onto WM-Gurus for the final testing stage of the Alpha and see how it goes
Once the Alpha is complete (ie not too buggy) I'll put the link for the Beta here
Enjoy!

this is really a great idea.
i hope all goes well...
thanks to all!

Okay,
ALPHA VERSION IS NOW AVAILABLE!!!!
You can see it by going to: http://xdabugs.vidmes.com
Feel free to register or use the following users:
Username "test" password "testing" (Access level - registered user)
Username "dev" password "dev" (Access level - developer)
Username "admin" password "password" (Access level - administrator)
PLEASE NOTE: At the end of the Alpha stage, ALL DATA WILL BE CLEARED FROM THE DATABASE!
What I need people to do:
Look for bugs
Write the Help\FAQ sections
Ask me questions so I can write the Help\FAQ sections
See what else is needed
Enjoy!!

Is there any benefit to putting upgradeable files in a rom?

What I mean is, it seems to me that it would be more efficient to put any/all files that may be upgraded as packages and instead of flashing cooked roms, we could flash a generic rom and uninstall old/reinstall new packages
Am I making sense to anyone?

I understand you
I believe this is part of what chefs who create "lite" or "unbloated" or "clean" or "naked" (in Garmin's ROMs) are trying to achieve.
I personally like the idea, and hope we see more of them.
My personal favorite ROM of all time was the very first Hyperdragon III

mbarvian said:
I understand you
I believe this is part of what chefs who create "lite" or "unbloated" or "clean" or "naked" (in Garmin's ROMs) are trying to achieve.
I personally like the idea, and hope we see more of them.
My personal favorite ROM of all time was the very first Hyperdragon III
Click to expand...
Click to collapse
Up until recently the problem has been that cooks either created loaded ROMs with tons of stuff added to them, or lite ROMs, where they stripped this out.
The issue was however that it is quite easy to strip things out of a ROM. Making CAB packages out of those stripped out files however can be one of the more time consuming tasks and cooks didn't always offer those packages. In addition, CABs which were made available from other sources weren't always packaged in entirety and wouldn't always install.
Cooks have been getting better at this recently however. My new set of ROMS follows these concepts precisely:
http://forum.xda-developers.com/showthread.php?t=429117

I have been calling and advocating for this too basically since the dawn of UC
Previously I didn't post much under different nick, but I have "put up together" this concept in THIS thread finally, albeit with somewhat misleading "temporary" title, but it is good discussion if anyone is interested.
Granted, few apps have to be cooked-in in order to function properly, but those are really just very few. But as you can read there, most objections against this kind of "real lite" ROMs (where any "upgraedable apps" are NOT cooked-in) come from people who don't understand it, or don't know much about UC or Sashimi (BTW I'm for UC rather than Sashimi because UC is much easier for any newbies), or just don't know/have no clue how it works and are affraid it would make troubles to them if they don't have the same apps cooked-in.
Perhaps any of you could add your input there, since there isn't much sense in starting new thread about basically same thing.
Bengalih, I will test your ROMs with pleasure when I have bit m,ore time (or actually a second Kaiser would be great ).
But I can already give you my sincere congratulations now if you have created such ROMs
I have made ROM based on hang.tuah's ROMeOS (it was going to be an update, but ended in another ROM, LOL - not quite "lite" as I would want it, but I can't change the things that were "always there" now ). I try to steer its users into UC and use "extended packs" for things like dialers, comm managers etc. They'll have best proof that "cooked-in" is *worse* than "installed" soon, when they will have i.e. choice of Opal or Kaiser dialer in the extended pack - which obviously would be impossible if the dialer was cooked-in in the ROM...

@bengalih: your post is what got me to thinking about this again
I'm happy to see that you others share my attitude towards efficiency
I have not completely read thru both of your threads but I suppose what needs to be done is to create a universal standard
The way I see it, this type of system would be beneficial to cooks and end users alike. End users need a minimal variety of options to install these collections and a minimal variety of each basic rom release to install the collections to. Cooks need a simple system to adhere to that requires no more work to put together their collections than the current amount of work they do to create their roms.
Here is a sample proposal (what I'm thinking right now with a minimal knowledge of rom cooking )
A base rom of each flavor could be made available to download. By each flavor, I mean a different rom with each combination of files that must be cooked in to work. I haven't read anything like that before so if there are more than a couple combinations then no more than 4-5 with typcal combinations should be considered.
I need to do some reasearch to learn what benefits and/or caveats are associated with UC and Sashimi. I suppose cooks should be the ones to decide whether to make their collection(s) combatible one installer or the other.

selyb said:
@bengalih: your post is what got me to thinking about this again
Click to expand...
Click to collapse
In the future it might just be best to post in the thread about this then. As a topic that has been tread over several times putting additional input into an existing thread would be more effective.
selyb said:
I have not completely read thru both of your threads but I suppose what needs to be done is to create a universal standard
Click to expand...
Click to collapse
Perhaps you should read through the threads that are already out there before staring a new one that re-hashes the same information.
selyb said:
The way I see it, this type of system would be beneficial to cooks and end users alike. End users need a minimal variety of options to install these collections and a minimal variety of each basic rom release to install the collections to. Cooks need a simple system to adhere to that requires no more work to put together their collections than the current amount of work they do to create their roms.
Click to expand...
Click to collapse
Good luck trying to get cooks to follow anything you propose. Not that it might not be a brilliant idea, but cooks are going to do their own thing. I decided to take matters into my own hands and cook my own ROMs according to the principles I thought best. I put the ROMs and my principles out there in hopes others will adopt them, but that's the best you can do...
selyb said:
A base rom of each flavor could be made available to download. By each flavor, I mean a different rom with each combination of files that must be cooked in to work. I haven't read anything like that before so if there are more than a couple combinations then no more than 4-5 with typcal combinations should be considered.
Click to expand...
Click to collapse
Again, pretty much what I have done already with the HTC and AT&T official 6.1 releases. A base ROM for each with a set of CAB file to customize to your desires.
selyb said:
I need to do some reasearch to learn what benefits and/or caveats are associated with UC and Sashimi. I suppose cooks should be the ones to decide whether to make their collection(s) combatible one installer or the other.
Click to expand...
Click to collapse
No offense, because I realize I am coming off a bit gruff in this post, but you do need to do alot of research. I agree with alot of what you are saying, but it has been said before (by myself and others). Also, there is no reason that a collection of CAB files wouldn't work with SASHIMI instead of UC or vice-versa. To your own admission, you don't understand how these installers work, but when you do your research you'll see that in essence they are both just installing CAB and XML files (and with SASHIMI the capability for much more).
Again, please don't take anything here as a personal attack. I can see that you are coming off of inspiration from my posts and I don't disagree with your basic ideas. However you will get better reception from all if you do these things:
1) Research what is out there before posting so you don't retread old ground.
2) Don't just "propose" ideas, put them into action. Even the best ideas are unlikely to be adopted unless you put effort into implementing them youself.
I say these to you for your own protection before someone not as nice as me begins to bash you for not doing research

Ok, well, I will quit posting to this thread before someone not so nice does come along.

selyb said:
Ok, well, I will quit posting to this thread before someone not so nice does come along.
Click to expand...
Click to collapse
Heh... well seriously, take some time and learn more of what is currently out there and see where it is lacking.
I generally invite user feedback on my development projects. If you go back through the older threads, and take a look at what I am trying to do with my BRR ROMs, please feel free to comment in there about what additionally you would like to see and why.
Trust me, I very much welcome an open debate about what would be an effective way to do things. I just wanted to burst your bubble a little bit (seeing as you are a newer member) that your aspirations, although maybe valid, are most likely not going to get implemented by a majority of the cooks throughout the site.
I don't mean to shut down your thread, and you should continue posting if you see it as the best place to do so. I just feel that if you contribute to some existing projects that already have momentum then your ideas are more likely to get some attention.

InsertCoin ROM documentation project

Important: The docs are up. The live copy can be found on http://docs.insertcoin-roms.org/ and the Git repository on https://github.com/Manko10/InsertCoin-Docs/. For information on how to participate, see the wiki.
Hi,
This thread is related to the InsertCoin ROM by baadnewz (see this thread: http://forum.xda-developers.com/showthread.php?t=1198684). Since I haven't written 10 postings yet, I can't post to that thread nor create a new one in that forum.
InsertCoin has become a quite popular ROM for the HTC Sensation. It has had 200,000 downloads yet and numbers still raise. With increasing popularity it becomes more and more difficult to get hold of information you need concerning installation, problems, modification, tweaking etc. The result is a very high number of redundant questions on the forums and confused newcomers.
The project
Thus being said, it is time to create a good and centralized knowledgebase which helps new users to dive straight into using InsertCoin, keeps the development thread cleaner and helps to push the project forward since energy can be focused more on implementing new features and fixing bugs than on answering the same questions all over again.
baadnewz attempted to launch a Wiki once, but it ceased and shut down (as well as the whole baadnewz.eu server which was the last more or less valuable resource for help outside XDA-Developers.com).
Now my idea is to create a new official InsertCoin documentation project. I talked to baadnewz and he assured it would be promoted and integrated into the official website once it comes to life. The project I'm heading for is a community-driven one. I would work for it as much as I can but I can't do it alone. I'm not experienced enough in many (especially technical areas) of InsertCoin development and Android development in general. There are many things to learn about InsertCoin. And to be honest: I also don't have the time to write all the stuff by myself. Once I had written everything, it would already be outdated. So this project is only possible if other people participate actively.
How shall the documentation be implemented?
I thought of a project hosted on GitHub. Users can fork the project, make changes and send pull requests. For infrequent submissions, we could also provide a special submission form.
A staging server would then pull the HEAD revision regularly, format it and publish it as a website.
Sounds complicated? But it isn't. Git is pretty much straightforward and also users without technical knowledge can learn it very quickly (yes, there are great graphical tools for it). And of course, the documentation would also include a noob-proof guide to contribution.
But why Git? Why not a Wiki?
A Wiki might seem to be easier, but in fact a Wiki has to be updated regularly. Patches for bugs and security holes have to be applied. Additionally, we had to fight spam. Especially when we use some well known software such as MediaWiki, spam bots would love it. That can be a lot of work.
But the main reason is portability. A Wiki is a Wiki, nothing more. Exporting the contents into other formats would be a tedious process. However, when using plain text files with a simple markup language such as Markdown, they can be exported to all formats we like. Not only can the staging server parse it to HTML, but it can also be exported to PDF, CHM files (does anybody still use these?) and many more formats.
All right, but what is to be documented?
Well, a lot. Things I have though of are
Installation
Where to get InsertCoin ROM?
Which version?
How to flash InsertCoin?
How to upgrade from previous versions?
To wipe or not to wipe (and when)?
Kernels
Which Kernels are there?
Where to get them?
What are the differences?
Advantages/disadvantages of specific Kernels
How to install a new Kernel/revert to stock?
What is a Kernel and why can't I install it via the Market? (dumb question, yes, but important to know)
Known problems
Any reported bugs still present in version X?
How do I report my own bugs?
Why does feature Y not work (and never will)?
Features
Why to choose InsertCoin?
How to submit feature requests?
Requirements
What do I need to run InsertCoin?
Which baseband version do I need?
Where do I get a new baseband version and which one to choose?
Does it work on device X, too?
Which is the oldest supported version for custom kernels?
Add-ons
Which add-ons are there?
Where to get them?
How to flash them?
What to be aware of?
How to get rid of malfunctioning add-ons?
Customization
Which themes are there?
How do I install them?
How do I revert back to the default theme?
How to set up custom boot splash and boot animation?
FAQ
Things users ask all the time
Things users might ask regularly in the future
Milestones
Any planned features for future releases?
How many ROMs to release tomorrow?
Participation
How to submit patches?
How to improve the documentation?
How to pay a round for baad?
General information
What else could be valuable information?
How do I backup and restore my data most efficiently and least time consuming for upgrades which force a full wipe?
etc.
The list goes on. It's up to us how much it'll grow. Make suggestions please. Don't hesitate!
And now you come into play!
Do you think, such a project could become a success? Do you have suggestions, ideas, criticism? Post it here. Please.
Would you like to contribute? Post an answer. You would be one of the glorious pioneers.
If I get enough positive feedback and support by people who want to contribute I will start working on the base system, set up the Git repository, write the staging software and launch the project. If not, it would have been at least worth the effort. But you would contribute and give something back to the community, wouldn't you? Sure, indeed...! ;-)
Cheers
Manko10

Do you think, such a project could become a success? Do you have suggestions, ideas, criticism? Post it here. Please.
Would you like to contribute? Post an answer. You would be one of the glorious pioneers.
Click to expand...
Click to collapse
of course it'll succeed cause it'll be much easier with plain updated steps (n00b proof )
I would like to contribute if u may allow
THIS IS AWESOME

Of course you can contribute. Everyone is pretty much welcome to do that.

For Baad and InsertCoin itself, I think it would be a perfect success. I myself have been looking for a central resource database for InsertCoin, but always resort to just searching the thread, which is not exactly the most efficient method.
I don't know much on the technical ROM-based side of things, but I am a web developer, so I'm sure I'd be able to help in the deployment of such a website. I also happen to have a vBulletin license I'm not using. If Baad wants to expand his ideas even further and have a sort of official InsertCoin forum, all to himself, I could most definitely lend a hand for that.
I'm thinking large scale here; and upon writing this, further ideas have just popped into my head, but I'll save that for later, but hey, Baad is largely-awesome.
If you happen to have an MSN or Skype, Manko, I'd love to talk to you further

i have a better idea for talking / chatting in a more centralized way: IRC
#baadnwz-roms on freenode

I don't know much on the technical ROM-based side of things, but I am a web developer
Click to expand...
Click to collapse
So am I.
I'm quite sure, baad will help us as good as he can but he is of course very busy with the ROMS. So it's better to have many guys in the project who know more about the technical stuff.

I would try to help too, if You like. If You don't need IC pro's only

We need everyone (IC pros are needed, but not only).
First of all we need people who have fun writing and maintaining (!) good and understandable documentation.

Guys
if you do this - it will be bloody FANTASTIC!
noobproof guide needed badly

Make it so. Sounds like it could become a great resource.

It will, but only if enough people participate.

why not add chatbox on the coming site, isnt much better? 24/7 we can have conversation as like me, am from the philippines, and my time is different to others

Well, the documentation would also be there 24/7. I think for live talking we should better use IRC (#baadnwz-roms on irc.freenode.net). Embedded chats on websites consume a lot of bandwidth.

lol!, i guess so, yeah, maybe irc is much better. anyways, maybe i can contribute some design for future use.

Just jeep in mind that IC is also made by baadnewz for the Desire (and the wildfire too?). I'd like to write some things for the Desire version of IC.

koenvbeek said:
Just jeep in mind that IC is also made by baadnewz for the Desire (and the wildfire too?). I'd like to write some things for the Desire version of IC.
Click to expand...
Click to collapse
yes once the project starts, desire will be there too
for wf i made 2 roms long time ago, and then i sold the phone

Ill contribute if i can I love this rom

wow... this sounds freaking awsome. i would most definately help with coding once the repositories are set up ^_^

I think it would be really beneficial for everyone especially for the folks who are new to the ROM. 600+ pages of comments are a LOT to read through!

Make it so. (with Jean Luc Picard's Voice ) Nice idea.
Would like to contribute sth, though I have a really tight schedule lately...

Rom OP Format...DEVS READ PLEASE

Below is a format that should be used as an example of how a rom thread should look. It doesnt have to be exact. I suggest that you stay creative and use all the features in the advanced panel when creating a thread.
1. Name of rom, team, etc
2. Introduction
3. Changelog in code or php tags
4. What's included in the rom in the (apps, tweaks, scripts, addons, mods) in code of php tags
5. What works/what doesn't work in code or php tags
6. Credits (Users name-with link to (profile/github/or thread u got tweak from embedded), and what they did to help you)
7. Screenshots (2-10 different screenshots of different aspects of rom)
8. Kernel with either link to thread you got it from or github (if stock sense or cm please state that and that is enough)
9. Instructions on how to install the rom (also if special instruction for a2sd or beats audio...etc)
10. Do's and Don'ts of the rom
11. Questions & Answers section (I find this helpful to write out asked questions with solutions at the bottom of the op. I find that it cuts down on the question being asked a million times)
12. Finally the dl link
13. Additional add-ons (this can go into first post or reserved posts after)
I find the embedded link looks and feels better throughout the op if possible.
All sections should have a header with enlarged text and spaced out so people can read it easily.
I am hoping that this helps to make this section a little cleaner and easier. enjoy
The way I look at this is that it takes US weeks/days/hours to make these roms....we can take the time out to make sure that the op looks professional and clean
Also Make sure the op is fully ready before posting. I know we all get excited to release a rom but stating that half the stuff will be updated as time permits just shows that you are lazy and in a hurry which doesnt look good cause if thats the case then how does your rom run....
No posting a a rom thread without a DL link either

Thanks Papa Smurf151 i think everyone who is getting ready to post a rom should be redirected here!
sorry if im not allowed to post here, so please delete my comment if needed

i left this open for feedback

How about how stable it is like in the old days?
I remember last year everyone would label them as beta, RC, final etc.

bennyboy78 said:
How about how stable it is like in the old days?
I remember last year everyone would label them as beta, RC, final etc.
Click to expand...
Click to collapse
I think what Papa Smurf outlined in the OP is more then enough and it covers the basics while keeping the majority of the threads uniformed or at least try to
I also don't think we should start being over critical here and require individuals that start threads in the development section to add labels like Alpha, Beta, MC, RC or whatever.
I understand that having labels would make things a whole lot easier for the user BUT it also doesn't encourage the user to read about what he or she flashes onto their phone.
I don't know how many times I've seen a user complain and harass developers over something that was clearly their (the user) fault because they didn't read the OP. They saw fancy screenshots and saw the download link and either ended up bricking their phone or causing their phone to turn into a hot pocket...lol
Not trying to tell people how to do their job BUT I think we should encourage users to read/search more not shortcut things for users.

Mazda said:
I think what Papa Smurf outlined in the OP is more then enough and it covers the basics while keeping the majority of the threads uniformed or at least try to
I also don't think we should start being over critical here and require individuals that start threads in the development section to add labels like Alpha, Beta, MC, RC or whatever.
I understand that having labels would make things a whole lot easier for the user BUT it also doesn't encourage the user to read about what he or she flashes onto their phone.
I don't know how many times I've seen a user complain and harass developers over something that was clearly their (the user) fault because they didn't read the OP. They saw fancy screenshots and saw the download link and either ended up bricking their phone or causing their phone to turn into a hot pocket...lol
Not trying to tell people how to do their job BUT I think we should encourage users to read/search more not shortcut things for users.
Click to expand...
Click to collapse
Well said, couldn't agree any more.

MBQsniper said:
Well said, couldn't agree any more.
Click to expand...
Click to collapse
See I assumed this was common sense and ROMs that are missing a lot of these details, I don't give the time of day too so those ROMs don't matter to me. Because in my mind all the good ROM's out there already follow this in some way shape or form.
I appreciate what you did but I don't see why we need it is all.

As long as these are only guidelines and not enforceable rules, I agree with them. But I wouldn't agree with deleting/locking threads that fail to follow these guidelines; that would send the wrong message to developers.

v5HMeca said:
As long as these are only guidelines and not enforceable rules, I agree with them. But I wouldn't agree with deleting/locking threads that fail to follow these guidelines; that would send the wrong message to developers.
Click to expand...
Click to collapse
Rom threads will never be locked or deleted for not following these guidelines. I would hope devs would embrace them and if a fellow dev isn't then I would hope someone would point them here and try to help them. Most rom devs want to have a nice looking op. But some of them are new and don't know better or are very young and don't know better. This just helps to give structure that they can refer to and say oh yeah maybe I should have that or this.
XDA Moderator

Cherokee4Life said:
See I assumed this was common sense and ROMs that are missing a lot of these details, I don't give the time of day too so those ROMs don't matter to me. Because in my mind all the good ROM's out there already follow this in some way shape or form.
I appreciate what you did but I don't see why we need it is all.
Click to expand...
Click to collapse
What?

Custom ROM comparison database 2.0 (open to edit for public now!!!)

UPDATE: Database 3.0 can now be found here
Someone asked me to create a thread here for my custom ROM comparison database, so that's what I'm doing here now.
A few words from my side so you know what to expect of it and clear things up.
This is the original text I posted on my blog, so I'll just put it up here as well.
At the end of last week, I asked on G+ what to do next, an app comparison or a new custom ROM review. On of the first answers that got my attention was someone asking for a custom ROM comparison instead. I thought about it for a while how this could works since I can’t show them off side by side and it would be difficult no matter what. While thinking along I also remembered one post on YouTube where a viewer gave me the constructive criticism on the videos getting too long, especially the part where I listed all the features in the video review. I told him I am aware of that fact but I still haven’t found the right solution to make the videos shorter without missing any important specs. After some more thinking the idea of the comparison database was born.
The idea behind the database
Creating a database that contains all the available features clearly visible and quickly to access for everybody was actually the hopefully right solution. Using it I don’t need to waste anymore time on rattling down the whole list in my video… this saves me a whole lot of time but of course also you. And if someone wants to know if a specific feature is available in the reviewed ROM he can just quickly check the database and look for it, it’s as easy as that. Of course this method also allows me to focus more on the important aspects of the ROM itself.
Creating the database itself took quite some time for sure but in the end I think this is the cleaner and smarter solution for everyone. I hope this to get a helpful tool for everyone to easily find the right ROM for himself that suites him the most.
I did 2 videos, one quickly explaining the purpose of the database itself and an additional one explaining some of the more important custom ROM features so that people who are maybe new to custom ROM flashing know what to look for. If you see any feature in my database and wanna know what it is for or what it does, leave me a comment. I will then either quickly explain it if possible or collect some of the requests and make another “features explained” video.
Here is the link for the database (it will also be attached to every upcoming custom ROM video as well as the matching article), it will be updated with every upcoming custom ROM video review. I am no professional in text editing, so if someone is maybe bored or wants to help me out in making a better and more professional appearing database to improve it, please contact me, I’d really appreciate it.
Click to expand...
Click to collapse
Features of the database
--------------------------------------------------
- detailed list of all possible custom ROM feaures (~100 at the moment, constantly growing)
- containing 13 of the most popular ROMs + stock Android ROM + Xposed Framework to compare with each other (list is still growing)
- a lot of useful additional informations like links to downloads, ROM's websites, G+ communities and much more
- everything is sorted logically and color coded for fast and easy comparison
- all features have a quick explanation, expecially helpful for custom ROM beginners
- a lot of maintainers to keep it updated as good as possible (12 maintainers at the moment) - always looking for more, feel free to join
- constantly working on improving and enhancing the database
here is the link to the database 2.0 - thx to @parker09
some additional videos to explain the whole thing again...
Please feel free to leave any comments.
I'm a real Google docs noob so if someone maybe wants to help me clean it up and polish the style, just contact me.
And if this thread is posted in the wrong section, please just let me know.
UPDATE new host
Updates
Update
I read the posts here and on the portal and wanna set some things straight.
I do the database including the reviews in my free time, but besides that I´m also blogging,doing app/device reviews, how to´s and similar stuff so time for the database is therefore limited. That´s the reason I can´t progress with the database as fast as I would like to, also my way of testing takes up a lot of time.
I will of course try to do it as frequently as possible and of course ROMs like AOKP and Omni will follow in time.
That´s it for that.
Regarding mistakes and such, I know the database isn´t flawless but I´m not doing errors on purpose. About missing features of certain ROMs, it is possible some ROMs now have features that weren´t available at my time reviewing it but it´s almost impossible for me to keep track of all changes since I use different ROMs all the time and can´t always go back to already reviewed ones.
Update 2
Big change, after all what I read, I finally decided to make the database open to edit for public. Everyone can add ROMs and changes as he wishes to. I only ask users to be resposible and keep everything clean. Feel free to make new entries or correct errors if found. I think this is the best way for the database to grow.
The 2nd change is the move to another design made by @parker09 that is way nicer and better in my opinion.
The old one will still stay but won´t be updated anymore I think. So don´t forget to change your current link to the new one.
BIG THX to everyone in advance who decides to particate on working on the database, I hope the new way is a win for everyone.
Update 3
Sorry to say but the open to public idea wasn't the best it seems since the database somehow got messed up a bit. I want to prevent this from happening that's why I have some rules now to hopefully keep things clean and right this time.
Everyone is still welcome to participate in maintaining the database but has to do following now in order to get permissions to edit.
This reason for the rules is so I can better keep track of what gets changed by who and I know which parts are getting updated and which not.
How to get permission to edit?
Please contact me via PM on xda with the following title...
maintain custom ROM database "your email adress" "your google name" (the name that will appear when editing the document)
- Please also write down your name and email again within the pm just to be sure
- Please tell me which ROM(s) you would like to maintain or what you plan to edit.
- Please tell me if it is ok to add you to hangouts, this would make the teamwork faster and easier
Rules for maintainers
can now be found directly in the database
I want this so I have a list of all the maintainer and know who does what, so things don't get mixed up like 2 people editing one rom at the same time getting each other between in their way. This gives me a better overview so I can track the changes.
THANKS TO
-----------------------------------------------
n3ocort3x - AICP Team member
owain94 - PACman Team member
vedantgp - CyanFox Team member - Special thanks for a lot of groundwork&more
josegalre - Special thanks for a lot of groundwork&more
jrudyk
msn.debord
louisjms
lordbalmon
septigation
l3v14n

Thank your for publishing it here as well. This will be helpful for all of us. :good:

SlimBean has Breathing SMS. I should know I ported it (its in MMS settings)

cordell12 said:
SlimBean has Breathing SMS. I should know I ported it (its in MMS settings)
Click to expand...
Click to collapse
Maybe it didn't have it back when I reviewed it or I missed it. Will change it later. Thanks for the heads up

Can you add what you can do with stock+GravityBox? Then people can see which benefits they can get without flashing roms.

Hi nimrodity,
please make it available as a online tool for all ROM makers, so that they can update it as and when possible. and then there's no need you to update it.

Nice I did a column for Paranoid Android (as best I can - some features I don't know what they do) but did as best I could so if you want to copy & paste it.
https://docs.google.com/spreadsheet...VoZ1l0bWxoYnVzek9oNnhlWXc&usp=drive_web#gid=1
On the second sheet I started one ages ago and that's the style I went with, and you hover over for what their options are.

Interesting, but what I would really love to see is developers from cross-ROM platforms joining hands

Lastest Carbon have got Paranoid PIE.

Small adjustments
You had a really great idea by doing this. I once search for something similar to this spredsheet and didn't find anything useful...till now!!
You did a wonderful job!
I just noticed 1 small thing and my other point is a suggestion:
1. In CM10.2 you have an option for the vibration intensity only, so maybe you could add to the "vibration" section: yes, but limited.
2. My suggestion would be to add another "spec" for the ROM. It would be "screen color/gamma calibration". It's a very interesting feature and CM10.2 (latest nightly) has it.
What do you think?
Thanks
Keep up the good work!:good:

maxver0 said:
Lastest Carbon have got Paranoid PIE.
Click to expand...
Click to collapse
I know but it didn't back then when I reviewed it. I can't always update the database especially with the old review build date. It would be too hard to keep track of all.

Thanks for Your work... Hope You will add more ROMs to this database and I hope other members will help You to get the info You need for awesome ROMs like:
Purity...
crdroid
XenonHD
Liquid Smooth
Vanir
Carbon
Illusion
beanstalk
Jellybam
... and more AOSPs
... ... ... ... OMNI
Purity, Vanir, Jellybam and XenonHD should be simple to track because devs keep the same MODs&features... little changes on every new build
More difficult to track other ROMs that add&remove features very often
I can't help You because I'm a Stockish man and I won't try AOSPs for now
Thanks for useful database, It will sure help me when I will going to flash new rom

felix1234 said:
Can you add what you can do with stock+GravityBox? Then people can see which benefits they can get without flashing roms.
Click to expand...
Click to collapse
Doesn't really make sense since it's all about custom Roms but I already thought about doing a separate review for the blog.
Not sure about your idea, will think about it though

itechengine said:
Hi nimrodity,
please make it available as a online tool for all ROM makers, so that they can update it as and when possible. and then there's no need you to update it.
Click to expand...
Click to collapse
As you can see by my simple list I don't know much higher about docs and I have no clue how to do such a tool. The idea sounds really cool if someone knows how to do that and wants to help out just contact me

parker09 said:
Nice I did a column for Paranoid Android (as best I can - some features I don't know what they do) but did as best I could so if you want to copy & paste it.
https://docs.google.com/spreadsheet...VoZ1l0bWxoYnVzek9oNnhlWXc&usp=drive_web#gid=1
On the second sheet I started one ages ago and that's the style I went with, and you hover over for what their options are.
Click to expand...
Click to collapse
Will check it later. If you see my YouTube channel you see my PA rant. I don't really have that much interest updating the database with PA since I'm not really a big fan of the to work. Nothing personal but I just can't get warm with their Rom

@nimrodity
Great work. Important factors when choosing rom could besides features be "RAM usage on clean install and no tweaks/installed apps" and benchmarks based on the same conditions.
But anyways, awesome work :thumbup:

pemell said:
@nimrodity
Great work. Important factors when choosing rom could besides features be "RAM usage on clean install and no tweaks/installed apps" and benchmarks based on the same conditions.
But anyways, awesome work :thumbup:
Click to expand...
Click to collapse
Sorry I won't including benchmarks since they have nothing to say about performance in daily use. They are no important factor for me. Same for the rest, also I mention performance and such in my video reviews, don't plan on adding that stuff directly into the database though

On Cyanogenmod it says :
Volume Music Controls : music controls visible only but not with volume buttons.
You can control the music with the Volume buttons whilst being locked.
And if Poweroptions refer to the "menu" that shows when pressing the power button, you can en/disable airplane mode and select "Screenshot". And you can switch between Silent/Vibrate/Sound Profile.

Why no MIUI?
Great work! Just one little nag - why no mention of MIUI? It's distinct feature set should surely warrant a review, but that's just my opinion.

jwchips said:
Great work! Just one little nag - why no mention of MIUI? It's distinct feature set should surely warrant a review, but that's just my opinion.
Click to expand...
Click to collapse
My database is far from being complete, I just started . I chose my Roms randomly until now. Miui is still possible to come