i21aneka [i21aneka]

This may take some getting through but lets start with the obvious.

1. Why is trips_datamodel_arc.php unconditionally included on every page load? trips_menu() can define a file to load as part of the menu structure.
2. The ARC2 library really shouldn't be part of the module. Your module's README.txt (missing) should include instructions on how to obtain and install it. Additionally, your module should check the library is installed before trying to use it.

to point 1, please read the Drupal documentation, I'm not hear to teach, just review.

to point 2, are you going to take responsibility for security releases of the library you use? It may be convenient for end users but it's the preferred method for end users to manage their own libraries and not host them in Drupal's CVS repos. It's there for Drupal code, not third party libraries.

Halted at applicants request.

These applications are available for anyone to review now. I don't know how you can claim that this is cencorship. If your module relies on an external library, we usually do not want it included in the module. For example, see the RDF module which requires people to download the ARC2 library.

@cvs reviewers:
I'd like to open this cvs application back up in light of the recent 'anyone can review a cvs application' policy change. Even though the applicant asked to have his application halted, he still made the effort before getting stymied, so I would appeal to AjK to review with greater relaxation and to all cvs-reviewers to give him another chance. Hopefully, we can spread some good will within this small part of the Drupal community.

For my review: The module makes proper use of Drupal's APIs for forms, system settings, and error messages. The code is very readable, even though most of the code is in .php files, which is uncommon, AFAIK. On the other hand, that may make sense because it is geared more toward external API integration than a normal module that heavily leverages existing functionalities. The author demonstrates ingenuity and originality, hands down, as well as a familiarity with Drupal. One oddity with the module is that requires the user to setup a separate database, which is understandable because it is separately managing relational models and is in an early stage of development.

In the future, I would like to see tighter integration of relational data handling within Drupal and collaboration with other contrib modules like SPARQL and SPARQL Views modules, since there appears to be a lot of effort on SPARQL support in your module. Some of your code might be better factored out into separate modules, like a common RDQL module since the RDF module uses that too. In this way, your efforts on this can contribute to other efforts in the community, but you'll have to stick around to pick up on those. :)

So long as i21aneka can post an updated version of his module without the non-GPL code, then he's ready to go IMHO and as best as I can tell from Drupal CVS Usage Policy. Libaries API may be an appropriate API for that. After he posts his project, issues for improvements in coding standards should be added and hopefully he would make them before creating a >=beta release (see also: #539616-16: CVS review process, what applicants expect of CVS admins).

@i21aneka:
The benefits to contributing on d.o are great and many in the Drupal community would be grateful for your contributions, so I hope you are still open to to it. Personally, I am interested in the future of metamodels and schema storage in Drupal. I also like that you're working on relational data visualization within Drupal, so I'll try follow your future contributions. Out of curiosity, do you have any plans on leveraging some of the latest and ongoing work in RDF to improve Drupal's schema storage? Here are a few links of community efforts you may be interested in:

Drupal RDF Schema proposal
Neologism, easy RDFS vocabulary publishing
Neologism (implements RDQL as well)
#809810: Support the Drizzle database engine
#566548: Add storage engine support to schema API.
#301038: Add a cross-compatible database schema introspection API
#566548: Add storage engine support to schema API.
Abitrary n-ary relationships Good conversation on how to improve nodereference's relational capabilities.
If you haven't seen how to use Nodereference + Views relationships, here's a great demo: http://blip.tv/file/1593750

Also, here's the info you requested:

But please give my the email of the person who is responsible for the reviewing guidelines.

Only Contributions repository managers who are part of the Infrastructure team can approve an application, however anyone can post a review based on the review guidelines. The guidelines are openly avaialbe for evaluation in #539616: CVS review process, what applicants expect of CVS admins.

I think the drupal approach is more censorship then open source.... I wonder whether should think about your reviewing guidelines for different categories of modules.

Many people are working hard on this with many improvements in mind, yours included. The categories issue won't make much of a difference once we implement http://drupal.org/community-initiatives/git >> Phase 3: Moving to a decentralized workflow. In the meantime, this review process is still the barrier that new contributors face. On the brightside, as with every system/process in Drupal, this one on the up-and-up!

The OP decided not to continue with this application, so I am closing it.