Forum OpenACS Q&A: Re: Quality of OpenACS
With the current level of testing resources we have available, I'm fairly confident that what would happen under the system Malte proposes is that most of the non-core packages would drift backwards in maturity until they were all broken, and then those who needed them would end up having to fix them. This places a huge burden on other developers. I can say this with some authority as it happened to me some months ago; I spent many hours of my client's time making a package work again, and in the process I made it incompatible with the other develoeper's work, so if/when he commits again the same thing is going to happen. It just makes for a big mess.
Perhaps we need a separate branch, or even a separate repository, for people to place their work in progress? I'm all for sharing unfinished code, but would prefer to not pollute the main repository with it.
Really the most important thing is that everyone agree on the guidelines. The biggest problem is having HEAD be seriously broken when the expectation is that it will be mostly functional. As long as expectations and reality match, we'll be ok.
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.
>Janine, are you saying that the community development of the re-write of ecommerce should happen elsewhere?
Or you could develop it in small enough pieces that the basic integrity of the package would be maintained.
It would be quite unsettling if we got a checkin that fundamentally broke the ecommerce package, esp. if the fixes required were more than a few hours of work. It would pretty much render the rest of us helpless or unable to work on the HEAD.
On another note, were I the queen or a surf for that matter, I would want her surfs to tend to the land (think code) outside the castle yet within the kingdom's domain, lest her people starve trying to fend for themselves.