Forum OpenACS Development: Re: CVS monitoring for OpenACS: fisheye.openacs.org
the github sync is done currently "manually" one-way. The openacs.org infrastructure depends currently on cvs (apm generation, upgrade from repository, ...), all documentation (official docs, wiki) address the repository, so this move would be much more work than just altering the SCM. It is not clear, who has to time to do this.
I would imagine it's something like, identify APMs and core infrastructures that are compatible, tar/gzip the apms and put them in an appropriate place such that they can be downloaded?
With core packages specifically, do all their version numbers match?
For non-core packages, how was it determined (if other than just testing) whether the non-core pkg was compatible with a particular core?
Once so determined, how is it marked so it can be viewed as part of what's available to be downloaded?
Finally, have I missed one or more overview items for this process?
As a rough picture: the cvs guidelines describe the required tags for every release. In a nightly build process, the apm builder iterates over a list versions (OpenACS releases), checks these out based on the tags and builds fresh .apm files for every release.
Update-from-repository queries the openacs.org based on the installed release of the client installation and gets the list of packages available for this release. By comparing the version numbers the local installation figures out what apms are offered for an installation.
It happens from time to time, that update from repository is broken. It happens e.g. when someone increases e.g. the major version from OpenACS without telling the apm generator, that this happened, or when some does not tag time files properly.
Non-core packages are not different from core-packages. There is no magic for determining the compatibility, this works just via cvs tagging: a developer has to tag a version of a package to be compatible with a release. Normally, it is a good advice to create these versions of the packages in the same branch as the major release of openacs (e.g. oacs-5-7) to allow partial fixes there.
OK, so the developer tags as (say) oacs-5-7 or openacs-5-7-compat, which causes apms to be built and placed in the filesystem somewhere.
When someone wants to update (say) openacs-5.7 and those packages selected from non-core, these packages are uploaded to the requested machine from the appropriate place in the filesystem, when update-from-repository is fired off from the installing machine.
Question for everyone, if no cvs commands are issued in update-from-repository, would there still need to be changes made to that part?
Another, when update-from-repository is broken, it can be traced back to whether tags were placed on the package before the packages are built?
With cvs, everything is focused on individual files, and for git, it's focused instead on commits. As Victor has put noncore packages in their own git repo, would this make the transition easier?
One thing might make things harder is figuring out how to interpret existing tags as they come from cvs to git in order to figure out which packages to include in the apm repository for a given version of openacs.
We have done to move to git for our learn project several years ago, victors repos are more or less a byproduct of this. We have changed our development workflows as well several times. We have now a feature-branch oriented development, which is for larger projects the way to go, when active development is happening. we have rather the fear that our code base is getting to far apart from plain openacs. however, the interests of an release manager are often different from the interests of an developer.