Forum OpenACS Q&A: Re: Quality of OpenACS

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

Posted by Dave Bauer on 06/08/06 02:04 PM

Malte

I absolutely do no agree with checking in lower quality code than what is existing.

It should be reasonable to expect that once a package is working, new development will improve or add new features etc, without breaking existing functionality.

It seems there are 3 types of pacakges, 1) acs core packages, 2) the "important" optional pakcages, basically those that make up dotlrn, and 3) other optional packages not in wide use.

Now, there are always bugs, etc, so I don't expect perfection, but an effort to always check in working code would help.

This requires a little more effort on the developer's part, to design new features in smaller chunks that more a package forward a little at a time. The other option is to wait to commit until a package is tested, especially for 1) new install of openacs and 2) upgrade.

Another key is to add automated tests is you change existing behavior. The tests can confirm that the original behavior works, and the new feature also works.

These are goals, and guidelines, not requirements, but if the community can work towards these goals, the quality will improve.

Regarding releases 1) only the release manager should release OpenACS Core packages. Right now, we are calling Don the release manager, he took over when I didn't have enough time to manage the 5.2.3 release.

Thanks for stressing following the release process, I think it does work, and is helpful to remember to test a new install bfore you release.

4: Re: Re: Quality of OpenACS (response to 3)

Posted by Malte Sussdorff on 06/08/06 03:21 PM

Dave, in the szenario you describe we will not need a release mechanism any more. Anything that is committed should be automatically released under the maturity level, as the conditions for the commit are exactly the ones I propose for releases.

So the question remains do we want strict commit or strict release rules (as we agree on the goals/guidelines/rules/bylaws/...)? What are the pros and cons of each approach. And what are the consequences for the development style and sharing of code of individual committers.

On a related note, I know that a lot of code, patches, new functionalities exist out there in the open which no one is committing, not because the functionality is not good, but because they do not have the time to test it in a proper way that will make it release worthy. My take was always to have these kind of features in HEAD and jointly figure out how to test them before release. If my take does not fit with the community at large, I would like to know how and where to exchange code that I deem interesting but did not have to time to write automated tests or test a new install with.

6: Re: Re: Re: Quality of OpenACS (response to 4)

Posted by Alex Kroman on 06/08/06 05:57 PM

I know that there is a lot of code sitting out there that won't be committed because when developers try to install a package from HEAD they get the message "Installation Failed".

Commits to HEAD should be working code that are unstable not because they don't work but because they've only been tested on the developers own machine with a vanilla OpenACS installation.