I have decided to not use SqlObject [1]. What the project should possibly do:
* Create a new mailinglist (e.g. on Google Groups), thus the spam-problem is reduced. The new groups should of course still be available with the nntp interface (gmane). This step enables _communication_ around SQLObject. (SQLAlchemy has recently moved to google groups and I assume the would assist this project with this step). * The remaining developers should focus to provide an sqlobject API compatibility layer for SQLAlchemy. This way existent software can migrate without many effort. I am sure that some projects would provide support for this (SQLAlchemy itself, TurboGears). * The project should move away from sourceforge. Trac provides nice functionality for small to medium scale open source projects. * At a minimum, the project should inform potential users about the low activity on the SQLObject project. The project lead should of course support all this moves. - [1] http://case.lazaridis.com/wiki/SqlObjectAudit . ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ sqlobject-discuss mailing list sqlobject-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
