Fedora Documentation Platform

[Jonathan Steffan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Team,

	So, after brief thought about the Fedora Documentation Platform (FDP)
changes I'd like to do... here they are:

* Replace Makefiles with config files and then use the FDP to do all
building, allowing a user to specify they want to use the local cpu to
do the building, or if they want to use the buildd.

	+ We get to use python :-D
	+ IMHO we would get much more flexibility and a tighter integration
with our translators and translation systems (read: translators would be
able to easily render for their language to check their results before
pushing the build to zope
	+ AFAIK, we have more combined skills with python, over Makefiles
	+ Centralized code updates
	- Centralized code updates, this is because very little code will
actually be in the buildd-cli. If the command is to run local, the
buildd will just return an array of commands it would have run...
allowing the buildd-cli to run them on the local cpu. This does require
the buildd to be available and the contributor in question to have
Internet access. Do we want to allow offline building?

* Have better targets. It will be much easier for me to write more
"stable" code if I am able to checkout a CVS module and then read
(uniformly) into the buildd what this CVS module allows the buildd to
do. For example, What languages are complete? What languages are there?
When was the last build, the results? What is the target for this doc?
Where do we have it published to? ... Stuff like this. I'd like to be
able to programmatically read this information.. while also having it
very easy to work with for a human (read: use something like
ConfigParser) and storing most, if not all, information in the CVS tree
itself. For example, I really wanted to add a "lock" to the CVS module
when someone is doing TTW (through the web) editing. This will prevent
data from being lost. Right now, it is possible for users via plone to
be over written by a use editing via CVS and vice versa. I'd like to be
able to checkout a CVS module and know "right away" if there has been an
edit somewhere else... that has not been saved back to the module. If we
had a nice system that I could easily make changes via the buildd to
inform users of this.. it would be perfect. Example:

	User 1 is editing the README via plone.
	User 2 is leet and edits the docbook directly by checking out the module
	User 2 is informed with a DONTREALLYDOTHIS file that has the user info
from plone stating the edit is going on, and when.
	[ OK, so yes.. we can do this anyways... and will]
	Any action User 2 takes via the buildd-cli, they will be directly
warned and also questioned as to continue or not before they can render,
or use the cli to commit (they could of course just use direct CVS
commands, but yea)

I also need the ability to have a document in different namespaces.
Namespace = url request that retrieves rendered content.

Example:

CVS module harHar could have the namespaces /the/har/Har and also
/documentation/this/is/answering/all/you/asked

Such:

	Admin 1 authorizes Document 1 to go into official namespace as
/howto/cure/luser/error
	This document is going through the standard process of translation, and
updates.
	User 1 wants to contribute a fix to /howto/cure/luser/error but doesn't
have access to that namespace.
	* Here, we want to enable anyone to help... on the team or not.
	User 1 either copies (if they can read they can copy :-D) or inits
another document using the same CVS source. At this point I want User 1
to be able to edit the document. They will be able to, they are owners
of the object. They will be restricted from being able to call a commit,
but will be able to render from CVS (though the most likely don't want
to as it would re-render over their changes.. good thing the document
would be versioned in plone so they can revert that oops).
	* Here I want to illustrate why I really want a good way to work in
multiple locations
	User 1 does some great work and informs Admin 1 (or 2, or 15) they
should look at the changes. (Now, hopefully, I can get CMFDiff to work
correctly, but lets assume it does) The Admin user will be able to look
at the history tab and view all of the changes. If they are acceptable,
the Admin user will be able to (from this user namespace) issue a commit
to save the changes to CVS.
	Admin 1 has saved the changes.. and likes them enough they want to push
them into the official namespace. Well, all that will need to happen is
to issue a render in the official namespace.

== At this point, having config files based in CVS is even more
important. I briefly brought this up a while ago and have yet to solve
it. ==
	* What happens if we get an edit in English, for example, while
translations are going on? Even if they are not? Do we render all
languages... even when some languages have not been updated yet? Does
this mean we will have multiple running versions? Do we block renders
until all languages are updated? In our current system, it is very hard
for me to programmatically tell/detect all of these situations and
anything I've tried so far I was able to break quickly.

Depending on the answers to the above, does it not make sense to be able
to say "current render for language XY is already updated, don't
render... *next*" to save CPU and rendering time? Does it not make sense
to "ping" our translation system when we have stale detection? Do we
ping and then block the render from going to the zope instance?

I'm going to cut myself off to try to answer the rest of my questions
from any responses I get from this. Basically, IMHO moving away from the
current Makefile system will make what I think we are trying to achieve
with the FDP less of a big "what can we get done building on top of our
current system" and more of a "oh yeah, now that is cool" situation.

Jonathan Steffan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHC8ZfrRJs5w2Gr1kRApJAAKDYbPkVxzxXzunpMpzH7qjnEVMZvACffmT/
aIQCuL+OBVNzQY9mh+ReR2s=
=M3wF
-----END PGP SIGNATURE-----