nyl auster [nylauster]

I found time to work on it tonight. Hope this will make your review easiest :-)
Please use this file instead of the one above if you didn't start yet your review.

You can use features module http://drupal.org/project/features to export all your configuration in modules rather than keep it in database. It makes staging easier.
featuresreport is a module that helps you manage staging using features. It's a module for developpers, which can be desinstalled on production sites.

User case :

You have two features on your site, exporting several views. Then you, or another person working on the site, add a new views on your drupal site by the UI. So, this this view is stocked in database and not yet exported in a feature : you can easily forget to export it !

featuresreport allows you :

1) Check which elements from exportables components (views, context, cck fields, imagecache presets, variables from variables table, permissions etc...) are not yet exported in a feature or in code

2) Just add those missings elements by copy/past drush output in the .info file of a feature (and then run drush features-update), rather than re-downloading the whole feature from the admin.

We can see elements than could be exported with drush or via a new link in features' admin.

There is no other modules providing this functionnality for now.

I corrected little mistakes tonight so i reupload the module one more time , to make the review as easy as possible :-)

well, thanks for taking time to take a look at this module.
featuresreport could be a very good friend when working with features module, but i need some feedback and testing on it, that's why i would like to put it on drupal.org :-)

I feel i can't go further in this project without sharing it and, i hope, find people who can extends / improve it, simply by adding / improving hooks in "elements_in_database.inc" file.

Thanks for your submission. Your module demonstrates, by the abundance of code comments and by the cleanness of the code style, a true willingness to produce readable code that others can contribute to. That's mainly what we are looking for during the review process. I'll go ahead and validate your CVS account.

This said, about the featuresreport module itself, I would strongly recommend not submitting it as a project on Drupal.org, but as a Feature request of the Features module. Two issues probably need to be fixed beforehand:

• The new hook_elements_in_database() feels completely unnecessary. Features already has a component introspection facility (hook_features_export_options()), which is not necessary to duplicate.
• There are some smallish code style issues (trailing spaces, missing dots at the end of comments, some text in French (:p), ...).

You mean : juste create an issue in the Features project and attach my module to show what is done for now ?
I agree that this shoud not be a separate project, but i'm a big noob as a drupal contributor, so don't really know which is the best way to work on this "featuresreport" feature for Features module.

Yes, exactly. Open an issue in the issue queue of the Features project, and start discussing with the maintainers of the project how to best integrate this useful "report" feature.