Yes, I would be willing to maintain the system if you guys wanted me to. Also, I have answers for some of the items on the list just so that I could expand on my belief that Enano could get the job done.<div><br></div><div> """""""""""""""</div><div><div>* Good security record</div><div>Enano has a good security record, it had few holes in it during its development period, and these were quickly spotted and plugged up nicely</div> <div>* Proactive, security minded developer community that is ...</div><div>Enano was designed with security in mind, and the developer absolutely believes security is top priority</div><div>* Highly responsive, especially to security issues</div> <div>The Developer will react VERY quickly to any security issues and fix them ASAP</div><div>* Flexible enough auth system to attach to FAS</div><div>Possible. Enano 1.1.x-hg uses HMAC-SHA1 for password storage, and DiffieHellman + AES192 for password transmission (that is the whole backend). I'm not sure what FAS2 uses for auth system, but it will be likely that the auth system backend in Enano would be entirely rewritten for FAS2 unless FAS2 were to adopt our system. Somehow, I doubt that Fedora would adopt OUR system for authentication :)</div> <div>* RSS</div><div>Enano's FeedMe plugin provides RSS feeds</div><div>* L10n that doesn't break the translator workflow</div><div>I have no idea what this means.</div><div>* Output for Transifex (PO/POT)</div><div> Could be done with a helper script according to the Developer.</div><div>* Content workflow (write <=> edit => publish)</div><div>No idea what this means.</div><div>* Internal version control with rollback capability</div> <div>Definitely. Due to the wiki capabilities in Enano, all documents have the capability of being rolled back, it supports diffing and revision control</div><div>* Content expiration (automatic)</div><div>Not sure, but I think this could be done through a plugin</div> <div>* Multiple roles, e.g. writer, team lead, editor, publisher, managing editor</div><div>Defintely. Group support is in Enano and through its ACLs it is possible to set the exact correct permissions for each group to suit its role</div> <div>* Categorize/tag content for easy base organization</div><div>Definite support for tags</div><div>* Search that works</div><div>Yes. The Search works very well.</div><div>* Integrate with FAS</div><div>I'm not sure of the integration points for FAS2 for Enano. It was actually because our efforts to get the Fedora Project to use Enano last summer that Enano now has Postgres support, so if FAS2 uses Postgres as a backend, it could be done through that. A method will have to be investigated.</div> <div>* Be a CMS as a core function, not an add-on</div><div>It definitely is a CMS at the core.</div><div>* Handle making certain pages or content areas static/non-database driven, such as for scaling during times of heavy resource demand</div> <div>Can be done with adding a plugin</div><div>* Must not lock us in. Data should be portable to another CMS.</div><div>Any CMS that supports importing MediaWiki and HTML page data from MySQL/Postgres should be able to import any and all documents from Enano straight from the database.</div> <div>"""""""""""</div><br><div class="gmail_quote">2009/1/15 Paul W. Frields <span dir="ltr"><<a href="mailto:stickster@gmail.com">stickster@gmail.com</a>></span><br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d">On Thu, Jan 15, 2009 at 08:16:31AM -0600, King InuYasha wrote:<br> > I would like to suggest Enano CMS, which fulfills most of the requirements<br> > without plugins. It would take some work to get FAS2 integration and stuff<br> > though. It uses MediaWiki syntax, so it is portable among other CMSes that<br> > support importing MediaWiki data.<br> <br> </div>As I understand the post Karsten made earlier, suggestions will be<br> given credence if they are accompanied by people willing to deploy and<br> maintain the suggested system. I couldn't tell from your post if<br> you're saying you're willing to do that, but you may in fact be saying<br> just that. Could you clarify so the Docs team can understand where to<br> fit this suggestion into the lineup?<br> <div><div></div><div class="Wj3C7c"><br> --<br> Paul W. Frields <a href="http://paul.frields.org/" target="_blank">http://paul.frields.org/</a><br> gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717<br> <a href="http://redhat.com/" target="_blank">http://redhat.com/</a> - - - - <a href="http://pfrields.fedorapeople.org/" target="_blank">http://pfrields.fedorapeople.org/</a><br> <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a>: stickster @ #fedora-docs, #fedora-devel, #fredlug<br> </div></div><br>--<br> fedora-devel-list mailing list<br> <a href="mailto:fedora-devel-list@redhat.com">fedora-devel-list@redhat.com</a><br> <a href="https://www.redhat.com/mailman/listinfo/fedora-devel-list" target="_blank">https://www.redhat.com/mailman/listinfo/fedora-devel-list</a><br></blockquote></div><br></div>