Обсуждение: Request for assistance/advice: TikiWiki CMS/Groupware will have to drop PostgreSQL support soon unless a maintainer steps up
Hello to the PostgreSQL community! I asked someone in the PostgreSQL community and he wrote: "There have been past conversations on the advocacy's mailing list discussing the lack of implementation of web based front-ends using PostgreSQL. You could post a request for help on the advocacy mail list." This is a request for assistance/advice. Please point me to the right people/place if this is the wrong place. I am a project admin for TikiWiki CMS/Groupware. "TikiWiki CMS/Groupware is a full-featured, web-based, multilingual, tightly integrated, all-in-one Wiki+CMS+Groupware, Free Source Software (GNU/LGPL), using PHP, ADOdb, Zend Framework, jQuery and Smarty. It is actively developed by a very large international community and is translated in over 35 languages. TikiWiki can be used to create all sorts of Web applications, sites, portals, knowledge base, intranets, and extranets." A few stats to give an idea of the scope of the project * Over 1 million lines of code. * 220+ developers directly committing to the core, with countless other people helping with support, documentation, testing, etc. * 1000+ pages of documentation. * A new code commit every 2 hours (average of last 5 years) * 16 000+ registered users on tikiwiki.org * 700 000+ downloads Also: http://info.tikiwiki.org/Fact+Sheet http://support.mozilla.com/ (10 million page views per week) and wiki.kde.org are powered by Tiki Tiki uses a database abstraction layer so it can be used with many databases (PostgreSQL, Oracle, Sybase, SQLite) in addition to MYSQL. However, support for anything but MySQL has become more & more problematic. It's not strictly a chicken & egg problem because Tiki once worked with non-MYSQL. However, without maintainers, it was lost over time. So we have come to a difficult decision. In about 50 days, database independence will be dropped in Tiki unless a maintainer steps up. So Tiki will become officially MySQL-only. Why? -------- We would love to support many databases, especially PostgreSQL because it's an open source & community-managed project like Tiki. There are many reasons why we would want database independence and it's no use listing them here because it's not that we don't want. It's that we don't have the resources to do so. Tiki is a huge application and we would need active devs that use/maintain Tikis on other databases. However, since we have no maintainer, we have been for a long time now in a "Worst of both worlds" situation. *Extra code to maintain *Bugs that never get fixed *People that are disappointed (feeling it's "false-advertising") *Not taking full advantage of MySQL advanced features More information here: http://dev.tikiwiki.org/Database+independence This is very disappointing to me because I have always wanted Tiki to be as universal as possible. So I don't want to give up on this goal without a fight. Which is why I am writing to you today. I look forward to any advice or help you may provide. Best regards, -- Marc Laporte http://MarcLaporte.com http://TikiWiki.org/MarcLaporte
Forwarded the message to a Venezuelan mailing list, hope it will get spread soon... Marc Laporte escribió: > Hello to the PostgreSQL community! > > I asked someone in the PostgreSQL community and he wrote: "There have > been past conversations on the advocacy's mailing list discussing the > lack of implementation of web based front-ends using PostgreSQL. You > could post a request for help on the advocacy mail list." > > This is a request for assistance/advice. Please point me to the right > people/place if this is the wrong place. > > > I am a project admin for TikiWiki CMS/Groupware. > > "TikiWiki CMS/Groupware is a full-featured, web-based, multilingual, > tightly integrated, all-in-one Wiki+CMS+Groupware, Free Source > Software (GNU/LGPL), using PHP, ADOdb, Zend Framework, jQuery and > Smarty. It is actively developed by a very large international > community and is translated in over 35 languages. TikiWiki can be used > to create all sorts of Web applications, sites, portals, knowledge > base, intranets, and extranets." > > A few stats to give an idea of the scope of the project > * Over 1 million lines of code. > * 220+ developers directly committing to the core, with countless > other people helping with support, documentation, testing, etc. > * 1000+ pages of documentation. > * A new code commit every 2 hours (average of last 5 years) > * 16 000+ registered users on tikiwiki.org > * 700 000+ downloads > > Also: > http://info.tikiwiki.org/Fact+Sheet > http://support.mozilla.com/ (10 million page views per week) and > wiki.kde.org are powered by Tiki > > Tiki uses a database abstraction layer so it can be used with many > databases (PostgreSQL, Oracle, Sybase, SQLite) in addition to MYSQL. > However, support for anything but MySQL has become more & more > problematic. It's not strictly a chicken & egg problem because Tiki > once worked with non-MYSQL. However, without maintainers, it was lost > over time. > > So we have come to a difficult decision. In about 50 days, database > independence will be dropped in Tiki unless a maintainer steps up. So > Tiki will become officially MySQL-only. > > Why? > -------- > We would love to support many databases, especially PostgreSQL because > it's an open source & community-managed project like Tiki. There are > many reasons why we would want database independence and it's no use > listing them here because it's not that we don't want. It's that we > don't have the resources to do so. Tiki is a huge application and we > would need active devs that use/maintain Tikis on other databases. > > However, since we have no maintainer, we have been for a long time now > in a "Worst of both worlds" situation. > *Extra code to maintain > *Bugs that never get fixed > *People that are disappointed (feeling it's "false-advertising") > *Not taking full advantage of MySQL advanced features > > More information here: > http://dev.tikiwiki.org/Database+independence > > This is very disappointing to me because I have always wanted Tiki to > be as universal as possible. So I don't want to give up on this goal > without a fight. Which is why I am writing to you today. > > I look forward to any advice or help you may provide. > > Best regards, > > >
Marc, > This is very disappointing to me because I have always wanted Tiki to > be as universal as possible. So I don't want to give up on this goal > without a fight. Which is why I am writing to you today. Thanks for contacting us. Clearly we need a way to advertise through our community which projects are looking for PostgreSQL maintenance/porting help; for now we can put TikiWiki in the Weekly News or similar, but it would be nice to do this more systematically. I assume there's already been appeals on the tikiwiki user mailing lists? Ultimately the maintainer needs to be someone who uses tikiwiki regularly or they won't stick to it. Actually ... *does* anyone use TikiWiki with Postgres right now? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com
On Mon, Jun 8, 2009 at 12:29 AM, Marc Laporte <marclaporte@tikiwiki.org> wrote: > Tiki uses a database abstraction layer so it can be used with many > databases (PostgreSQL, Oracle, Sybase, SQLite) in addition to MYSQL. > However, support for anything but MySQL has become more & more > problematic. It's not strictly a chicken & egg problem because Tiki > once worked with non-MYSQL. However, without maintainers, it was lost > over time. I'm guessing one of the painful things you deal with is maintaining the create and upgrade DDL scripts for all those platforms. I've done this in the past (years ago now, thankfully) for several database-independent products. It's not fun. I'm the lead developer on Power*Architect, an open source data modeling tool that lets you develop your data model in a platform-independent and visual way, then "forward engineer" to several platforms (from your list, we support PostgreSQL, Oracle, and MySQL--Sybase and SQLite support would need a bit of work). You could use this to generate both create and upgrade scripts for all the supported platforms. I hope this can help you argue to keep PostgreSQL support. With a platform-independent data model, supporting multiple platforms is much easier. I've done the switch from hand-coded SQL to platform independent visual modeling on real projects, so I could give a bit of advice about how to approach the problem if any of the tikiwiki developers are interested in trying it! -Jonathan
On Mon, Jun 8, 2009 at 4:56 PM, Josh Berkus<josh@agliodbs.com> wrote: > Marc, > >> This is very disappointing to me because I have always wanted Tiki to >> be as universal as possible. So I don't want to give up on this goal >> without a fight. Which is why I am writing to you today. > > Thanks for contacting us. Clearly we need a way to advertise through our > community which projects are looking for PostgreSQL maintenance/porting > help; for now we can put TikiWiki in the Weekly News or similar, but it > would be nice to do this more systematically. > This is a great idea! TikiWiki-Firefox collaboration has been hugely successful. I am sure it can be the same. I think our best shot is if both communities use their network to try to find one or many people that see value in this project and are ready to help out. We combine : *Experienced Tiki devs but that are unfamiliar with PostgreSQL (2 so far have expressed interest) *With PostgreSQL wizards that have a need for a Wiki+CMS+Groupware hybrid Both will have things to learn from each other :-) > I assume there's already been appeals on the tikiwiki user mailing lists? Yes. And I just added here: http://wiki.postgresql.org/wiki/TikiWiki_CMS/Groupware > Ultimately the maintainer needs to be someone who uses tikiwiki regularly > or they won't stick to it. > Exactly. > Actually ... *does* anyone use TikiWiki with Postgres right now? > I don't know for sure. But I am pretty sure there are some old versions out there (because AFAIK, it used to work). The problem is that maybe some people will upgrade in 6-12 months, only to find out at that time that PG support has been dropped. Best regards, M ;-) -- Marc Laporte http://MarcLaporte.com http://TikiWiki.org/MarcLaporte
Hi Jonathan, Thanks for this information and offer. You obviously know our pain, inside-out :-) I am glad to report that 2 Tiki developers have expressed interest so far. I am hereby passing on the link to Tiki dev-list :-) http://code.google.com/p/power-architect/ Best regards, M ;-) On Mon, Jun 8, 2009 at 5:40 PM, Jonathan Fuerth<fuerth@sqlpower.ca> wrote: > On Mon, Jun 8, 2009 at 12:29 AM, Marc Laporte <marclaporte@tikiwiki.org> wrote: >> Tiki uses a database abstraction layer so it can be used with many >> databases (PostgreSQL, Oracle, Sybase, SQLite) in addition to MYSQL. >> However, support for anything but MySQL has become more & more >> problematic. It's not strictly a chicken & egg problem because Tiki >> once worked with non-MYSQL. However, without maintainers, it was lost >> over time. > > I'm guessing one of the painful things you deal with is maintaining > the create and upgrade DDL scripts for all those platforms. I've done > this in the past (years ago now, thankfully) for several > database-independent products. It's not fun. > > I'm the lead developer on Power*Architect, an open source data > modeling tool that lets you develop your data model in a > platform-independent and visual way, then "forward engineer" to > several platforms (from your list, we support PostgreSQL, Oracle, and > MySQL--Sybase and SQLite support would need a bit of work). You could > use this to generate both create and upgrade scripts for all the > supported platforms. > > I hope this can help you argue to keep PostgreSQL support. With a > platform-independent data model, supporting multiple platforms is much > easier. I've done the switch from hand-coded SQL to platform > independent visual modeling on real projects, so I could give a bit of > advice about how to approach the problem if any of the tikiwiki > developers are interested in trying it! > > -Jonathan > -- Marc Laporte http://MarcLaporte.com http://TikiWiki.org/MarcLaporte