Hi All,


> On Apr 21, 2016, at 4:49 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> 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.

+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.

> Dave
> 
> 
>> On Thu, Apr 21, 2016 at 02:48:56AM -0700, marcel.taeumel wrote:
>> 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.
>> 
>> 
>> 
>> --
>> View this message in context: http://forum.world.st/Who-breaks-it-fixes-it-A-Question-about-our-Development-Model-tp4891134.html
>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>