Forum OpenACS Development: Re: CVS monitoring for OpenACS: fisheye.openacs.org

16: Re: CVS monitoring for OpenACS: fisheye.openacs.org (response to 15)

Posted by Jim Lynch on 12/07/12 03:09 AM

ahh, forgot about that. could you outline the process of doing the generation? One thing to note, it appears that there was a long period where, for 5.7, this mechanism was not maintained such that someone could get it from its "channel". Is it also the case that it's not clear who has time to maintain this as well?

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?

-Jim

17: Re: CVS monitoring for OpenACS: fisheye.openacs.org (response to 16)

Posted by Gustaf Neumann on 12/07/12 03:44 PM

Up to my partial knowledge there is no detailed description of the dependencies and the exact process. Part of the work is always to find the bits and pieces from the source code.... at least for me.

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.

18: Re: CVS monitoring for OpenACS: fisheye.openacs.org (response to 17)

Posted by Jim Lynch on 12/07/12 09:34 PM

Thanks Gustaf! I appreciate the explanation!

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.

-Jim

19: Re: CVS monitoring for OpenACS: fisheye.openacs.org (response to 18)

Posted by Gustaf Neumann on 12/08/12 10:24 AM

The programmatical changes are only required on the main repository part (openacs.org). Everything done with cvs can be done with git as well, sometimes maybe slightly different. One has much options with git. Do we want/need submodules? What kind of workflows do we want to support, do we recommend? The biggest piece of work is finally documentation. At the end, if we would do everything the same way as before, is the change worth the effort?

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.

20: Re: CVS monitoring for OpenACS: fisheye.openacs.org (response to 19)

Posted by Dafydd Crosby on 02/12/13 07:16 PM

I've already done some patches to improve the APM repositories. If it would be the thing that finally gets OACS to move to Git, I'll happily put in the effort to make another patch so that it will do the APM building from Git.

http://www.openacs.org/bugtracker/openacs/patch?patch_number=918
http://www.openacs.org/bugtracker/openacs/patch?patch_number=919