Forum OpenACS Improvement Proposals (TIPs): Re: TIP # 23 (Proposed): Core code changes and bug fixes require approved TIP.

I think this thread could be boiled down to:

DO NOT EVER BREAK EXISTING CODE

I know that it's more difficult to work this way because you can't just change the code when you want. But I've seen too many packages move from working to obsolete because they "don't have adequate maintenance". The point is, they should require *no* maintenance once they are accepted into the mainstream. If a great, new, slick API is appropriate and it is *not* compatible with existing code, it should go into a new namespace and existing core (or other package) code should be refactored to interface with the new API.

  • Nobody's code breaks
  • Packages only become obsolete when a newer, bigger, better package provides better service than the existing package
  • Developers don't have to refactor tested and QA'd production code every time a new OACS release comes out
  • Users can keep up with *every* new release if they want to
  • Contributions by developers to the community do not become a maintenance nightmare
Too difficult?
As to Randy's "Do not ever break existing code" - that's more of a wish, right?

Nobody wants to do it, but once in a while it turns out that it is impossible. For the upcoming 5.0 release I18N doesn't break the past, the templating system change does. There simply was no other way to fix this behaviour.

We need to balance stability with being able to move forward - let's see how OCT governance works out.

I think communicating such changes is important and not changing things without a consensus is also quite important but I think the current machanisms for oversight are reasonable (longish beta periods, nightly builds, commit mails, the cvs log browser's RSS feed, and the existing forums and irc).

Formalizing this for the core API makes sense to me but for a proposal like this to be acceptible we would need to be more careful about having things labeled private and public (and would need to add an experimental attribute to make clear that certain APIs were still open to change w/o the onus of writing a TIP). In addition I think "changing an api" would have to mean causing existing unit tests to fail (and of course such unit tests would need to be written...). As it stands, generally there are no unit tests to define current behavior and so the expected behavior is implicit in the way the APIs are used (and sometimes explicit in the documentation -- although there are enough conflicts between the code and documentation that even that is not really a good way to define expected behavior).

In any case, I find the penalty overly harsh and prone to capricious or contentious revocation of commit. Revoking commit for someone should be carefully considered, be the consensus of the OCT, and should never be up to one person (you need only look at times it's happened in other open source projects to see the potential repercussions). I would strongly object to any element of project governance which would allow something like that to happen.