<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">Chris,</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><br></span></div><div class="gmail_default">the issue at stake here is the sanctity of the version history. It's untouchable. Think of it as immutable, append-only.</div><div class="gmail_default"><br></div><div class="gmail_default">Unless some commit actually breaks the update stream or does some other kind of major damage to users systems, it is always preferable to revert that commit by a subsequent commit.</div><div class="gmail_default"><br></div><div class="gmail_default">Patrick did that, and nobody was adversely affected.</div><div class="gmail_default"><br></div><div class="gmail_default">Our rules about caution, restraint, doubt etc are to prevent these critical problems from occurring, not to keep the version history "pretty".</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><br></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">Also, I agree with Levente that your "inbox first" rule is not actually what we agreed upon. When we promote someone to core developer we trust them enough to judge whether to put stuff into trunk directly or not. </span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><br></span></div><div class="gmail_default">Patrick could have asked first before removing this seemingly weird line, because someone put it there for a reason. He's also correct in questioning that reason, since this is not how 32 bit forms should work today. It breaks the assumptions of everyone who has ever worked with graphics before. <span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small"><br></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><br></span></div><div class="gmail_default">I'm a champion of backwards-compatibility and not unnecessarily breaking things, but that should not stand in the way of necessary cleanup. There is a good argument that this hack is not needed anymore, so let's fix it.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><br></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">- Bert -</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><br></span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">On Wed, Oct 17, 2018 at 1:37 PM Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:</span><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Levente,<br>
<br>
The issue at large here (and what the swiki updates are about) is<br>
management of quality ancestry and code repository. I'm asking you to<br>
care about the "content" of Squeak that lies beyond the current<br>
running code in the image memory. We have had on-going and very<br>
tiring discussions through the years, particularly when spirit and<br>
letter of the "New Community Development Model" was violated. These<br>
three:<br>
<br>
* Exercise caution. This is a running system and breaking it<br>
needlessly is generally frowned upon.<br>
* Restrain yourself. Getting developer access doesn’t mean you are<br>
free to put in every pet extension you always wanted to have without<br>
discussion.<br>
* If in doubt, ask. T....<br>
<br>
very much resemble what I wrote on the swiki. And they appear before:<br>
<br>
* You break it, you fix it.<br>
<br>
Reading between the lines, "You break it, you fix it" is the<br>
*last-resort* when the first three failed.<br>
<br>
If someone submits a whimsical, same-day change to low-level,<br>
high-impact methods with ZERO testing, breaks the image, then is<br>
immediately "undone" with another commit, then it is going to get<br>
admin'd. It happens. In this instance, please do not feign like<br>
purging litter caused harm. It was the original whimsical same-day<br>
low-level method commit that caused the harm, including having these<br>
endless discussions about it instead of just reverting one package and<br>
saying "thanks, sorry for the goof up, next time I'll use the Inbox."<br>
:(<br>
<br>
On Wed, Oct 17, 2018 at 2:52 PM Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>> wrote:<br>
><br>
> Hi Chris,<br>
><br>
> I was wondering where that list of rules came from, because they don't<br>
> even resemble the actual Trunk developement rules[1].<br>
> So, I checked the entry and found that the list was added to the wiki this<br>
> July[2].<br>
> I don't remember any discussion about changing the Trunk developement<br>
> rules. Was there such discussion? If so, where can I find it?<br>
><br>
> Levente<br>
><br>
> [1] <a href="https://squeakboard.wordpress.com/2009/07/02/a-new-community-development-model/" rel="noreferrer" target="_blank">https://squeakboard.wordpress.com/2009/07/02/a-new-community-development-model/</a><br>
> [2] <a href="http://wiki.squeak.org/squeak/3279.diff?id=60" rel="noreferrer" target="_blank">http://wiki.squeak.org/squeak/3279.diff?id=60</a><br>
><br>
> On Tue, 16 Oct 2018, Chris Muller wrote:<br>
><br>
> > I've gone and moved these two inadvertent commits to the Treated Inbox.<br>
> ><br>
> > If you'd already updated your trunk image in the last few hours,<br>
> > revert your image to Graphics-pre.403.<br>
> ><br>
> > Since we're starting fresh on a new development cycle, please take<br>
> > this opportunity to review Guidelines for Core Developers for Trunk<br>
> > submissions:<br>
> ><br>
> > <a href="http://wiki.squeak.org/squeak/3279" rel="noreferrer" target="_blank">http://wiki.squeak.org/squeak/3279</a><br>
> ><br>
> > Regards,<br>
> > Chris<br>
> ><br>
> > ___________________<br>
> > 1. Commit it to the Inbox first.<br>
> > 2. Regard the code repository with equal respect to the image, for<br>
> > example, by avoiding unnecessary litter and bloat.<br>
> > 3. Never only change formatting, and even avoid changing prior<br>
> > developers formatting when making only minor changes to a method.<br>
> > 4. Give your peers a chance to review, commit to the Inbox first.<br>
> > 5. Never commit same-day code. Think about it and live with it for at<br>
> > least a few days first.<br>
> > 6. Share it with others for extra review eyes. The Inbox is a great<br>
> > way to do this.<br>
> > 7. Only commit meaningful changes like a fix or improvement, not<br>
> > merely a spelling or comment fix. Gather those up to include the next<br>
> > time there is a meaningful change to that package.<br>
> ><br>
> ><br>
> > On Tue, Oct 16, 2018 at 11:08 AM <<a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a>> wrote:<br>
> >><br>
> >> Patrick Rein uploaded a new version of Graphics to project The Trunk:<br>
> >> <a href="http://source.squeak.org/trunk/Graphics-pre.405.mcz" rel="noreferrer" target="_blank">http://source.squeak.org/trunk/Graphics-pre.405.mcz</a><br>
> >><br>
> >> ==================== Summary ====================<br>
> >><br>
> >> Name: Graphics-pre.405<br>
> >> Author: pre<br>
> >> Time: 16 October 2018, 5:07:10.382369 pm<br>
> >> UUID: 75b41799-4dd2-7a44-b98f-89612c4d7af9<br>
> >> Ancestors: Graphics-pre.404<br>
> >><br>
> >> Restores the 32bit black-transparent conversion. The corresponding test has been adapted and set to be an expected failure as the behavior should be tackled for 32bit at one point. The inconsistency results in major issues when working with forms resulting from loading pictures from external resources. An alternative approach would require changing all methods creating forms from external sources, although that would destroy color information.<br>
> >><br>
> >> =============== Diff against Graphics-pre.404 ===============<br>
> >><br>
> >> Item was changed:<br>
> >> ----- Method: Color class>>colorFromPixelValue:depth: (in category 'instance creation') -----<br>
> >> colorFromPixelValue: p depth: d<br>
> >> "Convert a pixel value for the given display depth into a color."<br>
> >> "Details: For depths of 8 or less, the pixel value is simply looked up in a table. For greater depths, the color components are extracted and converted into a color."<br>
> >><br>
> >> | r g b alpha |<br>
> >> d = 8 ifTrue: [^ IndexedColors at: (p bitAnd: 16rFF) + 1].<br>
> >> d = 4 ifTrue: [^ IndexedColors at: (p bitAnd: 16r0F) + 1].<br>
> >> d = 2 ifTrue: [^ IndexedColors at: (p bitAnd: 16r03) + 1].<br>
> >> d = 1 ifTrue: [^ IndexedColors at: (p bitAnd: 16r01) + 1].<br>
> >><br>
> >> (d = 16) | (d = 15) ifTrue: [<br>
> >> "five bits per component"<br>
> >> r := (p bitShift: -10) bitAnd: 16r1F.<br>
> >> g := (p bitShift: -5) bitAnd: 16r1F.<br>
> >> b := p bitAnd: 16r1F.<br>
> >> (r = 0 and: [g = 0]) ifTrue: [<br>
> >> b = 0 ifTrue: [^Color transparent].<br>
> >> b = 1 ifTrue: [^Color black]].<br>
> >> ^ Color r: r g: g b: b range: 31].<br>
> >><br>
> >> d = 32 ifTrue: [<br>
> >> "eight bits per component; 8 bits of alpha"<br>
> >> r := (p bitShift: -16) bitAnd: 16rFF.<br>
> >> g := (p bitShift: -8) bitAnd: 16rFF.<br>
> >> b := p bitAnd: 16rFF.<br>
> >> alpha := p bitShift: -24.<br>
> >> alpha = 0 ifTrue: [^Color transparent].<br>
> >> + (r = 0 and: [g = 0 and: [b = 0]]) ifTrue: [^Color transparent].<br>
> >> alpha < 255<br>
> >> ifTrue: [^ (Color r: r g: g b: b range: 255) alpha: (alpha asFloat / 255.0)]<br>
> >> ifFalse: [^ (Color r: r g: g b: b range: 255)]].<br>
> >><br>
> >> d = 12 ifTrue: [<br>
> >> "four bits per component"<br>
> >> r := (p bitShift: -8) bitAnd: 16rF.<br>
> >> g := (p bitShift: -4) bitAnd: 16rF.<br>
> >> b := p bitAnd: 16rF.<br>
> >> ^ Color r: r g: g b: b range: 15].<br>
> >><br>
> >> d = 9 ifTrue: [<br>
> >> "three bits per component"<br>
> >> r := (p bitShift: -6) bitAnd: 16r7.<br>
> >> g := (p bitShift: -3) bitAnd: 16r7.<br>
> >> b := p bitAnd: 16r7.<br>
> >> ^ Color r: r g: g b: b range: 7].<br>
> >><br>
> >> self error: 'unknown pixel depth: ', d printString<br>
> >> !<br>
> >><br>
> >><br>
><br>
<br>
</blockquote></div></div></div>