Forum OpenACS Development: Re: social networking functionality for acs-subsite? TIP?

Collapse
Posted by Don Baccus on
Torben, you've been around for a long time, and you know full well that changes such as this to core require a TIP.

That rule holds for me, for DaveB, Emmanuelle, Gustav - it holds for all OCT members.

If OCT members are required to TIP for such things, why in hell do you imagine that *YOU* are so special that *YOU* don't need to TIP???

Please explain your reasoning as to why you're so much smarter than those of us on the OCT that you get to exempt yourself from the rules that the OCT imposes upon itself.

Also note that since you're not an OCT member, you can't submit a TIP on your own, but rather must get an OCT member to endorse it.

You might want to drop the "I don't have to TIP because I don't want to" attitude ...

"acs-subsite seems the most appropriate for sharing social networking features instead of having them scoped per package. Should the code be moved to another package?"

You're not even sure you're doing this in the right place, and *still* you argue that you don't need to follow the same TIP process that OCT members like myself must follow?

Hi Don,

It's a stressful time, isn't it?

I don't think I'm special. I really didn't think this social networking thing was worth distracting the OCT from other work. It seems like a very small, incrementally positive thing. Nothing more. As an afterthought, based on your reaction, I'm wondering if there is some kind of MIT/facebooky vs. MIT.alt feud thing motivating this dialog.

You wrote: "since you're not an OCT member, you can't submit a TIP on your own, but rather must get an OCT member to endorse it."

The TIP rules, as I understand them, don't have this requirement[1].

You wrote: "You're not even sure you're doing this in the right place.."

I'm fairly confident, yet remain open-minded and do not assume to understand all core-developer issues. If others are working on social networking features, I'm for moving it into a social-networking package. Create or show me the package, and I'll move it there.

1. TIP rules: https://openacs.org/forums/message-view?message_id=115576

Collapse
Posted by Don Baccus on
The TIP rules, as I understand them, don't have this requirement[1].

OK, fine, we relaxed that requirement (it was discussed in the beginning).

Great, you get to start a TIP.

It doesn't mean you get to hack core without TIP'ing.

I don't think I'm special. I really didn't think this social networking thing was worth distracting the OCT from other work. It seems like a very small, incrementally positive thing. Nothing more. As an afterthought, based on your reaction, I'm wondering if there is some kind of MIT/facebooky vs. MIT.alt feud thing motivating this dialog.

Oh, good grief, Torben, stuff a sock in the conspiracy theory orifice.

You've been told you need to TIP before adding functionality to core.

This is not new.

I'm fairly confident, yet remain open-minded and do not assume to understand all core-developer issues

This statement alone justifies our policy that changes of this sort require a TIP.

Create or show me the package, and I'll move it there.

That's not how it works, Torben.

Remove your commits. We'll discuss afterwards if you choose to TIP.

Collapse
Posted by Don Baccus on
As an afterthought, based on your reaction, I'm wondering if there is some kind of MIT/facebooky vs. MIT.alt feud thing motivating this dialog.

1. TIP'ing is our process, well established, and no secret.

2. You have a personal habit of breaking stuff in core and others have had to spend time fixing it in the past ... while this doesn't mean we'll be more strict in our requiring you to TIP than we are on ourselves, it does mean that your thinking that we'll be *more* lax than we are on ourselves or others just ain't going to happen.

Hi Don,

you wrote: "You have a personal habit of breaking stuff in core and others have had to spend time fixing it in the past ..."

I supposed it could be viewed that way. I have mistakenly broken core functionality from inadvertently breaking package.info XML standards so the core couldn't read it --twice.

Yet, to my defense, I've also taken initiative to help fix things that were inadvertently broken by code improvements from others, digging in where I had little understanding. The outcomes were positive, even if my own net contribution was only in helping others to see the problem and motivating them to fix it.

I will TIP all core changes, including the one in dispute. Sorry for the confusion on removing the code.. I'm working on it..