Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
On Feb 1, 2011, at 7:04 AM, Stéphane Ducasse wrote:
Nicolas
We wanted to see the diff like in squeak (check the mails in september) but the squeaksource server would die under the diff size to generate (sic lukas). So? Do you think that we are explicitly against squeak. If we ever reached this state of mind, this is years that we passed it.
Maybe it's because the process only have appearances of quality, but doesn't really pay off.
Why do you say that? We log all our bugs and actions. So you can take all the fixes for squeak if you want. This is not my goal in life. Now we are more busy than average and sometimes opening a bug entry when you already pushed the code in the server is subject to missing some parts. But this is life.
Another aspect: Every 100% regid requirement kills a process. We tried that in Squeak in the past. E.g. at one point, people said we should *require* tests and a code review before adding a fix. Result: complete standstill. Yes, these things are *nice* and they should be done more often, but as soon as you require them, nothing will happen. The same with deprecation: Yes, we want to provide deprecation for one release for easy migration. But this in turn can not be a law. There is so much cruft and so little structure (API vs. internal methods undefined), that one can not move if a strict rule is adopted. Strict rules kills human processes. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
2011/2/1 Marcus Denker <marcus.denker@inria.fr>:
On Feb 1, 2011, at 7:04 AM, Stéphane Ducasse wrote:
Nicolas
We wanted to see the diff like in squeak (check the mails in september) but the squeaksource server would die under the diff size to generate (sic lukas). So? Do you think that we are explicitly against squeak. If we ever reached this state of mind, this is years that we passed it.
Maybe it's because the process only have appearances of quality, but doesn't really pay off.
Why do you say that? We log all our bugs and actions. So you can take all the fixes for squeak if you want. This is not my goal in life. Now we are more busy than average and sometimes opening a bug entry when you already pushed the code in the server is subject to missing some parts. But this is life.
Another aspect: Every 100% regid requirement kills a process. We tried that in Squeak in the past. E.g. at one point, people said we should *require* tests and a code review before adding a fix. Result: complete standstill. Yes, these things are *nice* and they should be done more often, but as soon as you require them, nothing will happen.
The same with deprecation: Yes, we want to provide deprecation for one release for easy migration. But this in turn can not be a law. There is so much cruft and so little structure (API vs. internal methods undefined), that one can not move if a strict rule is adopted.
Strict rules kills human processes.
    Marcus
I can only agree with this, the spirit of the rule matters, the letters don't. If the burden become inhuman, change the rules. Nicolas
-- Marcus Denker  -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
On 1 February 2011 08:05, Marcus Denker <marcus.denker@inria.fr> wrote:
On Feb 1, 2011, at 7:04 AM, Stéphane Ducasse wrote:
Nicolas
We wanted to see the diff like in squeak (check the mails in september) but the squeaksource server would die under the diff size to generate (sic lukas). So? Do you think that we are explicitly against squeak. If we ever reached this state of mind, this is years that we passed it.
Maybe it's because the process only have appearances of quality, but doesn't really pay off.
Why do you say that? We log all our bugs and actions. So you can take all the fixes for squeak if you want. This is not my goal in life. Now we are more busy than average and sometimes opening a bug entry when you already pushed the code in the server is subject to missing some parts. But this is life.
Another aspect: Every 100% regid requirement kills a process. We tried that in Squeak in the past. E.g. at one point, people said we should *require* tests and a code review before adding a fix. Result: complete standstill. Yes, these things are *nice* and they should be done more often, but as soon as you require them, nothing will happen.
The same with deprecation: Yes, we want to provide deprecation for one release for easy migration. But this in turn can not be a law. There is so much cruft and so little structure (API vs. internal methods undefined), that one can not move if a strict rule is adopted.
Strict rules kills human processes.
+1 Strict rules work mostly for pedantic people.. Not many of us having this trait. And for impulsive people like me, who is "chaotic pedant" its not always good, because boring stuff drains my energy quite fast :) We are not perfect and so, we should embrace that :)
    Marcus
-- Marcus Denker  -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
-- Best regards, Igor Stasenko AKA sig.
participants (3)
-
Igor Stasenko -
Marcus Denker -
Nicolas Cellier