Jan, I agree that the test process should have identified these issues, however I have been in Information Technology for nearly 30 years (Group Information Manager, Developer and other roles) and this tends to be quite common even from large commercial companies. Being in the industry a long time, I no longer find surprises exciting anymore, so I and very strict with my testing environment, I think it helps reduce the numerious grey hairs on my head :)

I have in the past made comments similar to yours, but I also that as a community we can all learn from our mistakes and help where we can to improve things.

Your idea to rename and recompile the old module is something that I have done from time to time when I have made significant changes while a particular module matures.

I would like to see DotNetNuke open up beta testing to the community, the current process to an exclusive group (sponsors and commercial module developers) has NOT proven to be very successful or does it build confidence in the DotNetNuke tested module program, it make me feel foolish when I recommend to my clients that they should look for modules that have been tested by DotNetNuke Corp.

DotNetNuke was originally founded on best practice, and eco system that made this open source project stand high above others, however there are now deviations that I certainly do not like (this is not the forum to discuss), recent comments from core members are certainly showing a negative shift in some of these founding practices and they don't seem to understand the impacts that are happening to the preceived value today of DotNetNuke.

Anyway, I am still strong supporter of  DotNetNuke and hope that things change for the better.

Cheers

Craig

Jan,

as the manager of the project release process, I would like to explain our goals and criteria: The module release process has been set up to

• make sure, provided tools like Gemini and source code repository are used correctly
• the module is packaged according to core team standards
• the module installs under certain situations, like OQ and non-dbo database owner, install and upgrade scenarios
• the module's general functions are executed correctly and various test cases are passed.
• the module works on sites with large user base (dotnetnuke.com staging) and high traffic (dogfooding)
• validate localizabiltiy
• ensure XHTML compliance
• last, but not least: review security

Basic intention of the release testing process is to validate, that the component does fit into the quality of the main product, it is bundled with. The testing team does not have resources to perform intensive testing and we are of the opinion, that this should be done by the teams prior to the release process. At the moment, we do not have a standardized process of beta testing within the project teams. There are activities to provide the teams with some tools, but IMHO we should leave some freedom on individual implementation by each team, i.e. for teams with individual testing sites, like Events, Forums, Gallery and other modules provide.

Regarding News, I did test the module myself with a couple of feeds and detected several problems, which have been ironed out by Peter before resubmission. I did not encounter massive performace issues, though I did not test multiple module instances on the same page and maybe not feeds from sites with low performance. I was aware, however, that there will be problems with some feeds and asked the team lead, to communicate this in public announcements for the new version.

Sabastian

Thanks for your input, it is always respected, I understand the load in relation of resourcing limitations, however as you can see in this forum there are at least three people who would\could help with pre-release testing. While I have worked around the issue and I have no urgency for this module, My overriding concern it that we (as a community) maintain the high standard of releases. As Jan has mentioned, it was only 5 minutes when we noticed some pretty significant issues, it is also tru that as consumers of these modules our expectations may differ from other test cases. From your description above, I don't believe that suitable test cases had been used from a usability point of view, yes the module probably worked as designed, however when compared to the usability or compatibility of the old module then it reduced compatibility. Therefore many found that this was a issue for it's usability.

From you bullet points above, there is no usability testing, I don't think this is right, whether it belongs at the project level or release level is not material, however because this particular module was replacing an already implemented module then feature changes, compatibility and usability should have been considered. I don't want to impact Peters good work here, and he may not have the resources available but surely we can all help with the shortfall?

Peters design approach was absolutly correct from a standards based design, however as I have mentioned previously, the world is a slack place when it comes to standards, this resulted in errors for users of the previous module that testing would have (in my view) identified an area that needed to be communicated to upgraders.

In our case DotNetNuke is not a revienue stream for us, however we do provide support and knowledge to the community and local installations as our contribution to the growth and awareness of DotNetNuke, therefore we can't contribute financially to the project, but we can assist the project where possible, DotNetNuke is our mechanisim of giving back to the community.

I would also point out that we should not single out Peters project here because this situation has ocured previously on other modules.

There are resources avaliable to you if desired and we certainly want the reputation of DotNetNuke maintained.

I am sorry if I come across hard or aggressive, but DotNetNuke has contributed high value to a number of areas, we are passionate about the project and DotNetNuke is worth defending.

Craig