Your favorite CMS running docs.fedoraproject.org?
Karsten Wade
kwade at redhat.com
Fri Jan 16 17:54:34 UTC 2009
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/5e58e723/attachment.sig>
More information about the fedora-devel-list
mailing list