Who breaks it, fixes it -- A Question about our Development Model

Hey Squeak Community,

according to our development model here:
https://squeakboard.wordpress.com/2009/07/02/a-new-community-development-model/

If I break something, I am responsible for fixing it.

So, if I meant to fix a bug such as here:
http://forum.world.st/The-Trunk-Morphic-mt-1119-mcz-td4890816.html

And somebody raises an issue about new bugs added or some use case missed, is there a general need to revert that before further disscussions? More importantly, wouldn't I be in charge of reverting it? And not somebody else...

Note that we all assume that any trunk committer thoroughly investigates the changes made and fixes yet discusses obvious issues --- before committing such changes. This fundamental level of trust comes with being allowed to commit to trunk in the first place. Nevertheless, remaining issues can easily discussed on the mailing list and the responsible committer can fix/revert them right away -- or delegate it to someone else if time is rare.

At least, this is what I expect from every trunk committer. :-)

It seems* to work pretty well:
http://forum.world.st/The-Trunk-ToolBuilder-Morphic-kfr-159-mcz-td4879754.html
http://forum.world.st/The-Trunk-Collections-mt-688-mcz-td4889675.html
http://forum.world.st/The-Trunk-Monticello-mt-629-mcz-td4887731.html
http://forum.world.st/The-Trunk-Morphic-cmm-615-mcz-td4524250.html
http://forum.world.st/The-Trunk-Graphics-tfel-327-mcz-td4880035.html

Sometimes, it seems* to not work:
http://forum.world.st/The-Trunk-Morphic-cmm-1052-mcz-td4862408.htm
http://forum.world.st/The-Trunk-SMLoader-cmm-85-mcz-td4850418.html
http://forum.world.st/The-Trunk-Morphic-cmm-1120-mcz-td4890853.html
http://forum.world.st/The-Trunk-Tools-cmm-693-mcz-td4890497.html

What is your opinion?

Best,
Marcel

* No limit or warranty. Off-list discussions not considered. Just exemplified.

I think that the intention of the "you break it, you fix it" rule is
that we must take responsibility for the changes that we make, and that
we should not intentionally cause problems and then expect someone else
to clean up the mess. All of the trunk contributors have been doing their
best to respect this rule, and it works very well.

Sometimes a change is made to trunk that causes a serious problem that
affects all of us, such as breaking the update stream (and I have been
guilty of this myself). The problem may not be immediately obvious to
the person making the change, or that person may not be able to quickly
fix the issue. In those cases, I would expect that anyone who is able
to fix it should do so as quickly as possible.

For other kinds of concerns, I think that as a matter of courtesy it
is good practice to give the person who caused the problem the first
opportunity to revert the change or fix the problem.

Dave


On Thu, Apr 21, 2016 at 02:48:56AM -0700, marcel.taeumel wrote:

Hi All,


+1.  (I presume) no one wants to slow down our rate of progress or make people afraid to make mistakes.  Simply that one can't expect others to pick up the pieces.  There are obvious safe guards; run unit tests, read the mailing list, ask for help, offer to help if this is your area of expertise and you can find the time.  And if you break it, make a timely effort to fix it.

There's another aspect to this.  If you want to change something and there's a good chance it will impact other users negatively, discuss it in the mailing list first, and/or commit prototypes to inbox for others to try/review/alter.

I literally spent weeks developing and refining and doing
usability-testing of the filtering function before presenting it to
the community **five years** ago.  Now someone came along in one
afternoon this week and deleted features that were purposefully
designed that way.  They also fundamentally changed the way list
widgets respond to keyboard input since Squeak 3.x more than a decade
ago!

The date of the methods of these breakages matches the date of the
commit.  Here is what our development process says about this:

     * Exercise caution. This is a running system and breaking it
needlessly is generally frowned upon.
     * Restrain yourself. Getting developer access doesn’t mean you
are free to put in every pet extension you always wanted to have
without discussion.
      * If in doubt, ask. This is the corollary to the restrain
yourself rule. You’re not under pressure to ship a product, so you
have the time to send a note saying “hey, I’m planning to fix this old
issue and it may have some side effect here or there. Anyone having a
problem with that?”

I don't think someone who causes such a fundamental breakage with no
discussion should be offended when someone fixes it with no
discussion.  They should just acknowledge their commit was premature
like when the situation was reversed earlier this year when they
needed to revert my code:

     http://forum.world.st/The-Trunk-Morphic-cmm-1074-mcz-td4877176.html#a4877196

Our development model does not specify any rules about how fixes
should be made, whether typing new code or reverting code, nor who
should do it.

Maybe this is just an exceptional week this week?  I have no desire to
revert anyones code, I've always preferred that we simply follow our
process as written, above, like Eliot did the other day.  Slapping
needless graffitti on the Tracing Messages Browser which I developed
in VA, VW and Squeak in the 1990's was just offensive to me.  I stand
my these two reverts.  If someone is truly open to an impartial
discussion, they will be willing to begin the discussion as a proposed
improvement to the status-quo, with such proposals that make these
kinds of fundamental UI changes, beginning in the Inbox, not trunk.

Best,
  Chris


On Thu, Apr 21, 2016 at 4:48 AM, marcel.taeumel <[hidden email]> wrote:

Whilst rules are useful (assuming they’re well thought out, sensibly applied, understood and modified when needed) nothing beats simply getting on Skype or facetime or the phone or even walking down the corridor and simply talking about a problem.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"How many Grogs does it take to change a lightbulb?”
"One. Something with manipulatory appendages will be along eventually."