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

I think that at a minimum, anything that breaks backwards compatibility should require a TIP.

Joel - do you mean changes to "actual" or "documented" functionality?

I'm assuming (based on the poster and timing) that this TIP is a reaction to the ad_page_contract stuff, so within that context - if the rule is that changes to the documented behaviour of core APIs require a TIP then Jun's changes wouldn't have required one (since the behaviour when vars are set before ad_page_contract is called isn't specified in the documentation).

Conversely, if the rule is that any changes to behaviour of core APIs for a given set of inputs (changes to existing functionality rather than API additions) require a TIP, then people are in effect being encouraged to add flags to handle the quirks of their own requirements, which in my opinion is likely to lead to a *more* fragmented and harder to understand API.

I don't know what the solution here is, but I don't think it lies in setting formal rules that won't in practice be followed.

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

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.