Discussion:
The Trunk: Graphics-pre.405.mcz
(too old to reply)
c***@source.squeak.org
0000-10-17 21:58:23 UTC
Permalink
Patrick Rein uploaded a new version of Graphics to project The Trunk:
http://source.squeak.org/trunk/Graphics-pre.405.mcz

==================== Summary ====================

Name: Graphics-pre.405
Author: pre
Time: 16 October 2018, 5:07:10.382369 pm
UUID: 75b41799-4dd2-7a44-b98f-89612c4d7af9
Ancestors: Graphics-pre.404

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.

=============== Diff against Graphics-pre.404 ===============

Item was changed:
----- Method: Color class>>colorFromPixelValue:depth: (in category 'instance creation') -----
colorFromPixelValue: p depth: d
"Convert a pixel value for the given display depth into a color."
"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."

| r g b alpha |
d = 8 ifTrue: [^ IndexedColors at: (p bitAnd: 16rFF) + 1].
d = 4 ifTrue: [^ IndexedColors at: (p bitAnd: 16r0F) + 1].
d = 2 ifTrue: [^ IndexedColors at: (p bitAnd: 16r03) + 1].
d = 1 ifTrue: [^ IndexedColors at: (p bitAnd: 16r01) + 1].

(d = 16) | (d = 15) ifTrue: [
"five bits per component"
r := (p bitShift: -10) bitAnd: 16r1F.
g := (p bitShift: -5) bitAnd: 16r1F.
b := p bitAnd: 16r1F.
(r = 0 and: [g = 0]) ifTrue: [
b = 0 ifTrue: [^Color transparent].
b = 1 ifTrue: [^Color black]].
^ Color r: r g: g b: b range: 31].

d = 32 ifTrue: [
"eight bits per component; 8 bits of alpha"
r := (p bitShift: -16) bitAnd: 16rFF.
g := (p bitShift: -8) bitAnd: 16rFF.
b := p bitAnd: 16rFF.
alpha := p bitShift: -24.
alpha = 0 ifTrue: [^Color transparent].
+ (r = 0 and: [g = 0 and: [b = 0]]) ifTrue: [^Color transparent].
alpha < 255
ifTrue: [^ (Color r: r g: g b: b range: 255) alpha: (alpha asFloat / 255.0)]
ifFalse: [^ (Color r: r g: g b: b range: 255)]].

d = 12 ifTrue: [
"four bits per component"
r := (p bitShift: -8) bitAnd: 16rF.
g := (p bitShift: -4) bitAnd: 16rF.
b := p bitAnd: 16rF.
^ Color r: r g: g b: b range: 15].

d = 9 ifTrue: [
"three bits per component"
r := (p bitShift: -6) bitAnd: 16r7.
g := (p bitShift: -3) bitAnd: 16r7.
b := p bitAnd: 16r7.
^ Color r: r g: g b: b range: 7].

self error: 'unknown pixel depth: ', d printS
Chris Muller
2018-10-16 19:46:45 UTC
Permalink
I've gone and moved these two inadvertent commits to the Treated Inbox.

If you'd already updated your trunk image in the last few hours,
revert your image to Graphics-pre.403.

Since we're starting fresh on a new development cycle, please take
this opportunity to review Guidelines for Core Developers for Trunk
submissions:

http://wiki.squeak.org/squeak/3279

Regards,
Chris

___________________
1. Commit it to the Inbox first.
2. Regard the code repository with equal respect to the image, for
example, by avoiding unnecessary litter and bloat.
3. Never only change formatting, and even avoid changing prior
developers formatting when making only minor changes to a method.
4. Give your peers a chance to review, commit to the Inbox first.
5. Never commit same-day code. Think about it and live with it for at
least a few days first.
6. Share it with others for extra review eyes. The Inbox is a great
way to do this.
7. Only commit meaningful changes like a fix or improvement, not
merely a spelling or comment fix. Gather those up to include the next
time there is a meaningful change to that package.
Post by c***@source.squeak.org
http://source.squeak.org/trunk/Graphics-pre.405.mcz
==================== Summary ====================
Name: Graphics-pre.405
Author: pre
Time: 16 October 2018, 5:07:10.382369 pm
UUID: 75b41799-4dd2-7a44-b98f-89612c4d7af9
Ancestors: Graphics-pre.404
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.
=============== Diff against Graphics-pre.404 ===============
----- Method: Color class>>colorFromPixelValue:depth: (in category 'instance creation') -----
colorFromPixelValue: p depth: d
"Convert a pixel value for the given display depth into a color."
"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."
| r g b alpha |
d = 8 ifTrue: [^ IndexedColors at: (p bitAnd: 16rFF) + 1].
d = 4 ifTrue: [^ IndexedColors at: (p bitAnd: 16r0F) + 1].
d = 2 ifTrue: [^ IndexedColors at: (p bitAnd: 16r03) + 1].
d = 1 ifTrue: [^ IndexedColors at: (p bitAnd: 16r01) + 1].
(d = 16) | (d = 15) ifTrue: [
"five bits per component"
r := (p bitShift: -10) bitAnd: 16r1F.
g := (p bitShift: -5) bitAnd: 16r1F.
b := p bitAnd: 16r1F.
(r = 0 and: [g = 0]) ifTrue: [
b = 0 ifTrue: [^Color transparent].
b = 1 ifTrue: [^Color black]].
^ Color r: r g: g b: b range: 31].
d = 32 ifTrue: [
"eight bits per component; 8 bits of alpha"
r := (p bitShift: -16) bitAnd: 16rFF.
g := (p bitShift: -8) bitAnd: 16rFF.
b := p bitAnd: 16rFF.
alpha := p bitShift: -24.
alpha = 0 ifTrue: [^Color transparent].
+ (r = 0 and: [g = 0 and: [b = 0]]) ifTrue: [^Color transparent].
alpha < 255
ifTrue: [^ (Color r: r g: g b: b range: 255) alpha: (alpha asFloat / 255.0)]
ifFalse: [^ (Color r: r g: g b: b range: 255)]].
d = 12 ifTrue: [
"four bits per component"
r := (p bitShift: -8) bitAnd: 16rF.
g := (p bitShift: -4) bitAnd: 16rF.
b := p bitAnd: 16rF.
^ Color r: r g: g b: b range: 15].
d = 9 ifTrue: [
"three bits per component"
r := (p bitShift: -6) bitAnd: 16r7.
g := (p bitShift: -3) bitAnd: 16r7.
b := p bitAnd: 16r7.
^ Color r: r g: g b: b range: 7].
self error: 'unknown pixel depth
Tobias Pape
2018-10-16 20:01:01 UTC
Permalink
Post by Chris Muller
I've gone and moved these two inadvertent commits to the Treated Inbox.
Chris, can we please NOT do that?
There was a commit, there was a revert.
That's ok, let us live with that.
Let's please not gamble with the history except for really severe stuff.

Thanks
-Tobias
Post by Chris Muller
If you'd already updated your trunk image in the last few hours,
revert your image to Graphics-pre.403.
Since we're starting fresh on a new development cycle, please take
this opportunity to review Guidelines for Core Developers for Trunk
http://wiki.squeak.org/squeak/3279
Regards,
Chris
___________________
1. Commit it to the Inbox first.
2. Regard the code repository with equal respect to the image, for
example, by avoiding unnecessary litter and bloat.
3. Never only change formatting, and even avoid changing prior
developers formatting when making only minor changes to a method.
4. Give your peers a chance to review, commit to the Inbox first.
5. Never commit same-day code. Think about it and live with it for at
least a few days first.
6. Share it with others for extra review eyes. The Inbox is a great
way to do this.
7. Only commit meaningful changes like a fix or improvement, not
merely a spelling or comment fix. Gather those up to include the next
time there is a meaningful change to that package.
Post by c***@source.squeak.org
http://source.squeak.org/trunk/Graphics-pre.405.mcz
==================== Summary ====================
Name: Graphics-pre.405
Author: pre
Time: 16 October 2018, 5:07:10.382369 pm
UUID: 75b41799-4dd2-7a44-b98f-89612c4d7af9
Ancestors: Graphics-pre.404
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.
=============== Diff against Graphics-pre.404 ===============
----- Method: Color class>>colorFromPixelValue:depth: (in category 'instance creation') -----
colorFromPixelValue: p depth: d
"Convert a pixel value for the given display depth into a color."
"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."
| r g b alpha |
d = 8 ifTrue: [^ IndexedColors at: (p bitAnd: 16rFF) + 1].
d = 4 ifTrue: [^ IndexedColors at: (p bitAnd: 16r0F) + 1].
d = 2 ifTrue: [^ IndexedColors at: (p bitAnd: 16r03) + 1].
d = 1 ifTrue: [^ IndexedColors at: (p bitAnd: 16r01) + 1].
(d = 16) | (d = 15) ifTrue: [
"five bits per component"
r := (p bitShift: -10) bitAnd: 16r1F.
g := (p bitShift: -5) bitAnd: 16r1F.
b := p bitAnd: 16r1F.
(r = 0 and: [g = 0]) ifTrue: [
b = 0 ifTrue: [^Color transparent].
b = 1 ifTrue: [^Color black]].
^ Color r: r g: g b: b range: 31].
d = 32 ifTrue: [
"eight bits per component; 8 bits of alpha"
r := (p bitShift: -16) bitAnd: 16rFF.
g := (p bitShift: -8) bitAnd: 16rFF.
b := p bitAnd: 16rFF.
alpha := p bitShift: -24.
alpha = 0 ifTrue: [^Color transparent].
+ (r = 0 and: [g = 0 and: [b = 0]]) ifTrue: [^Color transparent].
alpha < 255
ifTrue: [^ (Color r: r g: g b: b range: 255) alpha: (alpha asFloat / 255.0)]
ifFalse: [^ (Color r: r g: g b: b range: 255)]].
d = 12 ifTrue: [
"four bits per component"
r := (p bitShift: -8) bitAnd: 16rF.
g := (p bitShift: -4) bitAnd: 16rF.
b := p bitAnd: 16rF.
^ Color r: r g: g b: b range: 15].
d = 9 ifTrue: [
"three bits per component"
r := (p bitShift: -6) bitAnd: 16r7.
g := (p bitShift: -3) bitAnd: 16r7.
b := p bitAnd: 16r7.
^ Color r: r g: g b: b range: 7].
self error: 'unknown pixel depth: ', d printString
!
Chris Muller
2018-10-16 21:27:47 UTC
Permalink
Hi Tobias and all,

Could I ask you all to please get behind the administrator (me) who
volunteers his time to understand and maintain the health of our code
repository to ensure continuous service to the Squeak community? A
commit that violates 5 of 7 guidelines is not "okay", it's actually a
kind of a slap in the face, after which I have to go clean it up, and
then get told I'm "gambling", which is total nonsense and another
slap.

The best way to achieve what you wish is to respect the trunk and its
commit rules and guidelines, and get other committers to do the same.

Regards,
Chris
Post by Tobias Pape
Post by Chris Muller
I've gone and moved these two inadvertent commits to the Treated Inbox.
Chris, can we please NOT do that?
There was a commit, there was a revert.
That's ok, let us live with that.
Let's please not gamble with the history except for really severe stuff.
Thanks
-Tobias
Post by Chris Muller
If you'd already updated your trunk image in the last few hours,
revert your image to Graphics-pre.403.
Since we're starting fresh on a new development cycle, please take
this opportunity to review Guidelines for Core Developers for Trunk
http://wiki.squeak.org/squeak/3279
Regards,
Chris
___________________
1. Commit it to the Inbox first.
2. Regard the code repository with equal respect to the image, for
example, by avoiding unnecessary litter and bloat.
3. Never only change formatting, and even avoid changing prior
developers formatting when making only minor changes to a method.
4. Give your peers a chance to review, commit to the Inbox first.
5. Never commit same-day code. Think about it and live with it for at
least a few days first.
6. Share it with others for extra review eyes. The Inbox is a great
way to do this.
7. Only commit meaningful changes like a fix or improvement, not
merely a spelling or comment fix. Gather those up to include the next
time there is a meaningful change to that package.
Post by c***@source.squeak.org
http://source.squeak.org/trunk/Graphics-pre.405.mcz
==================== Summary ====================
Name: Graphics-pre.405
Author: pre
Time: 16 October 2018, 5:07:10.382369 pm
UUID: 75b41799-4dd2-7a44-b98f-89612c4d7af9
Ancestors: Graphics-pre.404
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.
=============== Diff against Graphics-pre.404 ===============
----- Method: Color class>>colorFromPixelValue:depth: (in category 'instance creation') -----
colorFromPixelValue: p depth: d
"Convert a pixel value for the given display depth into a color."
"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."
| r g b alpha |
d = 8 ifTrue: [^ IndexedColors at: (p bitAnd: 16rFF) + 1].
d = 4 ifTrue: [^ IndexedColors at: (p bitAnd: 16r0F) + 1].
d = 2 ifTrue: [^ IndexedColors at: (p bitAnd: 16r03) + 1].
d = 1 ifTrue: [^ IndexedColors at: (p bitAnd: 16r01) + 1].
(d = 16) | (d = 15) ifTrue: [
"five bits per component"
r := (p bitShift: -10) bitAnd: 16r1F.
g := (p bitShift: -5) bitAnd: 16r1F.
b := p bitAnd: 16r1F.
(r = 0 and: [g = 0]) ifTrue: [
b = 0 ifTrue: [^Color transparent].
b = 1 ifTrue: [^Color black]].
^ Color r: r g: g b: b range: 31].
d = 32 ifTrue: [
"eight bits per component; 8 bits of alpha"
r := (p bitShift: -16) bitAnd: 16rFF.
g := (p bitShift: -8) bitAnd: 16rFF.
b := p bitAnd: 16rFF.
alpha := p bitShift: -24.
alpha = 0 ifTrue: [^Color transparent].
+ (r = 0 and: [g = 0 and: [b = 0]]) ifTrue: [^Color transparent].
alpha < 255
ifTrue: [^ (Color r: r g: g b: b range: 255) alpha: (alpha asFloat / 255.0)]
ifFalse: [^ (Color r: r g: g b: b range: 255)]].
d = 12 ifTrue: [
"four bits per component"
r := (p bitShift: -8) bitAnd: 16rF.
g := (p bitShift: -4) bitAnd: 16rF.
b := p bitAnd: 16rF.
^ Color r: r g: g b: b range: 15].
d = 9 ifTrue: [
"three bits per component"
r := (p bitShift: -6) bitAnd: 16r7.
g := (p bitShift: -3) bitAnd: 16r7.
b := p bitAnd: 16r7.
^ Color r: r g: g b: b range: 7].
self error: 'unknown pixel depth: ', d printStri
Levente Uzonyi
2018-10-17 19:52:37 UTC
Permalink
Hi Chris,

I was wondering where that list of rules came from, because they don't
even resemble the actual Trunk developement rules[1].
So, I checked the entry and found that the list was added to the wiki this
July[2].
I don't remember any discussion about changing the Trunk developement
rules. Was there such discussion? If so, where can I find it?

Levente

[1] https://squeakboard.wordpress.com/2009/07/02/a-new-community-development-model/
[2] http://wiki.squeak.org/squeak/3279.diff?id=60
Post by Chris Muller
I've gone and moved these two inadvertent commits to the Treated Inbox.
If you'd already updated your trunk image in the last few hours,
revert your image to Graphics-pre.403.
Since we're starting fresh on a new development cycle, please take
this opportunity to review Guidelines for Core Developers for Trunk
http://wiki.squeak.org/squeak/3279
Regards,
Chris
___________________
1. Commit it to the Inbox first.
2. Regard the code repository with equal respect to the image, for
example, by avoiding unnecessary litter and bloat.
3. Never only change formatting, and even avoid changing prior
developers formatting when making only minor changes to a method.
4. Give your peers a chance to review, commit to the Inbox first.
5. Never commit same-day code. Think about it and live with it for at
least a few days first.
6. Share it with others for extra review eyes. The Inbox is a great
way to do this.
7. Only commit meaningful changes like a fix or improvement, not
merely a spelling or comment fix. Gather those up to include the next
time there is a meaningful change to that package.
Post by c***@source.squeak.org
http://source.squeak.org/trunk/Graphics-pre.405.mcz
==================== Summary ====================
Name: Graphics-pre.405
Author: pre
Time: 16 October 2018, 5:07:10.382369 pm
UUID: 75b41799-4dd2-7a44-b98f-89612c4d7af9
Ancestors: Graphics-pre.404
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.
=============== Diff against Graphics-pre.404 ===============
----- Method: Color class>>colorFromPixelValue:depth: (in category 'instance creation') -----
colorFromPixelValue: p depth: d
"Convert a pixel value for the given display depth into a color."
"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."
| r g b alpha |
d = 8 ifTrue: [^ IndexedColors at: (p bitAnd: 16rFF) + 1].
d = 4 ifTrue: [^ IndexedColors at: (p bitAnd: 16r0F) + 1].
d = 2 ifTrue: [^ IndexedColors at: (p bitAnd: 16r03) + 1].
d = 1 ifTrue: [^ IndexedColors at: (p bitAnd: 16r01) + 1].
(d = 16) | (d = 15) ifTrue: [
"five bits per component"
r := (p bitShift: -10) bitAnd: 16r1F.
g := (p bitShift: -5) bitAnd: 16r1F.
b := p bitAnd: 16r1F.
(r = 0 and: [g = 0]) ifTrue: [
b = 0 ifTrue: [^Color transparent].
b = 1 ifTrue: [^Color black]].
^ Color r: r g: g b: b range: 31].
d = 32 ifTrue: [
"eight bits per component; 8 bits of alpha"
r := (p bitShift: -16) bitAnd: 16rFF.
g := (p bitShift: -8) bitAnd: 16rFF.
b := p bitAnd: 16rFF.
alpha := p bitShift: -24.
alpha = 0 ifTrue: [^Color transparent].
+ (r = 0 and: [g = 0 and: [b = 0]]) ifTrue: [^Color transparent].
alpha < 255
ifTrue: [^ (Color r: r g: g b: b range: 255) alpha: (alpha asFloat / 255.0)]
ifFalse: [^ (Color r: r g: g b: b range: 255)]].
d = 12 ifTrue: [
"four bits per component"
r := (p bitShift: -8) bitAnd: 16rF.
g := (p bitShift: -4) bitAnd: 16rF.
b := p bitAnd: 16rF.
^ Color r: r g: g b: b range: 15].
d = 9 ifTrue: [
"three bits per component"
r := (p bitShift: -6) bitAnd: 16r7.
g := (p bitShift: -3) bitAnd: 16r7.
b := p bitAnd: 16r7.
^ Color r: r g: g b: b range: 7].
self error: 'unknown pixel depth: ', d printString
Chris Muller
2018-10-17 20:36:47 UTC
Permalink
Hi Levente,

The issue at large here (and what the swiki updates are about) is
management of quality ancestry and code repository. I'm asking you to
care about the "content" of Squeak that lies beyond the current
running code in the image memory. We have had on-going and very
tiring discussions through the years, particularly when spirit and
letter of the "New Community Development Model" was violated. These
three:

* 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. T....

very much resemble what I wrote on the swiki. And they appear before:

* You break it, you fix it.

Reading between the lines, "You break it, you fix it" is the
*last-resort* when the first three failed.

If someone submits a whimsical, same-day change to low-level,
high-impact methods with ZERO testing, breaks the image, then is
immediately "undone" with another commit, then it is going to get
admin'd. It happens. In this instance, please do not feign like
purging litter caused harm. It was the original whimsical same-day
low-level method commit that caused the harm, including having these
endless discussions about it instead of just reverting one package and
saying "thanks, sorry for the goof up, next time I'll use the Inbox."
:(
Post by Levente Uzonyi
Hi Chris,
I was wondering where that list of rules came from, because they don't
even resemble the actual Trunk developement rules[1].
So, I checked the entry and found that the list was added to the wiki this
July[2].
I don't remember any discussion about changing the Trunk developement
rules. Was there such discussion? If so, where can I find it?
Levente
[1] https://squeakboard.wordpress.com/2009/07/02/a-new-community-development-model/
[2] http://wiki.squeak.org/squeak/3279.diff?id=60
Post by Chris Muller
I've gone and moved these two inadvertent commits to the Treated Inbox.
If you'd already updated your trunk image in the last few hours,
revert your image to Graphics-pre.403.
Since we're starting fresh on a new development cycle, please take
this opportunity to review Guidelines for Core Developers for Trunk
http://wiki.squeak.org/squeak/3279
Regards,
Chris
___________________
1. Commit it to the Inbox first.
2. Regard the code repository with equal respect to the image, for
example, by avoiding unnecessary litter and bloat.
3. Never only change formatting, and even avoid changing prior
developers formatting when making only minor changes to a method.
4. Give your peers a chance to review, commit to the Inbox first.
5. Never commit same-day code. Think about it and live with it for at
least a few days first.
6. Share it with others for extra review eyes. The Inbox is a great
way to do this.
7. Only commit meaningful changes like a fix or improvement, not
merely a spelling or comment fix. Gather those up to include the next
time there is a meaningful change to that package.
Post by c***@source.squeak.org
http://source.squeak.org/trunk/Graphics-pre.405.mcz
==================== Summary ====================
Name: Graphics-pre.405
Author: pre
Time: 16 October 2018, 5:07:10.382369 pm
UUID: 75b41799-4dd2-7a44-b98f-89612c4d7af9
Ancestors: Graphics-pre.404
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.
=============== Diff against Graphics-pre.404 ===============
----- Method: Color class>>colorFromPixelValue:depth: (in category 'instance creation') -----
colorFromPixelValue: p depth: d
"Convert a pixel value for the given display depth into a color."
"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."
| r g b alpha |
d = 8 ifTrue: [^ IndexedColors at: (p bitAnd: 16rFF) + 1].
d = 4 ifTrue: [^ IndexedColors at: (p bitAnd: 16r0F) + 1].
d = 2 ifTrue: [^ IndexedColors at: (p bitAnd: 16r03) + 1].
d = 1 ifTrue: [^ IndexedColors at: (p bitAnd: 16r01) + 1].
(d = 16) | (d = 15) ifTrue: [
"five bits per component"
r := (p bitShift: -10) bitAnd: 16r1F.
g := (p bitShift: -5) bitAnd: 16r1F.
b := p bitAnd: 16r1F.
(r = 0 and: [g = 0]) ifTrue: [
b = 0 ifTrue: [^Color transparent].
b = 1 ifTrue: [^Color black]].
^ Color r: r g: g b: b range: 31].
d = 32 ifTrue: [
"eight bits per component; 8 bits of alpha"
r := (p bitShift: -16) bitAnd: 16rFF.
g := (p bitShift: -8) bitAnd: 16rFF.
b := p bitAnd: 16rFF.
alpha := p bitShift: -24.
alpha = 0 ifTrue: [^Color transparent].
+ (r = 0 and: [g = 0 and: [b = 0]]) ifTrue: [^Color transparent].
alpha < 255
ifTrue: [^ (Color r: r g: g b: b range: 255) alpha: (alpha asFloat / 255.0)]
ifFalse: [^ (Color r: r g: g b: b range: 255)]].
d = 12 ifTrue: [
"four bits per component"
r := (p bitShift: -8) bitAnd: 16rF.
g := (p bitShift: -4) bitAnd: 16rF.
b := p bitAnd: 16rF.
^ Color r: r g: g b: b range: 15].
d = 9 ifTrue: [
"three bits per component"
r := (p bitShift: -6) bitAnd: 16r7.
g := (p bitShift: -3) bitAnd: 16r7.
b := p bitAnd: 16r7.
^ Color r: r g: g b: b range: 7].
self error: 'unknown p
Bert Freudenberg
2018-10-17 21:01:02 UTC
Permalink
Chris,

the issue at stake here is the sanctity of the version history.
It's untouchable. Think of it as immutable, append-only.

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.

Patrick did that, and nobody was adversely affected.

Our rules about caution, restraint, doubt etc are to prevent these critical
problems from occurring, not to keep the version history "pretty".

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.

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.

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.

- Bert -
Post by Chris Muller
Hi Levente,
The issue at large here (and what the swiki updates are about) is
management of quality ancestry and code repository. I'm asking you to
care about the "content" of Squeak that lies beyond the current
running code in the image memory. We have had on-going and very
tiring discussions through the years, particularly when spirit and
letter of the "New Community Development Model" was violated. These
* 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. T....
* You break it, you fix it.
Reading between the lines, "You break it, you fix it" is the
*last-resort* when the first three failed.
If someone submits a whimsical, same-day change to low-level,
high-impact methods with ZERO testing, breaks the image, then is
immediately "undone" with another commit, then it is going to get
admin'd. It happens. In this instance, please do not feign like
purging litter caused harm. It was the original whimsical same-day
low-level method commit that caused the harm, including having these
endless discussions about it instead of just reverting one package and
saying "thanks, sorry for the goof up, next time I'll use the Inbox."
:(
Post by Levente Uzonyi
Hi Chris,
I was wondering where that list of rules came from, because they don't
even resemble the actual Trunk developement rules[1].
So, I checked the entry and found that the list was added to the wiki
this
Post by Levente Uzonyi
July[2].
I don't remember any discussion about changing the Trunk developement
rules. Was there such discussion? If so, where can I find it?
Levente
[1]
https://squeakboard.wordpress.com/2009/07/02/a-new-community-development-model/
Post by Levente Uzonyi
[2] http://wiki.squeak.org/squeak/3279.diff?id=60
Post by Chris Muller
I've gone and moved these two inadvertent commits to the Treated Inbox.
If you'd already updated your trunk image in the last few hours,
revert your image to Graphics-pre.403.
Since we're starting fresh on a new development cycle, please take
this opportunity to review Guidelines for Core Developers for Trunk
http://wiki.squeak.org/squeak/3279
Regards,
Chris
___________________
1. Commit it to the Inbox first.
2. Regard the code repository with equal respect to the image, for
example, by avoiding unnecessary litter and bloat.
3. Never only change formatting, and even avoid changing prior
developers formatting when making only minor changes to a method.
4. Give your peers a chance to review, commit to the Inbox first.
5. Never commit same-day code. Think about it and live with it for at
least a few days first.
6. Share it with others for extra review eyes. The Inbox is a great
way to do this.
7. Only commit meaningful changes like a fix or improvement, not
merely a spelling or comment fix. Gather those up to include the next
time there is a meaningful change to that package.
Post by c***@source.squeak.org
http://source.squeak.org/trunk/Graphics-pre.405.mcz
==================== Summary ====================
Name: Graphics-pre.405
Author: pre
Time: 16 October 2018, 5:07:10.382369 pm
UUID: 75b41799-4dd2-7a44-b98f-89612c4d7af9
Ancestors: Graphics-pre.404
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.
Post by Levente Uzonyi
Post by Chris Muller
Post by c***@source.squeak.org
=============== Diff against Graphics-pre.404 ===============
----- Method: Color class>>colorFromPixelValue:depth: (in category
'instance creation') -----
Post by Levente Uzonyi
Post by Chris Muller
Post by c***@source.squeak.org
colorFromPixelValue: p depth: d
"Convert a pixel value for the given display depth into a
color."
Post by Levente Uzonyi
Post by Chris Muller
Post by c***@source.squeak.org
"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."
Post by Levente Uzonyi
Post by Chris Muller
Post by c***@source.squeak.org
| r g b alpha |
d = 8 ifTrue: [^ IndexedColors at: (p bitAnd: 16rFF) + 1].
d = 4 ifTrue: [^ IndexedColors at: (p bitAnd: 16r0F) + 1].
d = 2 ifTrue: [^ IndexedColors at: (p bitAnd: 16r03) + 1].
d = 1 ifTrue: [^ IndexedColors at: (p bitAnd: 16r01) + 1].
(d = 16) | (d = 15) ifTrue: [
"five bits per component"
r := (p bitShift: -10) bitAnd: 16r1F.
g := (p bitShift: -5) bitAnd: 16r1F.
b := p bitAnd: 16r1F.
(r = 0 and: [g = 0]) ifTrue: [
b = 0 ifTrue: [^Color transparent].
b = 1 ifTrue: [^Color black]].
^ Color r: r g: g b: b range: 31].
d = 32 ifTrue: [
"eight bits per component; 8 bits of alpha"
r := (p bitShift: -16) bitAnd: 16rFF.
g := (p bitShift: -8) bitAnd: 16rFF.
b := p bitAnd: 16rFF.
alpha := p bitShift: -24.
alpha = 0 ifTrue: [^Color transparent].
+ (r = 0 and: [g = 0 and: [b = 0]]) ifTrue: [^Color
transparent].
Post by Levente Uzonyi
Post by Chris Muller
Post by c***@source.squeak.org
alpha < 255
ifTrue: [^ (Color r: r g: g b: b range: 255)
alpha: (alpha asFloat / 255.0)]
255)]].
Post by Levente Uzonyi
Post by Chris Muller
Post by c***@source.squeak.org
d = 12 ifTrue: [
"four bits per component"
r := (p bitShift: -8) bitAnd: 16rF.
g := (p bitShift: -4) bitAnd: 16rF.
b := p bitAnd: 16rF.
^ Color r: r g: g b: b range: 15].
d = 9 ifTrue: [
"three bits per component"
r := (p bitShift: -6) bitAnd: 16r7.
g := (p bitShift: -3) bitAnd: 16r7.
b := p bitAnd: 16r7.
^ Color r: r g: g b: b range: 7].
self error: 'unknown pixel depth: ', d printString
!
Chris Muller
2018-10-17 21:59:51 UTC
Permalink
Post by Bert Freudenberg
the issue at stake here is the sanctity of the version history.
"Sanctity." If only you REALLY felt that way... :(
Post by Bert Freudenberg
It's untouchable. Think of it as immutable, append-only.
Versions buried more than one or two deep are untouchable. The top
version(s) are not. Reverting to a prior version IS a use-case.
Deleting or moving a version IS a use-case. There are UI commands to
do them.
Post by Bert Freudenberg
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.
You have a penchant for stating things as "facts" without offering any
rationale whatsoever. I could do something similar by only
saying,"it's rarely preferable to revert a commit by a subsequent
commit," with no basis.
Post by Bert Freudenberg
Patrick did that, and nobody was adversely affected.
No! We've been through this but, since you're Bert... you're
conflating what you think is a "miniscule adverse effect" with "no
adverse effect". In truth the __breadth__ of the impact is not
miniscule:

- *Every client of every user* is adversely affected.
- *Every dimension of the hardware* is affected (memory, storage, network).
- And software -- the usability of the code repository and ancestral model.
- *Every future user* and their hard drives, memorys, and networks
will also be adversely affected.
- These adverse effects are _permanent_,
even though they were conjured committed in only minutes
from a whimsy.

Growing the universe by 0.1% is a big deal that advsersely affects
everybody whether they realize it or not.

It was only by admin'ing, that nobody will be adversely affected.
Post by Bert Freudenberg
Our rules about caution, restraint, doubt etc are to prevent these critical problems from occurring, not to keep the version history "pretty".
Stop mischaracterizing the reason for maintaining a quality ancestry
and code repository.
Post by Bert Freudenberg
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.
Of course. That's why it says "Guidelines" not "Rules". This was
written to instill a conservative approach to committing. It really
is a good approach for something you consider immutable.

As I said before, "hopefully it won't happen very often, but if it
does..." Rest assured, I don't enjoy being this
Chris Muller
2018-10-17 22:07:59 UTC
Permalink
..."(memory, storage, network)"

I forgot CPU...
Post by Chris Muller
Post by Bert Freudenberg
the issue at stake here is the sanctity of the version history.
"Sanctity." If only you REALLY felt that way... :(
Post by Bert Freudenberg
It's untouchable. Think of it as immutable, append-only.
Versions buried more than one or two deep are untouchable. The top
version(s) are not. Reverting to a prior version IS a use-case.
Deleting or moving a version IS a use-case. There are UI commands to
do them.
Post by Bert Freudenberg
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.
You have a penchant for stating things as "facts" without offering any
rationale whatsoever. I could do something similar by only
saying,"it's rarely preferable to revert a commit by a subsequent
commit," with no basis.
Post by Bert Freudenberg
Patrick did that, and nobody was adversely affected.
No! We've been through this but, since you're Bert... you're
conflating what you think is a "miniscule adverse effect" with "no
adverse effect". In truth the __breadth__ of the impact is not
- *Every client of every user* is adversely affected.
- *Every dimension of the hardware* is affected (memory, storage, network).
- And software -- the usability of the code repository and ancestral model.
- *Every future user* and their hard drives, memorys, and networks
will also be adversely affected.
- These adverse effects are _permanent_,
even though they were conjured committed in only minutes
from a whimsy.
Growing the universe by 0.1% is a big deal that advsersely affects
everybody whether they realize it or not.
It was only by admin'ing, that nobody will be adversely affected.
Post by Bert Freudenberg
Our rules about caution, restraint, doubt etc are to prevent these critical problems from occurring, not to keep the version history "pretty".
Stop mischaracterizing the reason for maintaining a quality ancestry
and code repository.
Post by Bert Freudenberg
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.
Of course. That's why it says "Guidelines" not "Rules". This was
written to instill a conservative approach to committing. It really
is a good approach for something you consider immutable.
As I said before, "hopefully it won't happen very often, but if it
does..." Rest assured, I don't enjoy being this "bad guy"...
Bert Freudenberg
2018-10-17 22:50:54 UTC
Permalink
Post by Chris Muller
Post by Bert Freudenberg
the issue at stake here is the sanctity of the version history.
"Sanctity." If only you REALLY felt that way... :(
🀔
Post by Chris Muller
Post by Bert Freudenberg
It's untouchable. Think of it as immutable, append-only.
Versions buried more than one or two deep are untouchable. The top
version(s) are not. Reverting to a prior version IS a use-case.
Deleting or moving a version IS a use-case. There are UI commands to
do them.
Nope. Not in Trunk. Only trunk admins can move versions. Because it is a
last-resort option when all else fails.
Post by Chris Muller
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.
You have a penchant for stating things as "facts" without offering any
rationale whatsoever. I could do something similar by only
saying,"it's rarely preferable to revert a commit by a subsequent
commit," with no basis.
It's a commonly accepted practices in our field:

"since so much work is local within your clone, you have a great deal of
freedom to rewrite your history locally. However, once you push your work,
it is a different story entirely, and you should consider pushed work as
final unless you have good reason to change it. "
Post by Chris Muller
Patrick did that, and nobody was adversely affected.
No! We've been through this but, since you're Bert... you're
conflating what you think is a "miniscule adverse effect" with "no
adverse effect". In truth the __breadth__ of the impact is not
- *Every client of every user* is adversely affected.
- *Every dimension of the hardware* is affected (memory, storage, network).
- And software -- the usability of the code repository and ancestral model.
- *Every future user* and their hard drives, memorys, and networks
will also be adversely affected.
- These adverse effects are _permanent_,
even though they were conjured committed in only minutes
from a whimsy.
Growing the universe by 0.1% is a big deal that advsersely affects
everybody whether they realize it or not.
It was only by admin'ing, that nobody will be adversely affected.
Sorry, I did not understand that you are worried about the physical history
size.
Post by Chris Muller
Our rules about caution, restraint, doubt etc are to prevent these
critical problems from occurring, not to keep the version history "pretty".
Stop mischaracterizing the reason for maintaining a quality ancestry
and code repository.
I did not get that, sorry again. I also do not agree with it. We should fix
our tools, not change history.
Post by Chris Muller
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.
Of course. That's why it says "Guidelines" not "Rules". This was
written to instill a conservative approach to committing. It really
is a good approach for something you consider immutable.
As I said before, "hopefully it won't happen very often, but if it
does..." Rest assured, I don't enjoy being this "bad guy"... :(
In a community as small as ours I think it's more valuable to be proactive
than conservative. That was the original vision of the trunk development
process - removing the gatekeepers, empowering individual developers. I
still think that's a fundamentally good idea.

- Bert -
Chris Cunningham
2018-10-17 23:09:06 UTC
Permalink
Post by Bert Freudenberg
Post by Chris Muller
Post by Bert Freudenberg
the issue at stake here is the sanctity of the version history.
"Sanctity." If only you REALLY felt that way... :(
🀔
Post by Chris Muller
Post by Bert Freudenberg
It's untouchable. Think of it as immutable, append-only.
Versions buried more than one or two deep are untouchable. The top
version(s) are not. Reverting to a prior version IS a use-case.
Deleting or moving a version IS a use-case. There are UI commands to
do them.
Nope. Not in Trunk. Only trunk admins can move versions. Because it is a
last-resort option when all else fails.
Post by Chris Muller
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.
You have a penchant for stating things as "facts" without offering any
rationale whatsoever. I could do something similar by only
saying,"it's rarely preferable to revert a commit by a subsequent
commit," with no basis.
"since so much work is local within your clone, you have a great deal of
freedom to rewrite your history locally. However, once you push your
work, it is a different story entirely, and you should consider pushed work
as final unless you have good reason to change it. "
what is the source of this quote?
Post by Bert Freudenberg
Post by Chris Muller
Patrick did that, and nobody was adversely affected.
No! We've been through this but, since you're Bert... you're
conflating what you think is a "miniscule adverse effect" with "no
adverse effect". In truth the __breadth__ of the impact is not
- *Every client of every user* is adversely affected.
- *Every dimension of the hardware* is affected (memory, storage, network).
- And software -- the usability of the code repository and ancestral model.
- *Every future user* and their hard drives, memorys, and networks
will also be adversely affected.
- These adverse effects are _permanent_,
even though they were conjured committed in only minutes
from a whimsy.
Growing the universe by 0.1% is a big deal that advsersely affects
everybody whether they realize it or not.
It was only by admin'ing, that nobody will be adversely affected.
Sorry, I did not understand that you are worried about the physical
history size.
Post by Chris Muller
Our rules about caution, restraint, doubt etc are to prevent these
critical problems from occurring, not to keep the version history "pretty".
Stop mischaracterizing the reason for maintaining a quality ancestry
and code repository.
I did not get that, sorry again. I also do not agree with it. We should
fix our tools, not change history.
Post by Chris Muller
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.
Of course. That's why it says "Guidelines" not "Rules". This was
written to instill a conservative approach to committing. It really
is a good approach for something you consider immutable.
As I said before, "hopefully it won't happen very often, but if it
does..." Rest assured, I don't enjoy being this "bad guy"... :(
In a community as small as ours I think it's more valuable to be proactive
than conservative. That was the original vision of the trunk development
process - removing the gatekeepers, empowering individual developers. I
still think that's a fundamentally good idea.
- Bert -
David T. Lewis
2018-10-18 00:18:20 UTC
Permalink
Post by Bert Freudenberg
Post by Chris Muller
Post by Bert Freudenberg
the issue at stake here is the sanctity of the version history.
It's untouchable. Think of it as immutable, append-only.
Versions buried more than one or two deep are untouchable. The top
version(s) are not. Reverting to a prior version IS a use-case.
Deleting or moving a version IS a use-case. There are UI commands to
do them.
Nope. Not in Trunk. Only trunk admins can move versions. Because it is a
last-resort option when all else fails.
I agree. Manually rewriting the version history is sometimes needed in
extreme cases where the trunk update stream is broken. Aside from that,
it is usually a bad thing to do.

There may be differences of opinion here, but I think that we need to
clear on this as a matter of policy. In my view, the policy should be:

"Nothing should be deleted from trunk unless it is an emergency fix."

T
Bernhard Pieber
2018-10-19 18:03:34 UTC
Permalink
Post by David T. Lewis
Post by Bert Freudenberg
Post by Chris Muller
Post by Bert Freudenberg
the issue at stake here is the sanctity of the version history.
It's untouchable. Think of it as immutable, append-only.
Versions buried more than one or two deep are untouchable. The top
version(s) are not. Reverting to a prior version IS a use-case.
Deleting or moving a version IS a use-case. There are UI commands to
do them.
Nope. Not in Trunk. Only trunk admins can move versions. Because it is a
last-resort option when all else fails.
I agree. Manually rewriting the version history is sometimes needed in
extreme cases where the trunk update stream is broken. Aside from that,
it is usually a bad thing to do.
There may be differences of opinion here, but I think that we need to
"Nothing should be deleted from trunk unless it is an emergency fix."
+1
Post by David T. Lewis
Thanks,
Chris Muller
2018-10-18 00:43:03 UTC
Permalink
Post by Bert Freudenberg
Post by Chris Muller
Post by Bert Freudenberg
the issue at stake here is the sanctity of the version history.
"Sanctity." If only you REALLY felt that way... :(
🀔
...then you would want the history to be usable by reflecting meaningful
changes, and not noise.

It's not a raw tape of a tape-recorder, but our creation as a community
which is meant to be _useful_ to future consumers.
Post by Bert Freudenberg
Post by Chris Muller
Post by Bert Freudenberg
It's untouchable. Think of it as immutable, append-only.
Versions buried more than one or two deep are untouchable. The top
version(s) are not. Reverting to a prior version IS a use-case.
Deleting or moving a version IS a use-case. There are UI commands to
do them.
Nope. Not in Trunk. Only trunk admins can move versions. Because it is a
last-resort option when all else fails.
Yes, it is a last resort. I'm sure we can do what's necessary to avoid
having to resort to it.

The discussion is preserved in the mailing list, we don't need or want it
in the trunk artifact.

Removing a short-term in-and-out caused no harm. Leaving it in does.
Post by Bert Freudenberg
Post by Chris Muller
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.
You have a penchant for stating things as "facts" without offering any
rationale whatsoever. I could do something similar by only
saying,"it's rarely preferable to revert a commit by a subsequent
commit," with no basis.
"since so much work is local within your clone, you have a great deal of
freedom to rewrite your history locally. However, once you push your
work, it is a different story entirely, and you should consider pushed work
as final unless you have good reason to change it. "
Another "should" statement, and yes, sometimes there is good reason.
Post by Bert Freudenberg
Post by Chris Muller
Patrick did that, and nobody was adversely affected.
No! We've been through this but, since you're Bert... you're
conflating what you think is a "miniscule adverse effect" with "no
adverse effect". In truth the __breadth__ of the impact is not
- *Every client of every user* is adversely affected.
- *Every dimension of the hardware* is affected (memory, storage, network).
- And software -- the usability of the code repository and ancestral model.
- *Every future user* and their hard drives, memorys, and networks
will also be adversely affected.
- These adverse effects are _permanent_,
even though they were conjured committed in only minutes
from a whimsy.
Growing the universe by 0.1% is a big deal that advsersely affects
everybody whether they realize it or not.
It was only by admin'ing, that nobody will be adversely affected.
Sorry, I did not understand that you are worried about the physical
history size.
Just because we don't need or want to enshrine 2K worth of "discussion" in
the trunk artifact and add 2K*(that .mcz file + every future .mcz file) *
(every copy of that file on a computer (package-cache, etc.) * (every
computer using Squeak), + (every running image memory) + (network
transit) + (cpu) etc. etc., doesn't mean I'm actively "worried" about
something. It would be like me saying to you, "I did not understand that
you are worried about performance". You may not be while still not
necessarily wanting to degrade something down when given a choice not to.
Post by Bert Freudenberg
Post by Chris Muller
Our rules about caution, restraint, doubt etc are to prevent these
critical problems from occurring, not to keep the version history "pretty".
Stop mischaracterizing the reason for maintaining a quality ancestry
and code repository.
I did not get that, sorry again. I also do not agree with it. We should
fix our tools, not change history.
It never was history.

What about the real-world cost?

Is there a single real-world benefit? You haven't mentioned a single
compelling one, just "should".
Post by Bert Freudenberg
Post by Chris Muller
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.
Of course. That's why it says "Guidelines" not "Rules". This was
written to instill a conservative approach to committing. It really
is a good approach for something you consider immutable.
As I said before, "hopefully it won't happen very often, but if it
does..." Rest assured, I don't enjoy being this "bad guy"... :(
In a community as small as ours I think it's more valuable to be proactive
than conservative.
That was the original vision of the trunk development process - removing
Post by Bert Freudenberg
the gatekeepers, empowering individual developers. I still think that's a
fundamentally good idea.
Right, but this has nothing to do with any of that. The state of the trunk
is still where you left it, and you are just as empowered as you always
were. Nothing changed, there was an obvious "oops", it never was
"history", so it was moved to Treated. We should honor the spirit of the
New Community Development Model. The ancestry is not a tape-recorder like
in git culture.

- Chris
Bernhard Pieber
2018-10-19 18:17:36 UTC
Permalink
Hi Chris,

It seems that you are quite annoyed and I assure you it is not my intention to annoy you any further. However, I would like to clarify one thing because it might make it easier for me to see where you come from. I have always thought that the moment something is pushed to trunk it becomes part of the history. Therefore I thought moving to Treated should only happen from Inbox. As you said "It never was history" you must mean somehing slightly different by history, right? I wonder what exactly?

Cheers,
Bernhard
Post by Chris Muller
Post by Bert Freudenberg
the issue at stake here is the sanctity of the version history.
"Sanctity." If only you REALLY felt that way... :(
🤔
...then you would want the history to be usable by reflecting meaningful changes, and not noise.
It's not a raw tape of a tape-recorder, but our creation as a community which is meant to be _useful_ to future consumers.
Post by Bert Freudenberg
It's untouchable. Think of it as immutable, append-only.
Versions buried more than one or two deep are untouchable. The top
version(s) are not. Reverting to a prior version IS a use-case.
Deleting or moving a version IS a use-case. There are UI commands to
do them.
Nope. Not in Trunk. Only trunk admins can move versions. Because it is a last-resort option when all else fails.
Yes, it is a last resort. I'm sure we can do what's necessary to avoid having to resort to it.
The discussion is preserved in the mailing list, we don't need or want it in the trunk artifact.
Removing a short-term in-and-out caused no harm. Leaving it in does.
Post by Bert Freudenberg
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.
You have a penchant for stating things as "facts" without offering any
rationale whatsoever. I could do something similar by only
saying,"it's rarely preferable to revert a commit by a subsequent
commit," with no basis.
"since so much work is local within your clone, you have a great deal of freedom to rewrite your history locally. However, once you push your work, it is a different story entirely, and you should consider pushed work as final unless you have good reason to change it. "
Another "should" statement, and yes, sometimes there is good reason.
Post by Bert Freudenberg
Patrick did that, and nobody was adversely affected.
No! We've been through this but, since you're Bert... you're
conflating what you think is a "miniscule adverse effect" with "no
adverse effect". In truth the __breadth__ of the impact is not
- *Every client of every user* is adversely affected.
- *Every dimension of the hardware* is affected (memory, storage, network).
- And software -- the usability of the code repository and ancestral model.
- *Every future user* and their hard drives, memorys, and networks
will also be adversely affected.
- These adverse effects are _permanent_,
even though they were conjured committed in only minutes
from a whimsy.
Growing the universe by 0.1% is a big deal that advsersely affects
everybody whether they realize it or not.
It was only by admin'ing, that nobody will be adversely affected.
Sorry, I did not understand that you are worried about the physical history size.
Just because we don't need or want to enshrine 2K worth of "discussion" in the trunk artifact and add 2K*(that .mcz file + every future .mcz file) * (every copy of that file on a computer (package-cache, etc.) * (every computer using Squeak), + (every running image memory) + (network transit) + (cpu) etc. etc., doesn't mean I'm actively "worried" about something. It would be like me saying to you, "I did not understand that you are worried about performance". You may not be while still not necessarily wanting to degrade something down when given a choice not to.
Post by Bert Freudenberg
Our rules about caution, restraint, doubt etc are to prevent these critical problems from occurring, not to keep the version history "pretty".
Stop mischaracterizing the reason for maintaining a quality ancestry
and code repository.
I did not get that, sorry again. I also do not agree with it. We should fix our tools, not change history.
It never was history.
What about the real-world cost?
Is there a single real-world benefit? You haven't mentioned a single compelling one, just "should".
Post by Bert Freudenberg
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.
Of course. That's why it says "Guidelines" not "Rules". This was
written to instill a conservative approach to committing. It really
is a good approach for something you consider immutable.
As I said before, "hopefully it won't happen very often, but if it
does..." Rest assured, I don't enjoy being this "bad guy"... :(
In a community as small as ours I think it's more valuable to be proactive than conservative.
That was the original vision of the trunk development process - removing the gatekeepers, empowering individual developers. I still think that's a fundamentally good idea.
Right, but this has nothing to do with any of that. The state of the trunk is still where you left it, and you are just as empowered as you always were. Nothing changed, there was an obvious "oops", it never was "history", so it was moved to Treated. We should honor the spirit of the New Community Development Model. The ancestry is not a tape-recorder like in g
H. Hirzel
2018-10-19 18:30:29 UTC
Permalink
Hi Bernard

I think the explanation lies in the following

Let us assume we have the following situation in the trunk

A.
update n
update n-1
update n-2
update n-3

Then an update n+1 is made:

B.
update n+1
update n
update n-1
update n-2
update n-3

and _immediately_ after it is discovered (within a few hours) that
update n+1 needs to be reverted and that is done so we have C

C.
update n+ 2 = revert of update n+1
update n+1
update n
update n-1
update n-2
update n-3

Then somebody detects this _BEFORE_ an update n+3 is made.
And deletes
update n+ 2 = revert of update n+1
update n+1


Then the situation is now

D
update n
update n-1
update n-2
update n-3

and this is indeed A.
No history to keep track of. The argument is that if an issue is
detected within a reasonable short time it does not need to be
recorded as history.

This was discussed a few months ago on the list.

Cases where this happens are actually rare (about every 6 months) and
the general recommendation is to discuss things in the inbox first.

--Hannes
Post by Levente Uzonyi
Hi Chris,
It seems that you are quite annoyed and I assure you it is not my intention
to annoy you any further. However, I would like to clarify one thing because
it might make it easier for me to see where you come from. I have always
thought that the moment something is pushed to trunk it becomes part of the
history. Therefore I thought moving to Treated should only happen from
Inbox. As you said "It never was history" you must mean somehing slightly
different by history, right? I wonder what exactly?
Cheers,
Bernhard
Post by Chris Muller
Post by Bert Freudenberg
the issue at stake here is the sanctity of the version history.
"Sanctity." If only you REALLY felt that way... :(
🤔
...then you would want the history to be usable by reflecting meaningful
changes, and not noise.
It's not a raw tape of a tape-recorder, but our creation as a community
which is meant to be _useful_ to future consumers.
Post by Bert Freudenberg
It's untouchable. Think of it as immutable, append-only.
Versions buried more than one or two deep are untouchable. The top
version(s) are not. Reverting to a prior version IS a use-case.
Deleting or moving a version IS a use-case. There are UI commands to
do them.
Nope. Not in Trunk. Only trunk admins can move versions. Because it is a
last-resort option when all else fails.
Yes, it is a last resort. I'm sure we can do what's necessary to avoid
having to resort to it.
The discussion is preserved in the mailing list, we don't need or want it
in the trunk artifact.
Removing a short-term in-and-out caused no harm. Leaving it in does.
Post by Bert Freudenberg
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.
You have a penchant for stating things as "facts" without offering any
rationale whatsoever. I could do something similar by only
saying,"it's rarely preferable to revert a commit by a subsequent
commit," with no basis.
"since so much work is local within your clone, you have a great deal of
freedom to rewrite your history locally. However, once you push your work,
it is a different story entirely, and you should consider pushed work as
final unless you have good reason to change it. "
Another "should" statement, and yes, sometimes there is good reason.
Post by Bert Freudenberg
Patrick did that, and nobody was adversely affected.
No! We've been through this but, since you're Bert... you're
conflating what you think is a "miniscule adverse effect" with "no
adverse effect". In truth the __breadth__ of the impact is not
- *Every client of every user* is adversely affected.
- *Every dimension of the hardware* is affected (memory, storage, network).
- And software -- the usability of the code repository and ancestral model.
- *Every future user* and their hard drives, memorys, and networks
will also be adversely affected.
- These adverse effects are _permanent_,
even though they were conjured committed in only minutes
from a whimsy.
Growing the universe by 0.1% is a big deal that advsersely affects
everybody whether they realize it or not.
It was only by admin'ing, that nobody will be adversely affected.
Sorry, I did not understand that you are worried about the physical history size.
Just because we don't need or want to enshrine 2K worth of "discussion" in
the trunk artifact and add 2K*(that .mcz file + every future .mcz file) *
(every copy of that file on a computer (package-cache, etc.) * (every
computer using Squeak), + (every running image memory) + (network transit)
+ (cpu) etc. etc., doesn't mean I'm actively "worried" about something.
It would be like me saying to you, "I did not understand that you are
worried about performance". You may not be while still not necessarily
wanting to degrade something down when given a choice not to.
Post by Bert Freudenberg
Our rules about caution, restraint, doubt etc are to prevent these
critical problems from occurring, not to keep the version history "pretty".
Stop mischaracterizing the reason for maintaining a quality ancestry
and code repository.
I did not get that, sorry again. I also do not agree with it. We should
fix our tools, not change history.
It never was history.
What about the real-world cost?
Is there a single real-world benefit? You haven't mentioned a single
compelling one, just "should".
Post by Bert Freudenberg
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.
Of course. That's why it says "Guidelines" not "Rules". This was
written to instill a conservative approach to committing. It really
is a good approach for something you consider immutable.
As I said before, "hopefully it won't happen very often, but if it
does..." Rest assured, I don't enjoy being this "bad guy"... :(
In a community as small as ours I think it's more valuable to be proactive
than conservative.
That was the original vision of the trunk development process - removing
the gatekeepers, empowering individual developers. I still think that's a
fundamentally good idea.
Right, but this has nothing to do with any of that. The state of the
trunk is still where you left it, and you are just as empowered as you
always were. Nothing changed, there was an obvious "oops", it never was
"history", so it was moved to Treated. We should honor the spirit of the
New Community Development Model. The ancestry is not a tape-recorder like
in git culture.
- Chr
Levente Uzonyi
2018-10-19 20:44:54 UTC
Permalink
Post by H. Hirzel
Hi Bernard
I think the explanation lies in the following
Let us assume we have the following situation in the trunk
A.
update n
update n-1
update n-2
update n-3
B.
update n+1
update n
update n-1
update n-2
update n-3
and _immediately_ after it is discovered (within a few hours) that
update n+1 needs to be reverted and that is done so we have C
C.
update n+ 2 = revert of update n+1
update n+1
update n
update n-1
update n-2
update n-3
Then somebody detects this _BEFORE_ an update n+3 is made.
And deletes
update n+ 2 = revert of update n+1
update n+1
Then the situation is now
D
update n
update n-1
update n-2
update n-3
and this is indeed A.
No history to keep track of. The argument is that if an issue is
detected within a reasonable short time it does not need to be
recorded as history.
Unfortunately that is not true if you had updated your image to B, but
didn't update it to C in time.
When the versions are removed (D), your image will stay tainted with the
faulty version after updating. The only way to fix it is to manually
revert to the previous version if that's possible at all.
So, while D looks the same as A, D won't fix your image updated to B.
You'll be stuck with the faulty version and merge conflicts in the future
if you don't notice that.
Had the two versions not be removed, the update process would be able to
fix your image "automagically".

Levente
Post by H. Hirzel
This was discussed a few months ago on the list.
Cases where this happens are actually rare (about every 6 months) and
the general recommendation is to discuss things in the inbox first.
--Hannes
Post by Levente Uzonyi
Hi Chris,
It seems that you are quite annoyed and I assure you it is not my intention
to annoy you any further. However, I would like to clarify one thing because
it might make it easier for me to see where you come from. I have always
thought that the moment something is pushed to trunk it becomes part of the
history. Therefore I thought moving to Treated should only happen from
Inbox. As you said "It never was history" you must mean somehing slightly
different by history, right? I wonder what exactly?
Cheers,
Bernhard
Post by Chris Muller
Post by Bert Freudenberg
the issue at stake here is the sanctity of the version history.
"Sanctity." If only you REALLY felt that way... :(
🀔
...then you would want the history to be usable by reflecting meaningful
changes, and not noise.
It's not a raw tape of a tape-recorder, but our creation as a community
which is meant to be _useful_ to future consumers.
Post by Bert Freudenberg
It's untouchable. Think of it as immutable, append-only.
Versions buried more than one or two deep are untouchable. The top
version(s) are not. Reverting to a prior version IS a use-case.
Deleting or moving a version IS a use-case. There are UI commands to
do them.
Nope. Not in Trunk. Only trunk admins can move versions. Because it is a
last-resort option when all else fails.
Yes, it is a last resort. I'm sure we can do what's necessary to avoid
having to resort to it.
The discussion is preserved in the mailing list, we don't need or want it
in the trunk artifact.
Removing a short-term in-and-out caused no harm. Leaving it in does.
Post by Bert Freudenberg
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.
You have a penchant for stating things as "facts" without offering any
rationale whatsoever. I could do something similar by only
saying,"it's rarely preferable to revert a commit by a subsequent
commit," with no basis.
"since so much work is local within your clone, you have a great deal of
freedom to rewrite your history locally. However, once you push your work,
it is a different story entirely, and you should consider pushed work as
final unless you have good reason to change it. "
Another "should" statement, and yes, sometimes there is good reason.
Post by Bert Freudenberg
Patrick did that, and nobody was adversely affected.
No! We've been through this but, since you're Bert... you're
conflating what you think is a "miniscule adverse effect" with "no
adverse effect". In truth the __breadth__ of the impact is not
- *Every client of every user* is adversely affected.
- *Every dimension of the hardware* is affected (memory, storage, network).
- And software -- the usability of the code repository and ancestral model.
- *Every future user* and their hard drives, memorys, and networks
will also be adversely affected.
- These adverse effects are _permanent_,
even though they were conjured committed in only minutes
from a whimsy.
Growing the universe by 0.1% is a big deal that advsersely affects
everybody whether they realize it or not.
It was only by admin'ing, that nobody will be adversely affected.
Sorry, I did not understand that you are worried about the physical history size.
Just because we don't need or want to enshrine 2K worth of "discussion" in
the trunk artifact and add 2K*(that .mcz file + every future .mcz file) *
(every copy of that file on a computer (package-cache, etc.) * (every
computer using Squeak), + (every running image memory) + (network transit)
+ (cpu) etc. etc., doesn't mean I'm actively "worried" about something.
It would be like me saying to you, "I did not understand that you are
worried about performance". You may not be while still not necessarily
wanting to degrade something down when given a choice not to.
Post by Bert Freudenberg
Our rules about caution, restraint, doubt etc are to prevent these
critical problems from occurring, not to keep the version history "pretty".
Stop mischaracterizing the reason for maintaining a quality ancestry
and code repository.
I did not get that, sorry again. I also do not agree with it. We should
fix our tools, not change history.
It never was history.
What about the real-world cost?
Is there a single real-world benefit? You haven't mentioned a single
compelling one, just "should".
Post by Bert Freudenberg
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.
Of course. That's why it says "Guidelines" not "Rules". This was
written to instill a conservative approach to committing. It really
is a good approach for something you consider immutable.
As I said before, "hopefully it won't happen very often, but if it
does..." Rest assured, I don't enjoy being this "bad guy"... :(
In a community as small as ours I think it's more valuable to be proactive
than conservative.
That was the original vision of the trunk development process - removing
the gatekeepers, empowering individual developers. I still think that's a
fundamentally good idea.
Right, but this has nothing to do with any of that. The state of the
trunk is still where you left it, and you are just as empowered as you
always were. Nothing changed, there was an obvious "oops", it never was
"history", so it was moved to Treated. We should honor the spirit of the
New Community Development Model. The ancestry is not a tape-recorder like
in git culture.
- Chris
H. Hirzel
2018-10-19 21:00:16 UTC
Permalink
Levente, yes, that is correct. It actually once happened to me. I
updated to B in a development image (alpha). And I did not get the
update to C. So I had to revert the effect manually.
But as mentioned before, all is comparatively rare.

Regarding the history discussion a much more relevant point is that
some of the mcz or mcd files are actually quite large. Even just the
change of some 100 or 200 bytes often causes a 100..200kB update file
to be created.

--Hannes
Post by Levente Uzonyi
Post by H. Hirzel
Hi Bernard
I think the explanation lies in the following
Let us assume we have the following situation in the trunk
A.
update n
update n-1
update n-2
update n-3
B.
update n+1
update n
update n-1
update n-2
update n-3
and _immediately_ after it is discovered (within a few hours) that
update n+1 needs to be reverted and that is done so we have C
C.
update n+ 2 = revert of update n+1
update n+1
update n
update n-1
update n-2
update n-3
Then somebody detects this _BEFORE_ an update n+3 is made.
And deletes
update n+ 2 = revert of update n+1
update n+1
Then the situation is now
D
update n
update n-1
update n-2
update n-3
and this is indeed A.
No history to keep track of. The argument is that if an issue is
detected within a reasonable short time it does not need to be
recorded as history.
Unfortunately that is not true if you had updated your image to B, but
didn't update it to C in time.
When the versions are removed (D), your image will stay tainted with the
faulty version after updating. The only way to fix it is to manually
revert to the previous version if that's possible at all.
So, while D looks the same as A, D won't fix your image updated to B.
You'll be stuck with the faulty version and merge conflicts in the future
if you don't notice that.
Had the two versions not be removed, the update process would be able to
fix your image "automagically".
Levente
Post by H. Hirzel
This was discussed a few months ago on the list.
Cases where this happens are actually rare (about every 6 months) and
the general recommendation is to discuss things in the inbox first.
--Hannes
Post by Levente Uzonyi
Hi Chris,
It seems that you are quite annoyed and I assure you it is not my intention
to annoy you any further. However, I would like to clarify one thing because
it might make it easier for me to see where you come from. I have always
thought that the moment something is pushed to trunk it becomes part of the
history. Therefore I thought moving to Treated should only happen from
Inbox. As you said "It never was history" you must mean somehing slightly
different by history, right? I wonder what exactly?
Cheers,
Bernhard
Post by Chris Muller
Post by Bert Freudenberg
the issue at stake here is the sanctity of the version history.
"Sanctity." If only you REALLY felt that way... :(
🤔
...then you would want the history to be usable by reflecting meaningful
changes, and not noise.
It's not a raw tape of a tape-recorder, but our creation as a community
which is meant to be _useful_ to future consumers.
Post by Bert Freudenberg
It's untouchable. Think of it as immutable, append-only.
Versions buried more than one or two deep are untouchable. The top
version(s) are not. Reverting to a prior version IS a use-case.
Deleting or moving a version IS a use-case. There are UI commands to
do them.
Nope. Not in Trunk. Only trunk admins can move versions. Because it is a
last-resort option when all else fails.
Yes, it is a last resort. I'm sure we can do what's necessary to avoid
having to resort to it.
The discussion is preserved in the mailing list, we don't need or want it
in the trunk artifact.
Removing a short-term in-and-out caused no harm. Leaving it in does.
Post by Bert Freudenberg
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.
You have a penchant for stating things as "facts" without offering any
rationale whatsoever. I could do something similar by only
saying,"it's rarely preferable to revert a commit by a subsequent
commit," with no basis.
"since so much work is local within your clone, you have a great deal of
freedom to rewrite your history locally. However, once you push your work,
it is a different story entirely, and you should consider pushed work as
final unless you have good reason to change it. "
Another "should" statement, and yes, sometimes there is good reason.
Post by Bert Freudenberg
Patrick did that, and nobody was adversely affected.
No! We've been through this but, since you're Bert... you're
conflating what you think is a "miniscule adverse effect" with "no
adverse effect". In truth the __breadth__ of the impact is not
- *Every client of every user* is adversely affected.
- *Every dimension of the hardware* is affected (memory, storage, network).
- And software -- the usability of the code repository and ancestral model.
- *Every future user* and their hard drives, memorys, and networks
will also be adversely affected.
- These adverse effects are _permanent_,
even though they were conjured committed in only minutes
from a whimsy.
Growing the universe by 0.1% is a big deal that advsersely affects
everybody whether they realize it or not.
It was only by admin'ing, that nobody will be adversely affected.
Sorry, I did not understand that you are worried about the physical history size.
Just because we don't need or want to enshrine 2K worth of "discussion" in
the trunk artifact and add 2K*(that .mcz file + every future .mcz file) *
(every copy of that file on a computer (package-cache, etc.) * (every
computer using Squeak), + (every running image memory) + (network transit)
+ (cpu) etc. etc., doesn't mean I'm actively "worried" about something.
It would be like me saying to you, "I did not understand that you are
worried about performance". You may not be while still not necessarily
wanting to degrade something down when given a choice not to.
Post by Bert Freudenberg
Our rules about caution, restraint, doubt etc are to prevent these
critical problems from occurring, not to keep the version history "pretty".
Stop mischaracterizing the reason for maintaining a quality ancestry
and code repository.
I did not get that, sorry again. I also do not agree with it. We should
fix our tools, not change history.
It never was history.
What about the real-world cost?
Is there a single real-world benefit? You haven't mentioned a single
compelling one, just "should".
Post by Bert Freudenberg
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.
Of course. That's why it says "Guidelines" not "Rules". This was
written to instill a conservative approach to committing. It really
is a good approach for something you consider immutable.
As I said before, "hopefully it won't happen very often, but if it
does..." Rest assured, I don't enjoy being this "bad guy"... :(
In a community as small as ours I think it's more valuable to be proactive
than conservative.
That was the original vision of the trunk development process - removing
the gatekeepers, empowering individual developers. I still think that's a
fundamentally good idea.
Right, but this has nothing to do with any of that. The state of the
trunk is still where you left it, and you are just as empowered as you
always were. Nothing changed, there was an obvious "oops", it never was
"history", so it was moved to Treated. We should honor the spirit of the
New Community Development Model. The ancestry is not a tape-recorder like
in git culture.
-
Bernhard Pieber
2018-10-24 19:39:17 UTC
Permalink
So it is about the mcd files in the package cache? Or are the 100..200kB added to the image as well?

Bernhard
Post by H. Hirzel
Levente, yes, that is correct. It actually once happened to me. I
updated to B in a development image (alpha). And I did not get the
update to C. So I had to revert the effect manually.
But as mentioned before, all is comparatively rare.
Regarding the history discussion a much more relevant point is that
some of the mcz or mcd files are actually quite large. Even just the
change of some 100 or 200 bytes often causes a 100..200kB update file
to be created.
--Hannes
Post by Levente Uzonyi
Post by H. Hirzel
Hi Bernard
I think the explanation lies in the following
Let us assume we have the following situation in the trunk
A.
update n
update n-1
update n-2
update n-3
B.
update n+1
update n
update n-1
update n-2
update n-3
and _immediately_ after it is discovered (within a few hours) that
update n+1 needs to be reverted and that is done so we have C
C.
update n+ 2 = revert of update n+1
update n+1
update n
update n-1
update n-2
update n-3
Then somebody detects this _BEFORE_ an update n+3 is made.
And deletes
update n+ 2 = revert of update n+1
update n+1
Then the situation is now
D
update n
update n-1
update n-2
update n-3
and this is indeed A.
No history to keep track of. The argument is that if an issue is
detected within a reasonable short time it does not need to be
recorded as history.
Unfortunately that is not true if you had updated your image to B, but
didn't update it to C in time.
When the versions are removed (D), your image will stay tainted with the
faulty version after updating. The only way to fix it is to manually
revert to the previous version if that's possible at all.
So, while D looks the same as A, D won't fix your image updated to B.
You'll be stuck with the faulty version and merge conflicts in the future
if you don't notice that.
Had the two versions not be removed, the update process would be able to
fix your image "automagically".
Levente
Post by H. Hirzel
This was discussed a few months ago on the list.
Cases where this happens are actually rare (about every 6 months) and
the general recommendation is to discuss things in the inbox first.
--Hannes
Post by Levente Uzonyi
Hi Chris,
It seems that you are quite annoyed and I assure you it is not my intention
to annoy you any further. However, I would like to clarify one thing because
it might make it easier for me to see where you come from. I have always
thought that the moment something is pushed to trunk it becomes part of the
history. Therefore I thought moving to Treated should only happen from
Inbox. As you said "It never was history" you must mean somehing slightly
different by history, right? I wonder what exactly?
Cheers,
Bernhard
Post by Chris Muller
Post by Bert Freudenberg
the issue at stake here is the sanctity of the version history.
"Sanctity." If only you REALLY felt that way... :(
🤔
...then you would want the history to be usable by reflecting meaningful
changes, and not noise.
It's not a raw tape of a tape-recorder, but our creation as a community
which is meant to be _useful_ to future consumers.
Post by Bert Freudenberg
It's untouchable. Think of it as immutable, append-only.
Versions buried more than one or two deep are untouchable. The top
version(s) are not. Reverting to a prior version IS a use-case.
Deleting or moving a version IS a use-case. There are UI commands to
do them.
Nope. Not in Trunk. Only trunk admins can move versions. Because it is a
last-resort option when all else fails.
Yes, it is a last resort. I'm sure we can do what's necessary to avoid
having to resort to it.
The discussion is preserved in the mailing list, we don't need or want it
in the trunk artifact.
Removing a short-term in-and-out caused no harm. Leaving it in does.
Post by Bert Freudenberg
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.
You have a penchant for stating things as "facts" without offering any
rationale whatsoever. I could do something similar by only
saying,"it's rarely preferable to revert a commit by a subsequent
commit," with no basis.
"since so much work is local within your clone, you have a great deal of
freedom to rewrite your history locally. However, once you push your work,
it is a different story entirely, and you should consider pushed work as
final unless you have good reason to change it. "
Another "should" statement, and yes, sometimes there is good reason.
Post by Bert Freudenberg
Patrick did that, and nobody was adversely affected.
No! We've been through this but, since you're Bert... you're
conflating what you think is a "miniscule adverse effect" with "no
adverse effect". In truth the __breadth__ of the impact is not
- *Every client of every user* is adversely affected.
- *Every dimension of the hardware* is affected (memory, storage, network).
- And software -- the usability of the code repository and ancestral model.
- *Every future user* and their hard drives, memorys, and networks
will also be adversely affected.
- These adverse effects are _permanent_,
even though they were conjured committed in only minutes
from a whimsy.
Growing the universe by 0.1% is a big deal that advsersely affects
everybody whether they realize it or not.
It was only by admin'ing, that nobody will be adversely affected.
Sorry, I did not understand that you are worried about the physical history size.
Just because we don't need or want to enshrine 2K worth of "discussion" in
the trunk artifact and add 2K*(that .mcz file + every future .mcz file) *
(every copy of that file on a computer (package-cache, etc.) * (every
computer using Squeak), + (every running image memory) + (network transit)
+ (cpu) etc. etc., doesn't mean I'm actively "worried" about something.
It would be like me saying to you, "I did not understand that you are
worried about performance". You may not be while still not necessarily
wanting to degrade something down when given a choice not to.
Post by Bert Freudenberg
Our rules about caution, restraint, doubt etc are to prevent these
critical problems from occurring, not to keep the version history "pretty".
Stop mischaracterizing the reason for maintaining a quality ancestry
and code repository.
I did not get that, sorry again. I also do not agree with it. We should
fix our tools, not change history.
It never was history.
What about the real-world cost?
Is there a single real-world benefit? You haven't mentioned a single
compelling one, just "should".
Post by Bert Freudenberg
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.
Of course. That's why it says "Guidelines" not "Rules". This was
written to instill a conservative approach to committing. It really
is a good approach for something you consider immutable.
As I said before, "hopefully it won't happen very often, but if it
does..." Rest assured, I don't enjoy being this "bad guy"... :(
In a community as small as ours I think it's more valuable to be proactive
than conservative.
That was the original vision of the trunk development process - removing
the gatekeepers, empowering individual developers. I still think that's a
fundamentally good idea.
Right, but this has nothing to do with any of that. The state of the
trunk is still where you left it, and you are just as empowered as you
always were. Nothing changed, there was an obvious "oops", it never was
"history", so it was moved to Treated. We should honor the spirit of the
New Community Development Model. The ancestry is not a tape-recorder like
in git culture.
- Chris
Loading...