Log in
Forgot your password?
History for RepositoryOrganizationNotes
??changed:- Repository Organization Notes Principles behind and incidental info about the organization of the repository. This is actually the notes accumulated during design of the organization. Repository Organization Requirements - The organization of the repository should be designed to value clarity and ease of collaboration over ease of performing mechanical processes (such as making release distributions). Release-making scripts will be responsible for creating "release bits" that are appropriate, and "release bits" may or may not look like what is in the repository. - The organization should support our open development process and be compatible with "product" processes. For example, it should be possible for a "shepherd" to manage a particular part of the repository and manage development in the Fishbowl. At the same time, a "product" shepherd must be able to manage a product lifecycle (which includes that part of the repository as a component part) without imposing too much overhead on the component shepherd. This means, for example, that the Zope (product) shepherd must be able to tag a specific revision of ZODB (component) for inclusion in a specific version of the product bits. It should be possible to do this (possibly for several products) with a relatively lightweight amount of coordination. It should also be able to happen in a way that doesn't impede the lifecycle of the component (which implies that our branching policy may need to change somewhat to avoid "freezes" outside of the product). - Some parts of the repository can be used in multiple ways, and have software bits that are unique to a particular usage (like things only useful in a release distribution, but not in a direct-checkout sort of usage). It is up to the shepherd of a repository area to arrange things so that they are useful in the appropriate contexts. For example, the ZEO part of the repository might manage things like start and stop scripts that are only used for a packaged release in a separate subdirectory so that it is not in the way for use as a checkout. The "release builder" for ZEO would be responsible for moving them to whatever place was appropriate in the release bits. - Software artifacts in the repository that have an identity should manage any documenation related to that identity in that place in the repository. For example, ZODB is a component part of Zope, but it is also commonly used as a component in other systems (and may have its own standalone release cycle). ZODB-specific documentation should be managed in the repository with the software. Scripts, CVS modules or other mechanisms used to make "release bits" should take appropriate action if the documentation needs to be augmented or moved around in the release bits. - Some community users like to "run from CVS", which has not been a problem until now because the repository (basically) reflected the "release bits", making it possible to "run a checkout". It is a goal to retain this ability, though it will likely be implemented using CVS "modules" that build configurations of repository bits that are shaped like release bits and can be run directly. - The repository organization should largely reflect the areas of responsibility of various "shepherds", and be as self-contained as possible. Shepherds are expected to know what is going on in their bits of the repository, and have given people write access with the understanding that they are only to make changes to their own bits. Keeping things self-contained will help prevent accidents. - The repository organization should strongly encourage the use of Python packages. Things that are not currently packages will live in an area with a derogatory name, just to make us dislike putting things there and want to move things out. Issues - Should there be a higher-level "technology area" organization, like "templating", "persistence", "relational", etc.? The reality is that (at least in the beginning) shepherds will be scarce - too scarce to have one for each DB adapter for example. One solution would be to have the "templating" shepherd, "persistence" shepherd, etc. **Resolution**: no, we are going to keep the repository as flat as possible, as management process is too fluid to design the repository around it. - Should "documentation" be a top-level area? This would relate basically to what Amos and Mike are currently doing on SF. Should it continue at SF? We don't have to answer that immediately to achieve the goals of this project. **Resolution**: yes, documentation will be a top-level area. Most likely the current SF documentation repository will move there. The New Repository Organization Here is the proposed repository organization. <pre> Packages AccessControl App BTrees DateTime DocumentTemplate HelpSys Interface OFS SearchIndex Shared StructuredText Testing TreeDisplay ZClasses ZLogger ZODB ZPublisher Zope ZServer ZEO webdav Products ExternalMethod MIMETools MailHost OFSP PythonScripts SiteAccess StandardCacheManagers ZCatalog ZGadflyDA ZSQLMethods ZopeTutorial PageTemplates Documentation TheZopeBook ZopeDevGuide etc. Releases Zope CMF etc. Binaries xxx JunkPile ![known as 'Cruft' in the actual implementation] Zope core stuff not located elsewhere ExtensionClass BTree cPickle? PCGI zlib </pre> <hr solid id=comments_below> jim (May 10, 2001 3:34 pm; Comment #1) -- <pre> > - The organization of the repository should be designed > to value clarity and ease of collaboration over ease of > performing mechanical processes (such as making release > distributions). Release-making scripts will be responsible > for creating "release bits" that are appropriate, and > "release bits" may or may not look like what is in the > repository. </pre> Overall, I agree, however, I do think that there *is* an important bit of machinery that should be supported. It should be easy to check out releases. That means that organization of a release should be possible via CVS modules. jim (May 10, 2001 3:40 pm; Comment #2) -- <pre> > This means, for example, that the Zope (product) shepherd must > be able to tag a specific revision of ZODB (component) for > inclusion in a specific version of the product bits. It should > be possible to do this (possibly for several products) with > a relatively lightweight amount of coordination. It should also > be able to happen in a way that doesn't impede the lifecycle > of the component (which implies that our branching policy may > need to change somewhat to avoid "freezes" outside of the product). </pre> If a particular configuration can be expressed via a CVS module, then this can be done in a very straightforward fashion. <pre> > - Software artifacts in the repository that have an identity > should manage any documenation related to that identity in that [86 more lines...]