-----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----- -- fedora-docs-list mailing list fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
