Forum OpenACS Q&A: Re: Re: Re: Re: Quality of OpenACS
This is unlike what happens in other settings -- eg Debian. There the versions of packages in "unstable" are always later than those in "testing", which are later than those in "stable". Seems to me that HEAD should be "unstable", the tip of oacs-5-2 should be "testing" and then a named release would be "stable".
Package developers with Debian do all their work in unstable and then push their work down into the more stable versions once bug fixes and dependencies, etc, are settled. WIth OpenACS the development occurs lower down (because that's what can be installed and run) and then eventually (hopefully) gets pushed up to HEAD. Is this the sensible way to do it?
Ongoing development would be committed to private repositories. Only when the work neared completion would it go into HEAD, which would, as you said, be considered unstable. Ongoing bugfixes and small changes would be made directly in HEAD.
When it was time for a release a new branch would be opened up, and last minute fixes would be done there. After the release was done, the branch would be merged back into HEAD and there would be no other branches until the next release.
However, I'm not the Queen and we have an even more complicated setup than most projects because core and packages are released separately, so the above probably wouldn't work.
I have never been exactly sure what the current process is; I don't commit all that often so when I do need to I just find out from Dave where it should go. That way I won't screw it up.
I have never been exactly sure what the current process is; I don't commit all that often...
Seems to me that that is the undesirable result of all this: multiple people solve the same problems on their own without getting the solutions back to the common code base, so we all duplicate each others' work and still wind up with unfixed problems.
HEAD : Unstable
Tip of released branch: Testing
Released versions: Stable
If we could agree on this denomination, we should then clarify the expectations for each of the trees.
As for where does development happen, here is the take I have been following so far when a project starts:
- Get a checkout from the current release
- Get a checkout from HEAD for the packages that I know will change heavily.
- Add new packages to HEAD
- Merge this together in the development and production server for the client, along with custom packages in our own repository.
And here is my way of committing:
- When I fix change functionality in released packages make sure they install on other environments (read: make a quick cvs update on other servers under my maintenance and do a quick check).
- HEAD package changes are committed if they work on the development server and then moved into production. No further testing on other machines.
- Once in a while I sit down and test the installation (in contrast to only upgrades) of a couple of these packages on a blank core release, using CVS. If it works I release the packages using the compat flag.
- Today I learned, that I should also release the required packages, otherwise the release does not make any sense.