Forum OpenACS Q&A: Re: Quality of OpenACS

5: Re: Quality of OpenACS (response to 1)

Posted by Janine Ohmer on 06/08/06 03:41 PM

As I have said before, I don't agree with committing code that the developer knows is not finished. That doesn't mean that everything that goes into HEAD has to be perfect, it may not be fully tested, but it shouldn't be completely non-functional either. IMHO checking out from HEAD means running on the bleeding edge of the latest code, not tripping and stumbling through a minefield.

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.

7: Re: Re: Quality of OpenACS (response to 5)

Posted by Torben Brosten on 06/08/06 11:21 PM

Janine, are you saying that the community development of the re-write of ecommerce should happen elsewhere?

http://openacs.org/xowiki/pages/en/ecommerce-g2

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

Posted by Janine Ohmer on 06/08/06 11:49 PM

Well, I'm not the one who gets to decide such things, but IMHO a major refactoring should not be committed to HEAD until it's at least at alpha stage. Until then it should go into either a branch or it's own repository.

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.

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.

14: Re: Re: Re: Quality of OpenACS (response to 7)

Posted by Tracy Adams on 06/09/06 08:06 AM

>>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.

15: Re: Re: Re: Quality of OpenACS (response to 7)

Posted by Torben Brosten on 06/09/06 08:33 AM

Adding code in small unbroken components is essentially how development is being done. Some packages are new, others are modifications to existing packages where changes are not meant to break anything. No work is being done to the ecommerce package directly.

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.