On Thu, Jan 15, 2009 at 07:59:17PM -0600, King InuYasha wrote: > Yes, I would be willing to maintain the system if you guys wanted me to. We also had some good discussions with you on IRC as follow-up. > 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. I'll also reply to a few items inline: > """"""""""""""" > * Good security record > 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 > * Proactive, security minded developer community that is ... > Enano was designed with security in mind, and the developer absolutely > believes security is top priority > * Highly responsive, especially to security issues > The Developer will react VERY quickly to any security issues and fix them > ASAP Mike McGrath reminded me there are things we can do to mitigate security risks, such as isolating the system, but I appreciate the proactive security approach. > * Flexible enough auth system to attach to FAS > 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 :) In IRC, we talked with Toshio for a few minutes. IIRC, you were going to look in to the JSON interface to FAS2. > * L10n that doesn't break the translator workflow > I have no idea what this means. > * Output for Transifex (PO/POT) > Could be done with a helper script according to the Developer. These two are related. All software and documentation in Fedora is translated using PO/POT files. Many translators use Transifex (https://l10n.fedoraproject.org) to submit translations. This requires that the PO/POT files be put into a version control system. However, all of that is worked out in advance of building for the CMS. We put active content in to projects on fedorahosted.org, where the PO/POT files live. The CMS mainly needs to take the rendered HTML and PDFs (where the toolchain takes PO + XML and creates the per-language versions of the build document.) It also needs to keep track of versions in some way, ideally the same version information as the actual doc package. > * Content workflow (write <=> edit => publish) > No idea what this means. In my mind, this is the core of what a CMS does. It lets you create several groups: * Writers -- can input content up to draft mode; drafts can be restricted from being publically viewable, or are shown as clearly drafts and not finished work. * Editors -- can approve/disapprove content. Some CMS workflows do not allow an editor to actually rewrite the content; their only choice is to push back to a writer or push ahead to publish. I personally think we should have editors able to make changes in the writing; the Docs Project can make that decision. * Publishers -- take content and push it live as either early-release drafts or final content. People can fill one or more of these roles, even for the same content. The key is to make sure that a piece of content is not published as complete without having an editor read and approve. However, a team of people could share the effort -- one person writes Chapter A, one writes Chapter B, and they edit each other's chapters. > * Content expiration (automatic) > Not sure, but I think this could be done through a plugin The idea here is to be able to designate a piece of content as only relevant for a version of Fedora, and when that version is EOL, the content is marked as EOL/deprecated. We don't want to make content disappear; it remains useful to people who choose not to upgrade. But we want to make it clear that we are not supporting content from five releases ago. :) > * Multiple roles, e.g. writer, team lead, editor, publisher, managing editor > 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 OK, and I presume the capabilities tie to the write/edit/publish paradigm. > * Integrate with FAS > 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. Toshio specified in IRC that direct access to the db is not likely. > * Handle making certain pages or content areas static/non-database driven, > such as for scaling during times of heavy resource demand > Can be done with adding a plugin This may or may not matter; the last few releases have handled the additional load with proxies and caching. I put it in as a requirement as a just-in-case feature. - Karsten -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41
Attachment:
pgpzVXmsDEScx.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
