Forum OpenACS Development: Re: Summary of Package development with CVS

2: Re: Summary of Package development with CVS (response to 1)

Posted by Jeff Davis on 07/01/04 08:07 AM

Jade, this was covered in tip 61.

It's definitely not the case that package developers should ignore the release branch; in fact generally speaking unless you are developing a package which requires features only present on HEAD developing on the current release branch (oacs-5-1 now) is probably better. Also, bug fixes absolutely should go into the release branch if the release branch is affected by the bug (though it's fine to apply it on HEAD and merge it to oacs-5-1 or vice versa).

Release branches are feature frozen only for core, so for packages working on the release branch is not a constraint. It also means that it will be easier for people to verify the package actually does work on the release branch.

I am leary of creating lots of branches for package work (and don't think it's necessary unless you are going to break something for an extended period); branching is the prefered alternative to what we had been doing (which was putting branched versions of packages in contrib). I personally would like these package branches to be named in some way thats consistent (and when someone really does need to do it we should discuss it -- they should post or ping OCT first I think).

3: Re: Summary of Package development with CVS (response to 2)

Posted by Jade Rubick on 07/01/04 07:11 PM

I guess what I'm looking for is guidance for what was left out of tip 61.

I've been told by more senior developers to commit packages to either HEAD or the oacs-5-1 branch. Different people tend to say different things.

The installation docs have people checkout packages using the compat tags. That makes development on either HEAD or the oacs-5-1 branch possible. So I guess either approach is acceptible, and that was why it was left out of TIP 61?

Other developers have expressed confusion. They would like some direction as to how to checkout packages and help contribute to them. Having two different systems makes it more complicated for them to get involved. People are asking me which branch they should check out, and I'm not really sure what to tell them. We don't really have a standard way of doing it.

Currently, I do my development on an OpenACS 5.1 installation (my developmental server). Once it is tested, I make a patch of my work, and patch the package in a checkout from HEAD, commit, and tag with openacs-5-1 compat. This allows me to make local edits in separate commits, but it does add some complexity. And it's not the most robust way of doing things.

I've asked in the past about the best way to set up CVS for development and production, to have local modifications, and still interact with OpenACS. The consensus seemed to be that CVS is not very good for this, and that everybody does it their own way, and no way is perfect, and darn wouldn't it be nice if we were all using Arch. I'd personally prefer to hear of one way that less experienced developers can default to while we learn the ropes, even if it's not perfect.

I'd like to write the documentation for this, so it's up there for everyone. But I'm still not totally clear on what the preferred way to do things is.

4: Re: Summary of Package development with CVS (response to 3)

Posted by Jeff Davis on 07/01/04 08:32 PM

Here is my view on developing versus CVS:

Doing development is easiest if you check out on a single branch.
It's bad to check out on a symbolic tag (which is what -compat is) to do development since it will be "sticky" and you will not be able to commit.
HEAD breaks -- it's less stable than the release branch and for most people not working on features in acs-core it's not the best alternative.
Sometimes people need to use features only on HEAD in which case developing on HEAD is the only choice.

As for developing in your own CVS repository and merging back, there is a lot more complexity and I don't think if you are less experienced with CVS that there is going to be any easy solution. I think for most people the best bet is either stick to submitting patches versus the reference copy you got or working on an openacs.org CVS checkout making parallel changes to whatever you are doing in your production environment (i.e. exactly what you are doing now).

Or, yeah, find someone to act as gatekeeper/patch merger between CVS and an Arch repository and switch to Arch.