Forum OpenACS Q&A: Re: Re: Re: Re: Quality of OpenACS

9: Re: Re: Re: Re: Quality of OpenACS (response to 8)

Posted by Stan Kaufman on 06/09/06 12:15 AM

Maybe I'm just thicker than a whale omelet, but I remain puzzled by why/when development goes into HEAD vs a branch. For instance, while working now with file-storage, I see that the version in HEAD is 5.1.0a17 while the version in oacs-5-2 is 5.2.2. Clearly work is going on in the branch that may or may not end up in HEAD, instead of vice versa. These aren't just bug fixes; these are enhancements or otherwise nontrivial developments.

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?

10: Re: Re: Re: Re: Re: Quality of OpenACS (response to 9)

Posted by Janine Ohmer on 06/09/06 12:27 AM

If I was the Queen, it would work like this:

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.

11: Re: Re: Re: Re: Re: Re: Quality of OpenACS (response to 10)

Posted by Stan Kaufman on 06/09/06 12:36 AM

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.

13: Re: Re: Re: Re: Re: Re: Re: Quality of OpenACS (response to 11)

Posted by Janine Ohmer on 06/09/06 07:53 AM

While I agree with Stan's point, I should clarify that the cause and effect in my case are not as they appear. I don't commit much anymore because the sites I work on have not released their code, and because some of what I do is too specialized to be of use to anyone else. So I am unfamiliar with the current processes because I don't have a need to commit very often, not the other way around.

12: Re: Re: Re: Re: Re: Quality of OpenACS (response to 9)

Posted by Malte Sussdorff on 06/09/06 08:05 AM

Thanks a lot for your explanation and the connection to Debian. This is exactly the way I see it.

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.